text:
stats: Fix gRPC xDS pending_requests: now drains back to 0

Description: xDS gRPC's stat for number of xDS request queued to be sent was previously only getting set when an attempt to send hit rate limiting. In addition to not updating when new items arrive, this stat would never return to 0 once set to non-0. This change also removes this gauge's use of set(), as one small step toward possibly removing Gauge::set() (#5790).
Risk Level: low
Testing: added coverage of fixed thing to existing unit test

@fredlas can you look into the build failures? Seems legit. Feel free to make the helper private as needed.

Turns out I was applying the test framework correctly, and just not understanding the logic being tested! I now realize that the request queue only gets (meaningfully) used in cases of rate limiting. Left a comment to clarify.

After working with the guts of stats in another PR, I realized why this one was originally using set() like it was: it was avoiding activating this stat in the (common) case that rate limiting was not active. I switched from inc/dec back to set. But, the set() is now in a different place, where it will be correct.

Please merge master to pick up https://github.com/envoyproxy/envoy/pull/5827.

Merged, thanks for the heads up.

Ping; should be ready to go now.

@fredlas I don't see any test change in the diff? Did a change get dropped accidentally?

@mattklein123 I see comment changes in https://github.com/envoyproxy/envoy/pull/5796/commits/7998d8daa4db07e474599bc60118edd4d4891c52, which covers my last set of Qs.

@htuch Shouldn't this change have a test that failed before the fix? I don't see any test changes?

Whoops, yeah. I started with tests that were testing what I (wrongly) thought the logic was supposed to be, and removed them once I realized I was testing the wrong thing, but didn't add anything else. #5903 tests the fixed behavior. Sorry!

authors: fredlas htuch mattklein123


text:
udp proxy: complete MVP

Fixes https://github.com/envoyproxy/envoy/issues/492
Fixes https://github.com/envoyproxy/envoy/issues/9018
Risk Level: Low, new feature
Testing: Integration/unit
Docs Changes: Added
Release Notes: Added

Note: This is stacked on top of https://github.com/envoyproxy/envoy/pull/8999. I wanted to get this out before I take off for conference week in case anyone wants to kick the tires. cc @danzh2010

Quick note here for anyone trying this out that I forgot to mention. Until we merge the SO_REUSEPORT change for UDP listeners, this will only work with concurrency == 1.

@danzh2010 @moderation ready for proper review. Thank you!

Note that I just pushed a fix for the test flake reported in https://github.com/envoyproxy/envoy/issues/9018 to this PR. It's low frequency enough that I think we can land here.

@danzh2010 updated PTAL

/azp run envoy-linux

source: gharchive/pull-request

repo: envoyproxy/envoy

license_type: permissive

license_source: github-api


text:
GeoIP support for envoy gateway

Description:
we would like to use GeoIP support with envoy gateway. It seems that envoyproxy itself supports that already https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/geoip_filter
What could be the correct place for this configuration? I am thinking could it fit under securitypolicy? basically this is similar stuff that "authorization" has, but no idea should it be under authorization or just under securitypolicy spec

cc @nezdolik

geoip databases are pretty large, so I think the envoy gateway should download the database from normal http url and then somehow upload that to envoyproxy?

Currently Envoyproxy expects the databases to be present at configured location on startup, so Envoy Gateway (infra module?) could download the databases prior to spinning up Envoyproxies.

What could be the correct place for this configuration? I am thinking could it fit under securitypolicy?

Logically it does not belong to SecurityPolicy (API allowing system administrators to configure authentication and authorization policies to the traffic entering the gateway).
@zetaab feel free to raise feature request to envoyproxy repo.

imo, it does belong to securitypolicy api. If we have like 2 apis: https://foobar.com and https://huuh.com. We want that https://huh.com allows all traffic from everywhere and we want limit https://foobar.com only for instance to allow Sweden. What could be the better place for that? In securitypolicy api we can already configure do we allow or deny ip addresses, this is kind of similar stuff but with countries in it?

@zetaab from that perspective yes, if you bundle geolocation feature with rbac. But geolocation filter on its own just appends geolocation information to the request.

@nezdolik right. So basically geoip filter should be before rbac (securitypolicy authorization) and then in authorization we should have possibility deny/allow by header for instance. If authorization is not used, then geoip headers are just applied to the request.

source: gharchive/issue

authors: arkodg nezdolik zetaab

repo: envoyproxy/gateway


text:
Asset helpers not working post upgrading to ruby 2.7

@envygeeks
Hi ,
I am facing issue with  below scenario, is there anything I am missing ?
Gemlist
Upgraded ruby verison from 2.5 to 2.7
Jekyll version  3.9.2
Jekyll assets 3.0.6
Sprockets 3.7.2
sprockets-assets latest
sprockets-helpers
In css/main.scss
.bg {
 background: url(asset_path("account_member_roles_1@1x.png"));
}

tried
asset_path , asset_url, image-url, asset-url didn't work
_config.yaml
baseurl: "/help" # the subpath of your site, e.g. /blog/
destination: _site/help
incremental: true
plugins:

octopress-autoprefixer
jekyll-assets

markdown: kramdown
kramdown:
input: GFM
collections:
articles:
output: true
sass:
sass_dir: css
exclude:

/.asset-cache/* # Files with [._#] that Jekyll doesn't alread manage need a leading slash.
/.buildkite/*
.dockerfileignore
Capfile
cicd/*
circle.yml
config/*
Dockerfile
Gemfile
Gemfile.lock
gems/*
Guardfile
lib/*
nginx.conf
nginx.docker.conf
node_modules/*
Rakefile
README.md
script/*
spec/*
vendor/*

assets:
assets:
- "*.svg"
prefix: "/kb_assets"
sources:
- _kb_assets/images
- _kb_assets/stylesheets
- _kb_assets/javascripts
- _kb_assets/image
- _kb_assets/img
- _kb_assets/css
- _vendor/stylesheets
- _vendor/javascripts
sources:

_kb_assets/css
_kb_assets/fonts
_kb_assets/images
_kb_assets/videos
_kb_assets/javascript
_kb_assets/video
_kb_assets/image
_kb_assets/img
_kb_assets/js
_kb_assets/stylesheets
css

All css files sit in the root/css folder

It seems I have similar problem.

ruby-2.7.2
jekyll-4.3.2

Maybe I use it wrong way? I added this plugin to existing project which have folders:

:file_folder: _sass

:page_facing_up::page_facing_up: *.scss

:file_folder: assets

:file_folder: css

:page_facing_up: styles.scss — main file

:file_folder: images

I tried to move images and styles to :file_folder: _assets without any success.
Is there any documentation except README.md?

authors: annapoorna-r shoorick

repo: envygeeks/jekyll-assets

license: ISC


text:
assess which wallets we want to support

for now we support only Anchor...
Which ones should we support?

Scatter
Wombat
Lynx
etc..

One of the new UALProvider authenticators is erroring out. In dev mode, it's loud (see below). I don't think it impacts user experience in prod mode though. But it is annoying in dev mode.

I think it's Scatter. Not sure.

repo: eoscommunity/Eden

license: MIT


text:
Add separation between the current week and following week

Is it possible to add separation between the current week and following week when the calendar is displayed in weeks? I would like to add some space between the bottom and top of the calendars see attached image with red arrow mark.
"system": {
"show": ["weeks"]

Are, you just put the "space", not "border"... Hmmm.. the html structure is table so It cannot be separated physically. but what you want is giving attentional look to this week, you can add more decoration.
Try this code in your custom.css (not tested but you can get an idea)
.CALEXT  tr.thisweek td {
    border-bottom: 2px solid #FFF
}

Thanks!! the code you recommended works perfectly.

repo: eouia/MMM-CalendarExt

license: mit

license_source: bigquery


text:
Multi parameters

Implementing support for parameters where the parameter value is composed of more than one template value, e.g: timespan={time:start?}/{time:end?}

Coverage decreased (-0.5%) to 72.15% when pulling 562af48217d776ba9d1582604676a59beab2657f on multi-parameters into 714800f43567ab6cd4222a1769af19941c843c30 on master.

authors: constantinius coveralls

repo: eoxc/opensearch


text:
Allow accepting an argument by position and by flag

 Issue by casey
Monday Apr 13, 2020 at 23:41 GMT
Originally opened as https://github.com/clap-rs/clap/issues/1820

It would be nice to allow CLIs to a single argument both by position, and by flag.
A possible API for this would be to add Arg::positional(bool), that when passed true makes an arg be accepted by position, even if it already has a long or short flag.
The reason this came up is that wrote a CLI with Clap that takes all of it arguments by flag. After releasing the binary, it's clear that one of the flags is always going to be present, so I'd like to "promote" it to a positional argument, so the flag isn't required. However, I'd like to avoid breaking existing usage, so it would be ideal to make it both a flag and a positional argument.
Allowing seamless promotion from flag to flag + positional would have the nice bonus of encouraging conservative design of CLIs.
Positional arguments are the most scarce, since using more than two or three becomes unwieldy. Short flags are the next most scarce, since there are < 100 possible short flags. Long flags are essentially unlimited. So it would nice to enable the pattern of giving everything long flags initially, and then "upgradiing" commonly used arguments to short flags and positional over time.

 Comment by casey
Tuesday Apr 14, 2020 at 05:23 GMT

Thanks for the workaround, I'll do that for now. I'm not so much thinking of it as deprecating the option for the positional, since options can be more readable, for example in shell scripts.
There are some negatives to using two args. One is that because I'm calling a number of additional methods, those need to be duplicated. Using structopt, but would likely be similar with clap-derive:
  #[structopt(
    long = "input",
    short = "i",
    value_name = "PATH",
    empty_values = false,
    parse(try_from_os_str = InputTarget::try_from_os_str),
    help = INPUT_HELP,
  )]
  input_option: Option<InputTarget>,
  #[structopt(
    value_name = "PATH",
    empty_values = false,
    required_unless = "input-option",
    conflicts_with = "input-option",
    parse(try_from_os_str = InputTarget::try_from_os_str),
    help = INPUT_HELP,
  )]
  input_arg: Option<InputTarget>,

I had to factor out the help message into a constant, INPUT_HELP. I decided to not use hidden, since I think it's slightly more understandable if the argument shows in the help message in the options section, and in the args section at the bottom.
Also, I have required_if constraints on two other arguments on the "input" argument, so I had to modify them to be:
    required_if("input-arg", "-"),
    required_if("input-option", "-"),

And then to actually access the value, since it's now an Option, I'm doing:
    self
      .input_arg
      .as_ref()
      .xor(self.input_option.as_ref())
      .ok_or_else(|| Error::internal("Expected `input_arg` or `input_flag` to be set"))

All in all this isn't too bad, since I'm able to get the CLI that I wanted, but it could be made a little less verbose if it was supported directly.
Edit: Actually, using .xor is more correct, which I missed the first time around.

 Comment by CreepySkeleton
Tuesday Apr 14, 2020 at 00:27 GMT

If I get it right, this snipped is exactly what @casey wants:
App::new("app")
    .arg(
        // deprecated optional option
        Arg::with_name("input_opt")
            .hidden(true)
            .long("--input")
            .takes_value(true)
    )
    .arg(
        // new positional arg
        Arg::with_name("input_pos")
            .takes_value(true)
            .required_unless("input_pos")
    )

This is done already, what's left to explore?

 Comment by pksunkara
Tuesday Apr 14, 2020 at 08:30 GMT

Also, I have required_if constraints on two other arguments on the "input" argument, so I had to modify them to be:

You can use an arg group for that.

One is that because I'm calling a number of additional methods, those need to be duplicated.

You would be adding just one more condition to check if the argument is present or not. You wouldn't be needing anymore duplication. Please give some example if I am wrong.
I am still not convinced that this is needed to be handled by clap. Let's leave this open and see if more people ask for this.

 Comment by casey
Tuesday Apr 14, 2020 at 09:10 GMT

You would be adding just one more condition to check if the argument is present or not. You wouldn't be needing anymore duplication. Please give some example if I am wrong.

I should have been more clear, what I was referring to was the additional configuration of each arg that needs to be duplicated and now kept in sync, in this case empty_values = false and parse(try_from_os_str = InputTarget::try_from_os_str).

 Comment by CreepySkeleton
Tuesday Apr 14, 2020 at 20:48 GMT

I had to factor out the help message into a constant, INPUT_HELP.

This is totally expected when you want to use the same message for different args. For example, consider this clap-unrelated code:
// we want to pass the very same value to multiple fns

// Option 1 - duplicate
func1(&get_val());
func2(&get_val());

// Option 2 - factor out
let val = get_val;
func1(&val);
func2(&val);

clap is no different here.

And then to actually access the value, since it's now an Option, I'm doing:

Yeah, structopt isn't that handy when it comes to requires_if*; this is a known problem. So far, nobody has been able to propose a design that unambiguous and easy to use and considerably easy to implement, but this is a problem with derive, not with clap itself. Your suggestions/help are welcome there!

I was referring to was the additional configuration of each arg that needs to be duplicated and now kept in sync [...]

I believe this is intentional design of clap/structopt (I may be wrong here). Every arg requires you to configure it explicitly so anyone could tell it's properties just from the look of it, no need to look somewhere else. Code is much more read than written after all.
Keeping args in sync might be a problem indeed, but you current proposal is pretty much irrelevant here, no offense.

I'd like to get back to your proposal - positional(bool). In clap, an argument is either positional or not (has long/short options) by definition, they can't be both at the same time. If you want to see it ever implemented, we will need a detailed explanation of the semantic properties backed with unambiguous examples. Thanks for your understanding.
Personally I think that the only real problem here is keeping args in sync, but I also think that requires_if(name) hints developer about dependencies and connections rather well, the state of affairs is "good enough". Everything else here is just a bikeshedding if you ask me.

 Comment by pksunkara
Tuesday Apr 14, 2020 at 21:43 GMT

Can he do flatten to reuse the defined arg?

 Comment by CreepySkeleton
Tuesday Apr 14, 2020 at 21:45 GMT

He can't since the flags are not the same. And even if he could, I hardly see a point.

 Comment by casey
Wednesday Apr 15, 2020 at 00:32 GMT

I had to factor out the help message into a constant, INPUT_HELP.

This is totally expected when you want to use the same message for different args. For example, consider this clap-unrelated code:

Right, but with access to positional(true), they wouldn't need to be two different args, they could be the same arg, and be configured in a single place.

I was referring to was the additional configuration of each arg that needs to be duplicated and now kept in sync [...]

I believe this is intentional design of clap/structopt (I may be wrong here). Every arg requires you to configure it explicitly so anyone could tell it's properties just from the look of it, no need to look somewhere else. Code is much more read than written after all.
Keeping args in sync might be a problem indeed, but you current proposal is pretty much irrelevant here, no offense.

None taken! I think the proposal is relevant, because if you could do positional(true) the somewhat error prone duplication could be avoided, and done in a single place.

I'd like to get back to your proposal - positional(bool). In clap, an argument is either positional or not (has long/short options) by definition, they can't be both at the same time. If you want to see it ever implemented, we will need a detailed explanation of the semantic properties backed with unambiguous examples. Thanks for your understanding.

Here's a concrete example:
let arg = Arg::with_name("input")
  .long("input")
  .positional(true)
  .takes_value(true);

let app = App::new("app")
.arg(arg);

Then, the following would both be the same, giving the arg input the value foo:
$ app --input foo
$ app foo

 Comment by CreepySkeleton
Friday Apr 17, 2020 at 01:20 GMT

@casey Sorry for the delay.
The whole point of "different types - different arg" is that we want to keep it simple. In clap, an arg defines one entity, whether it's an option or a positional arg. Your proposal introduces a magical switch that goes against this unspoken policy (I repeat, I might have got it wrong), and what's more, a switch for a thing that does something that is already doable with a combination of existing switches.
I see you called required_unless a workaround, but it's pretty much the intended way to do it. It is intentional - I believe - that when you need two separate entities, you create two separate args and specify their mutual relations via requires*, conflicts*, ArgGroup, whatever. This is a difference between "a god option that does multiple (quite unrelated) things" and "a few smaller options that relate to each other somehow".
My opinion is that your CLI is suffering from "multiple ways to do the same thing" syndrome. You probably don't need it, and if you believe you do, be ready to embrace the complexity it brings in.

 Comment by casey
Saturday Apr 18, 2020 at 00:41 GMT

@casey Sorry for the delay.

No worries!

The whole point of "different types - different arg" is that we want to keep it simple. In clap, an arg defines one entity, whether it's an option or a positional arg. Your proposal introduces a magical switch that goes against this unspoken policy

I think that part of the issue is that that's not how my mental model of clap works. I think of args as being the same kind of thing, whether by position, by long flag, or by short flag, and that in the same way that the same arg can have both a long flag and a short flag, they should also be able to be positional as well.

 Comment by CreepySkeleton
Saturday Apr 18, 2020 at 03:25 GMT

Our mental models of clap - and perhaps mindsets - are different, indeed. Let me try to explain it to you (and let's hope you're into math 🙏 ).
A developer comes up with a set of command line options (X) at his fancy. clap needs to map these options to a set of Args (Y). What does this mapping look like?
Your mental model is surjective mapping:

My mental model is bijective mapping:

The reasons I prefer bijection over everything else:

It's easy to implement.

It's easy to understand. Also, most people comprehend it the same way, which is a priceless property.

It's easy to teach. Currently, all I need to explain the difference between "positional arg" and "option" to a newcomer is: "It's positional unless you call Arg::short/long". Dead easy.
With your proposal in mind, I would have to add "... but if you call Arg::positional, your arg may become both positional and not positional. To understand what this means exactly, please go read that part of documentation".

Anyway, I really don't think this option has any value. The thing you want to do is doable with current clap, the problems with keeping multiple options in sync come from redundancy of your CLI - in my opinion, this is a very edge case that is not worthy of it's own dedicated method. Please don't take the later statement as offense or something, I'm just noticing that the very fact that you are the only one who ever came here with such a request so far (IIRC) it very telling.
If many people come here with similar requests I might become open to it, but until then, I'm totally against the inconsistency the proposed option drags along.

 Comment by casey
Monday Apr 20, 2020 at 03:22 GMT

I think it's mostly a matter of perspective: Clap already supports mapping short flags, long flags, and aliases, which could be be considered to be a surjective mapping.

 Comment by kbknapp
Wednesday Apr 29, 2020 at 19:22 GMT

@casey I'm sympathetic to your situation, but I'm afraid it will create some additional confusion and complicate the parsing rules for what subjectively is a niche problem set.
I can see where you come from about all arguments being simply "arguments" and the way they're accessed (via short, long, or position) is just an implementation detail. I'd submit that both you and @CreepySkeleton are correct in your assumptions. All arguments are just arguments, and can pretty easily float between the ways they're accessed (short, long, position, etc.) depending on configuration, however @CreepySkeleton is correct in that internally clap handles these as very distinct types, which allows certain optimizations and rule simplification when parsing. The three "types" for clap are:

positional (no short or long, essentially just a value)
flag (a short or long, but no value)
option (a short or long and associated value)

Clap makes the determination as to which type an argument is early on based on the supplied configuration. Having one argument be multiple types could be rather large internal change.
Also, aliases are not related to this discussion as they're just additional shorts/longs and don't change the base type of the argument. I.e. they're not additional arguments from claps point of view (even if it appears so from the users point of view).

To solve your case, I would suggest two things and I know they're not exactly what you're looking for but in the long run I think its a better solution:

Set your old option to hidden (i.e. don't show it in the help message)
Use required_unless for the new positional argument

Reason being, you are essentially phasing out the old argument. Then on next major version release, you can remove the old option. If you want to go the extra mile, you could first set the option's help message to a deprecation warning, and hide later, or even print a deprecation warning manually if they use the old option.
Essentially you're trying to move your CLI to something more consistent in the future instead of fixing the problem for now but leaving it complicated indefinitely.

 Comment by casey
Thursday Apr 30, 2020 at 00:25 GMT

That all makes sense, although even considering the maintenance burden of keeping two arguments in sync, I think I probably won't deprecate the option:

If all arguments can be passed by option, then the user doesn't need to remember which arguments are passed by position.

I personally sometimes find it hard to remember what positional arguments do, and find options easier to remember.

For scripts, using options can serve as a form of documentation.

I'm not sure that deprecating the option would benefit the end user.

 Comment by kbknapp
Thursday Apr 30, 2020 at 01:22 GMT

I personally sometimes find it hard to remember what positional arguments do, and find options easier to remember.

100% agree. A good general rule of thumb is to have no more than two positional arguments per command or subcommand for exactly that reason.

 Comment by ctrlcctrlv
Monday Oct 25, 2021 at 14:16 GMT

Here's a somewhat minimal (was too lazy to remove some glif2svg options lol) example of how you can hack this together with clap 2.3x despite developers not wanting to add it: https://gist.github.com/ctrlcctrlv/bd0ba2d2a9eb638eec5b5f9dd0ec671e

 Comment by ctrlcctrlv
Monday Oct 25, 2021 at 14:25 GMT

Currently, all I need to explain the difference between "positional arg" and "option" to a newcomer is: "It's positional unless you call Arg::short/long". Dead easy.

So don't implement it that way. Implement it as also_long(&str) and also_short(&str). If you call either on a positional argument, or both, then it becomes also optional.

repo: epage/clapng


text:
Custom headers

Is your feature request related to a problem? Please describe.
Hi, in current project we have an Auth check on the backend (Authorization header.
Without it, backend forbids all requests, also from Ketcher.
I guess that custom headers feature can be widely helpful
Describe the solution you'd like
Patch itself https://gist.github.com/Hellek/136678652331cbc098cf311a07fe08c8
Current interface looks like this
const structServiceProvider = new RemoteStructServiceProvider(
  createBackendRequestUrl('/v2'),
  {
    Authorization: `Bearer ${userStore.token.authToken}`,
  },
)

Dear @Hellek ,
Thank you for your interest to Ketcher.
We will discuss your suggestion internally and put it in our backlog.
Right now I recommend you to create your own StructServiceProvider and pass it as a property to  component  to  solve this issue (please refer to https://github.com/epam/ketcher/blob/master/packages/ketcher-core/src/infrastructure/services/struct/remoteStructServiceProvider.ts as an example)
Regards,
Ketcher team

Verified as fixed on Release 2.5.0.

Guys that is great news!! But there are two extra request where extra headers still not exists. For now we still patching it
diff --git a/node_modules/ketcher-core/dist/index.modern.js b/node_modules/ketcher-core/dist/index.modern.js
index a7a4b85..d457bb9 100644
--- a/node_modules/ketcher-core/dist/index.modern.js
+++ b/node_modules/ketcher-core/dist/index.modern.js
@@ -9605,7 +9605,7 @@ var RemoteStructService = function () {
                 isAvailable = false;
                 _context.prev = 1;
                 _context.next = 4;
-                return request('GET', this.apiPath + 'info');
+                return request('GET', this.apiPath + 'info', null, this.customHeaders);
               case 4:
                 response = _context.sent;
                 indigoVersion = response.indigo_version;
@@ -9689,7 +9689,7 @@ var RemoteStructService = function () {
       var req = request('POST', this.apiPath + "imago/uploads".concat(parVersion), blob, {
         'Content-Type': blob.type || 'application/octet-stream'
       });
-      var status = request.bind(null, 'GET', this.apiPath + 'imago/uploads/:id');
+      var status = request.bind(null, 'GET', this.apiPath + 'imago/uploads/:id', null, this.customHeaders);
       return req.then(function (data) {
         return pollDeferred(status.bind(null, {
           id: data.upload_id

authors: AndreiMazol Hellek ZhannaNovikova

repo: epam/ketcher


text:
Try to register a handle for .pr0 files

Check this:
https://docs.microsoft.com/en-us/microsoft-edge/progressive-web-apps-chromium/how-to/handle-files
https://developer.chrome.com/docs/apps/manifest/file_handlers/
The idea is to be able to open payment request files (.pr0) directly from links or the device's file system.

wrong repo


text:
Improve scrolling performance in UserScreen

This PR improves scrolling performance in the list of matches and puzzles for profiles. This is done in two ways :

the LazyColumn state is no longer read in the composition but rather as a derivedStateOf, reducing and narrowing the scope of recompositions to animate the elevation of the toolbars;
the matches and puzzles are now keyed, which may help with item re-using.

LGTM Thanks !

authors: BadrTad alexandrepiveteau

repo: epfl-SDP/android


text:
Setting individual end times in disposition fails

2021-12-03 14:39:00,166 DEBG 'uwsgi' stderr output:
Traceback (most recent call last):
  File "/home/juhsp/.local/lib/python3.8/site-packages/django/core/handlers/exception.py", line 47, in inner

2021-12-03 14:39:00,167 DEBG 'uwsgi' stderr output:
    response = get_response(request)
  File "/home/juhsp/.local/lib/python3.8/site-packages/django/core/handlers/base.py", line 181, in _get_response

2021-12-03 14:39:00,168 DEBG 'uwsgi' stderr output:
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/home/juhsp/.local/lib/python3.8/site-packages/django/views/generic/base.py", line 70, in view

2021-12-03 14:39:00,168 DEBG 'uwsgi' stderr output:
    return self.dispatch(request, *args, **kwargs)
  File "/home/juhsp/.local/lib/python3.8/site-packages/ephios/core/signup/disposition.py", line 118, in dispatch

2021-12-03 14:39:00,169 DEBG 'uwsgi' stderr output:
    return super().dispatch(request, *args, **kwargs)
  File "/home/juhsp/.local/lib/python3.8/site-packages/django/contrib/auth/mixins.py", line 104, in dispatch

2021-12-03 14:39:00,169 DEBG 'uwsgi' stderr output:
    return super().dispatch(request, *args, **kwargs)
  File "/home/juhsp/.local/lib/python3.8/site-packages/django/views/generic/base.py", line 98, in dispatch
    return handler(request, *args, **kwargs)
  File "/home/juhsp/.local/lib/python3.8/site-packages/ephios/core/signup/disposition.py", line 224, in post

2021-12-03 14:39:00,170 DEBG 'uwsgi' stderr output:
    if not formset.is_valid():
  File "/home/juhsp/.local/lib/python3.8/site-packages/django/forms/formsets.py", line 321, in is_valid

2021-12-03 14:39:00,171 DEBG 'uwsgi' stderr output:
    self.errors
  File "/home/juhsp/.local/lib/python3.8/site-packages/django/forms/formsets.py", line 304, in errors

2021-12-03 14:39:00,171 DEBG 'uwsgi' stderr output:
    self.full_clean()
  File "/home/juhsp/.local/lib/python3.8/site-packages/django/forms/formsets.py", line 355, in full_clean

2021-12-03 14:39:00,172 DEBG 'uwsgi' stderr output:
    for i, form in enumerate(self.forms):
  File "/home/juhsp/.local/lib/python3.8/site-packages/django/utils/functional.py", line 48, in __get__

2021-12-03 14:39:00,172 DEBG 'uwsgi' stderr output:
    res = instance.__dict__[self.name] = self.func(instance)
  File "/home/juhsp/.local/lib/python3.8/site-packages/django/forms/formsets.py", line 155, in forms
    return [
  File "/home/juhsp/.local/lib/python3.8/site-packages/django/forms/formsets.py", line 156, in <listcomp>

2021-12-03 14:39:00,175 DEBG 'uwsgi' stderr output:
    self._construct_form(i, **self.get_form_kwargs(i))
  File "/home/juhsp/.local/lib/python3.8/site-packages/django/forms/models.py", line 632, in _construct_form
    form = super()._construct_form(i, **kwargs)
  File "/home/juhsp/.local/lib/python3.8/site-packages/django/forms/formsets.py", line 193, in _construct_form
    form = self.form(**defaults)
  File "/home/juhsp/.local/lib/python3.8/site-packages/ephios/core/signup/disposition.py", line 31, in __init__
    super().__init__(**kwargs)
  File "/home/juhsp/.local/lib/python3.8/site-packages/ephios/core/signup/methods.py", line 141, in __init__
    instance = kwargs["instance"]
KeyError: 'instance'

A requested participation had been created for the affected shift. It was later changed to use a signup-method that is not using the requested state. Hence the disposition queryset wasn't rendering the requested participation to the template, so the pk was missing in the post data, which lead to a key error when dealing with the POST data.

authors: felixrindt jeriox

repo: ephios-dev/ephios


text:
Pausing with option to hide overlay, added Coachmark.disableCoachmarkTap

Pausing with hide option: can pause -> show other viewcontroller -> do stuff -> resume when coming back.
Coachmark.disableCoachmarkTap: can disable tapping on coachmark to show next (so it can be triggered by tapping on cutoutbutton)

Thanks for working on this. I'm so sorry that it took me nearly 7 months to take a look at this PR.

Coachmark.disableCoachmarkTap: can disable tapping on coachmark to show next (so it can be triggered by tapping on cutoutbutton)

The same effect can be achieved by disabling user interaction on the body view and that's one less thing to maintain. ;)

Pausing with hide option: can pause -> show other viewcontroller -> do stuff -> resume when coming back.

This is actually a cool feature, but I want to take it to the next level in the near future. The ability to truly pause the flow and change dataSource/delegate on the fly is something required to support cross controller walkthrough. I will tackle it in a different way and it should, by extension, support your use case.
I'm not going to merge the PR, but thanks for taking a look at this. 👏

Support landed in 42c41fa.

authors: dazeili ephread

repo: ephread/Instructions


text:
Dynamic paths (aliases, dynamic requires)

This applies only to internal component hadling. Presentation componets should have shortened routes. We do not expect our users to operate IDE effectively or even own one.
For our internal component hadling, relative routes kill IDE support for file operations. Most notable: navigation, move file, find usages. We should use relative paths everywhere.

[ ]  Router

Is:
{
  name: 'TreeView',
  path: '/ui/tree-view',
  component: lazyLoading('ui/tree-view/TreeView'),
  meta: {
    title: 'menu.treeView'
  }
},

Should be:
{
  name: 'TreeView',
  path: '/ui/tree-view',
  component: () => import('../../../components/ui/date-time-pickers/DateTimePickers.vue'),
  meta: {
    title: 'menu.treeView'
  }
},

[ ]  Charts.vue
[ ]  Check other places and add them to this issue

@asvae why require instead of import?

@pfrohner because derp. Thanks for noticing.

@asvae that's arguable, i really hate relative paths and already had a problem while doing project restructure

Fixed already.

authors: asvae pfrohner smartapant

repo: epicmaxco/vuestic-admin


text:
get rid of 'db'subst' and 'ioc.substitution' + make default generate output in /tmp

The substitution file should always be called ioc.subst so ibek generate looks for :

ioc.yaml
st.cmd
ioc.subst
start.sh

and generates from yaml:

st.cmd
ioc.subst
ioc.db

I believe this has been fixed throughout ibek and the scripts that use it but there is at least one place this is still wrong:
def generate(
    instance: Path = typer.Argument(
        ..., help="The filepath to the ioc instance entity file"
    ),
    definitions: List[Path] = typer.Argument(
        ..., help="The filepath to a support module definition file"
    ),
    out: Path = typer.Option(
        default="config/st.cmd",
        help="Path to output startup script",
    ),
    db_out: Path = typer.Option(
        default="config/db.subst",
        help="Path to output database expansion shell script",
    ),
):

defaults SHOULD be

out = /tmp/st.cmd
db_put = /tmp/ioc.subst

done in f7d82deb08596c5a7761eeba70f11ee123a1f5da

repo: epics-containers/ibek


text:
Iowa and Florida data (United States, Subnational)  OBVIOUSLY WRONG.

Hello --
I have to question if any of your members who are responsible for the daily upkeep of your site ever bother to look at the data and simply ask themselves if the data is correct.
Today, both Iowa and Florida data are quite obviously seriously screwed up.  If you do nothing else, at least put some form of quality control into your data entry.  The site is good, but with inconsistent, incorrect data, it is not a reliable indicator of the progress of Covid.

Thank your message. We do not have the capacity to investigate every individual daily estimate, so we're relying on the kind contributions of the likes of yourself to alert us when there is an issue.
The data from many states in the US is subject to strong reporting artefacts, which appear to have been exacerbated by the holidays to a degree that it threw our model in the two instances you mentioned. We've removed these for the time being, and will reinstate them in a few days when things have normalised.

repo: epiforecasts/covid


text:
[Backport to v0.6] Upgrade Grafana to v7.3.5

Backport #1860 to v0.6 branch.

Closing without resolution since we no longer support 0.6.x versions.

repo: epiphany-platform/epiphany


text:
Tiny toolbar covering the content

Describe the bug
Missing the text since it floats up over the display area

@lunchin may need to add an issue to the CMS UI team?

Packages updated.

repo: episerver/Foundation


text:
Review "Equella License Review" and create appropriate tasks

https://confluence.unicon.net/confluence/display/ProServ/Equella+License+Review

Separate out those that will only require documentation (like Oracle dependencies) and note those that require additional discussion

https://docs.google.com/spreadsheets/d/1GYyQ2jdw9IKccQDVt-cpcvgJuI5MuCUgOAzCkr4JIYw/edit#gid=0

License review details license compatibility. We need to to document the dependencies first.

I've added another tab to the spreadsheet which is a dump of the license report from the "sbt-license-report" plugin. This is a list of all the jars required for the server and admin console currently.

Thanks @doolse. I reviewed those entries.

Kaltura is not compatible with Apache. Is this required or can this be an optional download?
Jaxen license requires display of the notice somewhere in the documentation. Can this be replaced by Xalan XPath support?

com.pearson.pdn.icodeon:icodeon-java-sdk is not open source. We need to discuss how to address this dependency.

There is a customized Pearson HTTPInvoker class. Since it's in the equella package and Spring is Apache Licensed, we should be okay.

JPF is LGPL licensed, which means we can only use it unmodified. If we can eliminate the customizations, we should be good.

We need to remove dhfjava if we do not know it's origin.

@doolse do you have time Tuesday (my Monday) to have a call for these items? I would like to create issues to address the above and any other we come across.

Yeah sure, same time as usual should be good, or even 30 mins earlier if you like.

Great, let's go for 30 minutes earlier. I will send you an email with an invite for today.

Pearson icodeon-java-sdk not used
eBay component relies on eCommerce
Jaxen is not directly referenced nor is it a dependency (must be an unnamed dependency dependency)

authors: bjagg doolse emcgarrahan

repo: equella/Equella


text:
Python ccm and kubevip load balancer

Renamed stacks to have different names for the different languages since a project can only be in 1 language
Organization ID is now optional as it is for Equinix.metal.Project
Fix kube-proxy/cni installation, there was a flag to skip kube-proxy installation and CNI was replacing just some of the proxy functions
Fix networking for workers, added routes for bgp neighbors (required for LB)
Added CPEM v3.6.2
Added Kube-vip v0.6.0 for LB
API key for CPEM created on the fly
Exported device information in outputs

Closed in favor of #9


text:
fix: for instantiate entity feature, optional attributes with a default value are included

What does this pull request change?
The instantiate entity endpoint should follow these rules:

all required attributes, as defined in the blueprint, are included.
If the required attribute has a default value, that value will be used.
If not, an 'empty' value will be used. For example empty string,
an empty list, the number 0, etc.
optional attributes with a default value are included
optional attributes without a default value are not included.

This PR fixes the issue that optional attributes with default value are NOT included in the created entity
Also, a refactor of the create_default_array function - it has been moved to a new file and simplified a bit.
Issues related to this change:
closes #469

wait for feedback from @l3abak if the rules for instantiate are correct

repo: equinor/data-modelling-storage-service


text:
First commit

Linked to:
equinor/fiberoptics-das-simulator#3
equinor/fiberoptics-das-simulator#5
equinor/fibra-jsv-flux#67
equinor/fibra-canary#2

PRs:
#3
#5
...will replace this

repo: equinor/fiberoptics-das-simulator


text:
PersonListItem pop-over causes scrollbar

Describe the bug
When a PersonListItem is a certain distance away from the bottom of the screen, it will choose to display the pop-over beyond the current length of the page, causing a scrollbar to appear.
The behavior I see suggests an incorrect calculation of the pop-over height causing the component to think it has enough space below when it hasn't.
To Reproduce
I have created an example in https://codesandbox.io/p/sandbox/optimistic-napier-863sl5. Using absolute position isn't necessary to trigger this issue. Anything that places the PersonListItem close to the end of the page is sufficient.
Steps to reproduce the behavior:

Show a PersonListItem close to the bottom of the page. If it's too close, it will correctly show the pop-over above the PersonListItem. If it's too far away, it will correctly show the pop-over below the PersonListItem. You may have to experiment with the exact distance.
Hover over the PersonListItem to have it show the pop-over.

Expected behavior
The pop-over should be shown just above the bottom of the page.
Screenshots
Correct (80px from the bottom):

Incorrect (130px from the bottom):

Correct (180px from the bottom):

Desktop

OS: Windows
Browser: Firefox 120 and Edge 120 (not a typo, I have version 120 of both)

So expected behaviour is that the popup should chose a direction based on available room. e.g. in the sandbox example the popup should be directed upwards.
This is also the behaviour i would expect.
We have a focus now on getting the people-feature ready for a v1 release.
I have reported multiple observations and concerns..
Will leav issue open and include reference to backlog item when one is defined.

AB#48493

This has been released in the portal and should be resolved.

I can confirm that the issue is fixed in my sandbox, and it also seems to be fixed in https://fusion-s-portal-ci.azurewebsites.net/apps/corporate-project-review/. Thank you

authors: HansDahle asbjornhaland estoksam

repo: equinor/fusion-react-components


text:
Merge develop to main

Pull Request Template
Description
Merge current changes to main
Type of change
How Has This Been Tested?
Not tested
Test Configuration:

Environment:

Checklist:

[x] I have performed a self-review of my own code
[ ] I have commented my code in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have made corresponding changes to the architecture
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes

Trenger en approve til, @eaidland @equinor-jmel

repo: equinor/omnia-timeseries-python


text:
Revoke SSL certificates

Research how to revoke certificates from LetsEncrypt

https://crt.sh/

We have a few options to revoke SSL-certificates; get public and private cert or authorize local machine for the domain we need to revoke certificate for.
The public and private certs is accessible directly from the cluster and we can use certbot CLI to revoke with both these files.
To authorize local machine we have control over DNS and can add a TXT record to validate.
Use this guide to to revoke; https://letsencrypt.org/docs/revoking/ - Both these methods should be tested.

Seems trivial enough. Should test with a cert and then we can close this.

Solution;
kubectl get secret sdp-web-tls -o jsonpath='{.data.tls.crt}' | base64 --decode > crt.pem
kubectl get secret sdp-web-tls -o jsonpath='{.data.tls.key}' | base64 --decode > key.pem
sudo certbot revoke --cert-path ./crt.pem  --key-path ./key.pem
Updating a README somewhere...

authors: esselt soofstad

repo: equinor/sdp-aks


text:
Witsml Explorer UI Enhancements

Fixes
This pull request fixes #1588 , #1589 , #1590 , #1591 , #1592 , #1593 , #1594
Description
GUI Improvements.
Type of change
GUI Improvements

Bugfix
Enhancement of existing functionality
This change requires a documentation update

Impacted Areas in Application
FrontEnd UI Components will be affected including navigation
Checklist:
Please tick all the boxes or remove the ones that aren't needed and explain why
Communication

[x] PR is related to an issue
[ ] I have made corresponding changes to the documentation

Code quality

[x] Code follows the style guidelines
[x] I have self-reviewed my code
[ ] No new warnings are generated

Test coverage

[ ] Existing tests pass
[ ] New code is covered by passing tests

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

Please split this PR into one pull request per issue, starting with issue #1593 and #1594

repo: equinor/witsml-explorer


text:
Factory uses bytes4 to track instanceTypes, this is unjustifiably restrictive

The Factory contract wants to track types of contracts. It does this using a bytes4 type. It seems this is inspired from the ERC-165 standard.
The baseline choice should be using a full 32 byte hash. The bytes4 costs more gas to store, retrieve and compare (EVM stores a whole word, Solidity handles truncation) also it has less collision resistance.
As an author of ERC-165 I think bytes4 is a bad choice here.
Recommendation: use a full word hash
References: Definition https://github.com/erasureprotocol/erasure-protocol/blob/4a3d98ce023a264a9f3c7ba62ef77a9207bba5fe/contracts/modules/Factory.sol#L20

Change would require redeployment of registries, added for v2

authors: fulldecent thegostep

repo: erasureprotocol/erasure-protocol


text:
URL in biblio. display

@michaelnmmeyer — I am sure we have discussed this before, sorry for forgetting what the suituation is.
can URLs not be represented in the same way as DOIs, i.e. as [URL] with hyperlink?
is this why in general we're not displaying URLs recorded in zotero items at all?
and for itemType:website, like this one, we are forced to make an exception due to the nature of the case?

if actually it is possible to display URLs as [URL] with hyperlink, then I'd like all URLs to be displayed including the ones for itemType:website.

There are no restrictions on the bibliography format, we can do what we want, so OK for this.
Displaying websites URLs might still be useful for people who want to print things on paper, or if we want to produce PDF files.

thanks!
I am not inclined to give much (or any) importancre to the needs of people who want to print on paper; in a pdf, I presume the hyperlink could be preserved. closing this for now.

authors: arlogriffiths michaelnmmeyer

repo: erc-dharma/project-documentation


text:
🛑 Twilight is down

In c3789dd, Twilight ($TWILIGHT_IP) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Twilight is back up in 97eee1b after 1 hour, 31 minutes.


text:
Null pointer exception when comparing packages

I created two packages and tried to compare them, but it failed with this error:
System.NullReferenceException: Object reference not set to an instance of an object.
   at InnovatorAdmin.ItemReference.CompareTo(ItemReference other) in c:\Projects\tools\InnovatorAdmin\InnovatorAdmin.Api\ItemReference.cs:line 220
   at System.Collections.Generic.GenericComparer`1.Compare(T x, T y)
   at System.Linq.EnumerableSorter`2.CompareKeys(Int32 index1, Int32 index2)
   at System.Linq.EnumerableSorter`1.QuickSort(Int32[] map, Int32 left, Int32 right)
   at System.Linq.EnumerableSorter`1.QuickSort(Int32[] map, Int32 left, Int32 right)
   at System.Linq.EnumerableSorter`1.Sort(TElement[] elements, Int32 count)
   at System.Linq.OrderedEnumerable`1.<GetEnumerator>d__0.MoveNext()
   at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
   at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
   at InnovatorAdmin.ListCompare.Create[T,TKey](IEnumerable`1 baseList, IEnumerable`1 compareList, Func`2 keyGetter) in c:\Projects\tools\InnovatorAdmin\InnovatorAdmin.Api\Export\ListCompare.cs:line 55
   at InnovatorAdmin.InstallItemDiff.GetDiffs(IEnumerable`1 left, IEnumerable`1 right) in c:\Projects\tools\InnovatorAdmin\InnovatorAdmin.Api\Export\InstallItemDiff.cs:line 65
   at InnovatorAdmin.InstallItemDiff.GetDiffs(InstallScript left, InstallScript right) in c:\Projects\tools\InnovatorAdmin\InnovatorAdmin.Api\Export\InstallItemDiff.cs:line 59
   at InnovatorAdmin.Controls.Compare.Configure(IWizard wizard) in c:\Projects\tools\InnovatorAdmin\InnovatorAdmin\Controls\Compare.cs:line 34
   at InnovatorAdmin.Main.GoToStep(IWizardStep step) in c:\Projects\tools\InnovatorAdmin\InnovatorAdmin\Main.cs:line 155
   at InnovatorAdmin.Controls.CompareSelect.GoNext() in c:\Projects\tools\InnovatorAdmin\InnovatorAdmin\Controls\CompareSelect.cs:line 39
   at InnovatorAdmin.Main.btnNext_Click(Object sender, EventArgs e) in c:\Projects\tools\InnovatorAdmin\InnovatorAdmin\Main.cs:line 189

This happens because other.keyedName is NULL in CompareTo:

repo: erdomke/InnovatorAdmin


text:
No file descriptors available Error

Hi,
After a few hours of running wstunnel as below, I got this error.
wstunnel server wss://[::]:8443

This is my limits info:

This is not related to wstunnel but to your system/workload, file descriptors are not infinite.
Either spread the load on another machine, or if you have too many idle connections, use a reverse proxy to force close inactive connections after a timeout

Hi,
If I run wstunnel like this on the client side, will the problem be solved?
wstunnel client -L 'tcp://0.0.0.0:80:localhost:80?timeout_sec=60' -L 'tcp://0.0.0.0:443:localhost:443?timeout_sec=60' wss://sub.domain.ir:8443
Thanks for your answer

It would indeed, but the timeout is only implemented for udp. As for Tcp we already know when to terminate the connection.
I strongly recommend you installing nginx/haproxy in front of wstunnel to handle those cases.

repo: erebe/wstunnel


text:
not sure how to handle this situation

Imagine I have 3 machines, A, B and C
Machine A and B are behind firewalls.
Machine C hosts a websocket broker service... anything sent to it is sent to any other client connected to it.
On machine B I have a server that can listen on http/https or a unix socket.
How can I connect from machine A to Machine B though Machine C using wstunnel?

Hello, not sure if you can with this setup.
Your broker can forward websockets message, but it needs to establish the connection (as some info are present in the initial http header) for wstunnel to accept connections
something like below may work:

start wstunnel server on machine B listenning on 443
start an other wstunnel server on machine C that listen on a specific port
start a wstunnel client that talk to your broker with a -L 3333:localhost:specific_port on a specific port on machine A
start an other wstunnel client to contact localhost:3333 and try to send some data

authors: Zibri erebe


text:
Trino - Allow login using BasicAuthentication

I'm using reladiff, but the classes mentioned below come from sqeleton.
This is the official conn string for Trino:
trino://<username>:<password>@<hostname>:8080/<database>
But if you try to login using it like
table = connect_to_table(
    f"trino://{TRINO_USER}:{TRINO_PASS}@{TRINO_HOST}/catalog/schema",
    "trino_queries",
    ("query_id"),
)

It throws:
TypeError: Connection.__init__() got an unexpected keyword argument 'password'
For the Trino connection I think we could do something similar the Presto connection is doing here https://github.com/erezsh/sqeleton/blob/master/sqeleton/databases/presto.py#L173
This will allow us to use a db_info like
db_conf_trino = {
    ...
    "user": TRINO_USER,
    "password": TRINO_PASS,
    "auth": "basic",
    "http_scheme": "https",
}

table = connect_to_table(
    db_conf_trino,
    "trino_queries",
    ("query_id"),
)

@erezsh I can help with a pr if you think this makes sense.
Python 3.12.3
reladiff v0.5.1

You're right, currently trino doesn't accept a password.
If you'd like to submit a PR, that would be welcome!

authors: erezsh jkleinkauff

repo: erezsh/sqeleton


text:
command mode bugs

Append new line to commands sent to stdin
Make sure stdin is closed when command mode session is killed, prevents bug causing stdin of executing terminal to no longer display after proctmux exits
remove unneccessary check/sleep when reading stdout of tmux comman mode process

you are on fire dude

authors: erhickey napisani

repo: erhickey/proctmux


text:
[INF] Add pre-commit hooks to repository

Pre-commit hooks are a great way to push code style checks to the development machine, so that they automatically happen and thus we don't have to wait for the CI system to finish to  discover that it failed only on code style.
I will add in instructions to get started with pre-commit,  so that a bunch of checks are automatically done pre-commit.

I was just thinking about proposing optional pre-commit hooks yesterday! awesome

authors: ericmjl hectormz

repo: ericmjl/pyjanitor


text:
Disable invocation and arg actions for rejects.

Throw an exception if invocationActions are added to a reject.
Refer to #434.

Another option would be to stop #define OCMReject(invocation) from returning a recorder which may make a lot of these compile time as opposed to runtime errors.

Actually we need the recorder for .ignoringNonObjectArgs so scratch that idea.

Thanks Erik!

repo: erikdoe/ocmock


text:
Weird issue: not building cross platform with gox

I'm still investigating, so this report might be wrong, but my "gox" build started failing after I included this (very nice package):

--> openbsd/amd64 error: exit status 1
Stderr: go build github.com/erikdubbelboer/gspt: build constraints exclude all Go files in /Users/chlane/go/pkg/mod/github.com/erikdubbelboer/gspt@v0.0.0-20210805194459-ce36a5128377

--> linux/amd64 error: exit status 1
Stderr: go build github.com/erikdubbelboer/gspt: build constraints exclude all Go files in /Users/chlane/go/pkg/mod/github.com/erikdubbelboer/gspt@v0.0.0-20210805194459-ce36a5128377

--> windows/amd64 error: exit status 1
Stderr: go build github.com/erikdubbelboer/gspt: build constraints exclude all Go files in /Users/chlane/go/pkg/mod/github.com/erikdubbelboer/gspt@v0.0.0-20210805194459-ce36a5128377

etc. I won't put the entire thing in there.  Maybe this is an obvious error or something, I'll post more when I figure it out.

It says build constraints exclude all Go files but there are no build constraints in this package. Are you maybe disabling cgo? Cgo is required for this to work.

That must be it then, I didn't do anything to enable CGO in gox ( https://github.com/mitchellh/gox ).  I'll close it as WAD then.

authors: erikdubbelboer jayalane

repo: erikdubbelboer/gspt


text:
[6.2.0] Regression when promise rejects form cannot be submitted again.

As title says, I have a login form that returns 400 on failed login. With 6.2.0 the user cannot retry the login.
With 6.1.1 and below works as expected.

Can u show some code?

Here is an example https://github.com/esbenp/redux-form/commit/790006248f75da71eeea42fb1b11fef406fa1c23
Seems it is due to this conditional https://github.com/erikras/redux-form/blob/master/src/reduxForm.js#L324
When a promise is rejected this.submitPromise will equal the rejected promise on subsequent submits, where as when the submit completes without errors this.submitPromise=undefined. I have not really investigated further, nor do I know if this is wanted behaviour.

authors: esbenp mschipperheyn ruiaraujo

repo: erikras/redux-form


text:
how can I disabled 'enter' for submissing?

how can I disabled 'enter' for submissing?
sometimes , I don't want 'enter' for submissing , I want disabled it。

This issue doesn't belong to our GitHub issue tracker.
We request you to ask again at StackOverflow, using the redux-form tag, then post the question link here.
As usual, don't forget to explain your question well and show what you've got so far!
This is because the GitHub issue tracker is better suited for discussions related to bugs and improvements of Redux Form.
Meanwhile, StackOverflow is better at keeping popular questions visible, while separating feature-related questions from help-related questions.
Thanks for using Redux Form!

authors: gustavohenke lzpBlack


text:
add fields's onChange callback

Thank you very much for this awesome library...
I've faced the problem like https://github.com/erikras/redux-form/issues/330
So I think it's better to add callback to field's onChange.
I've implement in:

https://github.com/joehua87/redux-form/blob/master/src/events/createOnChange.js
https://github.com/joehua87/redux-form/blob/master/src/events/__tests__/createOnChange.spec.js

Even if onChange did support this, you still couldn't call handleSubmit() in your callback because the data won't have filtered down through the props yet. What does this accomplish?

:( Sorry for the wrong code.
I want to submit the form when the field's value changed.
Currently I'm using like this:
onSubmit(event, field) {
  if (field) {
    field.onUpdate(event);
  }
  const {submit, handleSubmit} = this.props;
  handleSubmit((data) => {
    if (field) {
      data[field.name] = event.target.value;
    }
    submit(data);
  })();
}

The JSX:
<Input  {...sort}  onChange={(event) => this.handleSubmit(event, sort)}>
Button onClick={this.handleSubmit.bind(this)}>Search</Button>

I think you are correct in identifying the main problem being with validation, as handleSubmit() is only going to have the old data for validation. But that's a problem with your current solution as well.

Many thanks for answer :)

I've used the below code to submit the form whenever a field changes without tinkering with the fields themselves.
  componentWillReceiveProps(nextProps) {
    if (nextProps.dirty && nextProps.valid) {
      let doubleDirty = false;
      Object.keys(nextProps.fields).forEach(key => {
        if (nextProps.fields[key].value !== this.props.fields[key].value) {
          doubleDirty = true;
        }
      });
      if (doubleDirty) {
        nextProps.handleSubmit();
      }
    }
  }

:+1: Thank you @kyleboyle

@erikras - I am needing to track deltas for form submit, so we don't submit the entire blob. Is @kyleboyle 's approach the best way to deal with that for now? Thank you so much. Great library, so far!

Oh, I've got traversal logic all over the place. :-) But nothing that does this precise thing. Seems like it wouldn't be too hard to make a cousin of getValuesFromState() that only returned the dirty values.

Tried this approach, I am getting issues because calling nextProps.handleSubmit() makes it propagate a "touch" on all inputs, which in turns re-updates the props of everything (and I can't use props.submitting because my submit function isn't a promise, so the prop isn't set).
Haven't figured a way to avoid that, not for the lack of trying.
I am starting to think that it wouldn't be too bad to be able to provide a callback that would be called after any value change, have a onChange config parameter the same way we are able to provide onSubmit.
Another approach I have tried is to just use the asyncValidate, but it feels wrong and I hit a bug (should raise an issue for that), where asyncValidate checks whether a field belongs to ayncBlurFields config using its "actual" name, which fails with dynamic fields : One would have to provide children[0].name, children[1].name etc etc in asyncBlurFields if one want to async validate all the children[].name fields.
So, back to step one, I like your approach but end up having an infinite loop.

@atwam the double dirty check is suppose to stop the recursion. Is your onSubmit function throwing an uncaught exception? I've found that will cause an infinite loop. Also you'll have to verify that the dirty check is working for dynamic / nested fields, I haven't tested that.

@kyleboyle Indeed, it seems to improve once I removed the call to my submit function through handleSubmit
If find it's actually easier for me now to use this.save() rather than this.props.handleSubmit(), bypassing redux-form altogether, given I only get this save method called once everything is valid anyway.

@kyleboyle's solution didn't work for me. When I call nextProps.handleSubmit(); inside componentWillReceiveProps, I get the issue described by #190: You must either pass handleSubmit() an onSubmit function or pass onSubmit as a prop.
Whereas I declared the form tag as documented: <form onSubmit={handleSubmit(submit)}>, where submit is my custom handler, passed down from my form container.
I'm running 5.3.1.

Described the same issue here: http://stackoverflow.com/questions/38902221/redux-form-trigger-form-onsubmit-after-input-onchange

@freen I was using redux 3.5.1, so the api may have changed. I think the principle still applies you just have to figure out the right way to invoke the handleSubmit, I am no longer using this approach in my app so can't go back to verify. did you try handleSubmit(submit)?

@kyleboyle @freen @atwam Where did y'all end up with for this case on v6?

@oyeanuj I'm using 5.3.1 --- can't speak to 6.

authors: atwam erikras freen joehua87 kyleboyle oyeanuj slangeberg


text:
add support for props with nested immutables

Background:
Sometimes, a prop might be a POJO that contains a nested immutable structure. Draft-js' editorState is a great example. Within sCU, the plain deepEqual function is used on it & breaks.
Why this is needed:

Per #2798 the only way to make this work with draft-js is to serialize the editorState.
The beauty of immutables is that we don't have to do a deep equals, comparing references is enough
folks may use different immutable libraries so there is no safe way to ducktype an immutable
folks may have large POJOs that they want to exclude from being deep equaled in sCU. This is a cheap, unobtrusive way to add performance.

Example:
reduxForm({form: 'linkChanger', immutables: ['editorState']})
can bump the docs if you like it

Codecov Report

Merging #3019 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff           @@
##           master   #3019   +/-   ##
======================================
  Coverage     100%    100%
======================================
  Files          67      67
  Lines        1395    1396    +1
======================================
+ Hits         1395    1396    +1

Impacted Files
Coverage Δ

src/createReduxForm.js
100% <100%> (ø)
: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 ac33570...d869c7e. Read the comment docs.

From your description, this sounded like a massive change, and then it only turned out to be two little lines.
So all you're doing is allowing additional "props not to update for" to be specified. It's unclear to me what this has to do with immutability or how it would help with Draft JS. Why are you passing editorState to your form as a prop?

The problem I see, though, is that you are totally ignoring changes to the props listed. It seems like you should be ===ing them, right?
Let's call it immutableProps.

you're correct, i was being selfish & just solving for my use case.
Fixed & documented! if a unit test is needed lemme know where.

Can you get the code coverage back up to 100%?
npm run test:cov
open coverage/lcov-report/index.html

Fantastic!

oh super duper, thank you!

Published in v6.8.0.

authors: codecov-io erikras mattkrick


text:
Allow for latest 100 rebar3 versions when fetching from GitHub

Closes #40.
Also closes #39.
Edit: after this one's approved and merged we could think about 1.7.2, since there's also a recent patch by @wojtekmach in the queue.

Tests are failing because versions I didn't consider would move forward just moved forward due to the rebar3 issue that gave rise to 3.16.1.

@starbelly, wanna give this a quick looksy?

@paulo-ferraz-oliveira Yup, did earlier, merge away, tag away.

authors: paulo-ferraz-oliveira starbelly

repo: erlef/setup-beam


text:
Updated the attribute parser to handle extra attributes aside from just a class and id.

I wanted the ability to be able to add width & height attributes to images but wasn't able to in the current state so I updated the RegEx rules and the parseAttributeData method. Now a user can add something like {.test .fu #bar style="color:red; font-style:italic" data-is-cool="'tis true" lang=en_us} and it'll render out these attributes class="test fu" id="bar" style="color:red; font-style:italic" data-is-cool="'tis true" lang="en_us".
I also added the inlineImage method so attributes like width & height can be added.

:+1:

@PhrozenByte - Updated per your comment and also added the ability to have spaces in the quoted attributes.
On a separate note. Any idea what's up with the tests? Seems travis can't find ParsedownTest.php and has been failing on that before my commits.

Added to my extension with more stable regex parser which will produces:

{#foo} → <tag id="foo">
{#foo#bar} → <tag id="bar">
{.foo} → <tag class="foo">
{.foo.bar} → <tag class="foo bar">
{#foo.bar.baz} → <tag id="foo" class="bar baz">
{#foo .bar .baz} → <tag id="foo" class="bar baz"> (white-space before # and . becomes optional in my extension)
{foo="bar"} → <tag foo="bar">
{foo="bar baz"} → <tag foo="bar baz">
{foo='bar'} → <tag foo="bar">
{foo='bar baz'} → <tag foo="bar baz">
{foo=bar} → <tag foo="bar">
{foo=} → <tag foo="">
{foo} → <tag foo="foo">
{foo=bar baz} → <tag foo="bar" baz="baz">
{#a#b.c.d e="f" g="h i" j='k' l='m n' o=p q= r s t="u#v.w.x y=z"} → <tag id="b" class="c d" e="f" g="h i" j="k" l="m n" o="p" q="" r="r" s="s" t="u#v.w.x y=z">

One vote here to see this merged! It's been around long enough and seems to be part of the MarkDown Extra spec:
https://michelf.ca/projects/php-markdown/extra/#spe-attr
and be wildly useful out in the field!

authors: PhrozenByte bernd-wechner the0neWhoKnocks tovic

repo: erusev/parsedown-extra


text:
Version code differs from tag

At git tag 1.5.2 as well as master branch, there is still const version = '1.5.1'; in code.
Thanks for your effort!

Thanks, this is resolved now.

repo: erusev/parsedown


text:
Invalid instruction variants allowed

The x64asm type system is insufficient for preventing users from requesting instruction such as:
crc32 %r12, %ah
(This shouldn't be allowed due to %r12 requiring a rex prefix.)
This occurs for other instructions in similar situations, such as when a memory operand requires an rex prefix. Fixing this issue will require a major re-architecting. I'd prefer to stay away from this is possible.
Known opcodes with this issue --

crc32
movsx
movzx

I will implement a dynamic check in Instruction::check() for this.  In the future, we might reevaluate the situation and decide to extend the type-system to catch this statically.

authors: eschkufz stefanheule


text:
[FEAT] Available for testing

First, I'd like to thank you for this! Beautiful! :+1:
I have a 49PUS8303 and I'm available for testing any new feature :smile:
Looking forward to MQTT integration also - definitely big progress for home automation...

Hey @mtzro2003, thank you for your kind words! I was not sure if anybody was actually using this script, so I haven't really worked on Pylips recently... (since it already solves my use cases as it is)
So yeah, haven't really realized that people are waiting for updates, will try to do something about MQTT support in the coming week or two... I have a working prototype, just need to polish it a bit.

Hey @mtzro2003, thank you for your kind words! I was not sure if anybody was actually using this script, so I haven't really worked on Pylips recently... (since it already solves my use cases as it is)
So yeah, haven't really realized that people are waiting for updates, will try to do something about MQTT support in the coming week or two... I have a working prototype, just need to polish it a bit.

Hi, forgive my ignorance but will MQTT support have any bearing on input selection (hdmi) or lack of?

@gb160, no, the input selection is not possible with the API - there is nothing I can do as even the official app does not have this functionality. You can do it with ADB, although it is not super reliable in my experience (there is a link somewhere in the beginning of the Readme).

@eslavnov Thats a shame as unfortunately my TV is not Android, its just Linux.
Ive managed to achieve channel switching via CEC commands, but its messy as hell...its a real shame the API has this function missing.
Cheers for the reply anyway.

@mtzro2003, I've pushed a new version with some new commands and MQTT support - would you mind giving it a try? It is basically rewritten from scratch, so I hope I did not break anything, lol

First thing tomorrow morning when I arrive @office. :D
Gonna report back!
On Sun, Apr 21, 2019, 22:11 Evgeny Slavnov notifications@github.com wrote:

@mtzro2003 https://github.com/mtzro2003, I've pushed a new version with
some new commands and MQTT support - would you mind giving it a try? It is
basically rewritten from scratch, so I hope I did not break anything, lol
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/eslavnov/pylips/issues/9#issuecomment-485275291, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAQWPIQ6AEKW6W37CAQIK63PRS36BANCNFSM4HEHULBA
.

Sorry for not being able to report sooner...
Here's what I did so far after upgrading.
As I used pylips from command line with user and password, I put those in settings.ini and tried to run pylips - TV was OFF:
$ cat settings.ini
[DEFAULT]
verbose = True
MQTT_listen = False
MQTT_update = False
num_retries = 3
update_interval = 3
[TV]
host = 192.168.200.33
port =
apiv =
user = XXXXXXXXXXXXX
pass = XXXXXXXXXXXXX
protocol =
[MQTT]
host = 127.0.0.1
port = 1883
user = pylips
pass = XXXXXXXXXXXXXX
TLS = False
topic_pylips =
topic_status =
$  python3 pylips
Checking API version and port...
Trying http://192.168.200.33:1925/6/system
Connection refused
Trying http://192.168.200.33:1925/5/system
Connection refused
Trying http://192.168.200.33:1925/1/system
Connection refused
PING 192.168.200.33 (192.168.200.33) 56(84) bytes of data.

--- 192.168.200.33 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

IP 192.168.200.33 seems to be offline. Exiting...

Question: shouldn't it try to ping first and THEN try to connect to API?
Second, TV ON:
$ python3 pylips.py
Checking API version and port...
Trying http://192.168.200.33:1925/6/system
Traceback (most recent call last):
  File "pylips.py", line 412, in <module>
    pylips = Pylips("settings.ini")
  File "pylips.py", line 72, in __init__
    if self.check_paired() is False:
AttributeError: 'Pylips' object has no attribute 'check_paired'

On line 72, I believe it should be if self.check_if_paired() is False
I added apiv = 6 to settings.ini and it worked:
$ python3 pylips.py
Please enable mqtt_listen in settings.ini or provide a valid command with a '--command' argument

Gonna test it further with MQTT and get back to you

I turned OFF the TV (standby actually), by remote, and pylips reports that it's ON. Here's the JSON that is posted to the MQTT topic:
{"power_on": true, "volume": 0, "muted": true, "cur_app": "org.droidtv.playtv", "ambilight": {"styleName": "FOLLOW_VIDEO", "isExpert": false, "menuSetting": "COMFORT", "stringValue": "Comfort"}, "ambihue": false}

Getting the power state from command line reply:
$ python3 pylips.py --host 192.168.200.33 --user XXXXXXXX --pass XXXXXXXXXXXXXXXXXXXX --command powerstate
Checking API version and port...
Trying http://192.168.200.33:1925/6/system
Sending GET request to https://192.168.200.33:1926/6/powerstate
Request sent!
{"powerstate":"Standby"}

Also, when TV is in standby pylips continues to interrogate the API, querying ambilight config, acivities and audio level.
Maybe, when it detects that the TV is in standby or OFF, it should query only the powerstate.
After a while, it reports that the powerstate changed - TV was responding to ping:
{"power_on": false, "volume": null, "muted": false, "cur_app": "NA", "ambilight": null, "ambihue": false}

Another issue:
If apiv parameter in settings.ini is configured manually, pylips gets no reply from the TV. When I leave it blank, everything is OK:
$ cat settings.ini
[DEFAULT]
verbose = True
MQTT_listen = True
MQTT_update = True
num_retries = 3
update_interval = 3
[TV]
host = 192.168.200.33
port = 1925
apiv = 6
user = XXXXXXXXXX
pass = XXXXXXXXXX
protocol = https://
[MQTT]
host = 127.0.0.1
port = 1883
user = pylips
pass = XXXXXXXXXX
TLS = False
topic_pylips = pylips/Livingroom_TV/command
topic_status = pylips/Livingroom_TV/status
openhab@openhab:~/pylips$ python3 pylips.py
Started MQTT status updater
Sending GET request to https://192.168.200.33:1925/6/audio/volume
Connected to MQTT broker at 127.0.0.1
Sending GET request to https://192.168.200.33:1925/6/audio/volume
Sending GET request to https://192.168.200.33:1925/6/audio/volume
Sending GET request to https://192.168.200.33:1925/6/activities/current
Sending GET request to https://192.168.200.33:1925/6/activities/current
Sending GET request to https://192.168.200.33:1925/6/activities/current
Sending GET request to https://192.168.200.33:1925/6/ambilight/currentconfiguration
Sending GET request to https://192.168.200.33:1925/6/ambilight/currentconfiguration
Sending GET request to https://192.168.200.33:1925/6/ambilight/currentconfiguration
Sending POST request to https://192.168.200.33:1925/6/menuitems/settings/current
Sending POST request to https://192.168.200.33:1925/6/menuitems/settings/current
Sending POST request to https://192.168.200.33:1925/6/menuitems/settings/current
^CTraceback (most recent call last):
  File "pylips.py", line 412, in <module>
    pylips = Pylips("settings.ini")
  File "pylips.py", line 95, in __init__
    self.start_mqtt_updater(self.verbose)
  File "pylips.py", line 409, in start_mqtt_updater
    time.sleep(int(self.config["DEFAULT"]["update_interval"]))
KeyboardInterrupt
openhab@openhab:~/pylips$ nano settings.ini
openhab@openhab:~/pylips$ cat settings.ini
[DEFAULT]
verbose = True
MQTT_listen = True
MQTT_update = True
num_retries = 3
update_interval = 3
[TV]
host = 192.168.200.33
port = 1925
apiv =
user = XXXXXXXXXX
pass = XXXXXXXXXX
protocol = https://
[MQTT]
host = 127.0.0.1
port = 1883
user = pylips
pass = XXXXXXXXXX
TLS = False
topic_pylips = pylips/Livingroom_TV/command
topic_status = pylips/Livingroom_TV/status
openhab@openhab:~/pylips$ python3 pylips.py
Checking API version and port...
Trying http://192.168.200.33:1925/6/system
Started MQTT status updater
Connected to MQTT broker at 127.0.0.1
Sending GET request to https://192.168.200.33:1926/6/audio/volume
Request sent!
{"muted":false,"current":1,"min":0,"max":60}
Sending GET request to https://192.168.200.33:1926/6/activities/current
Request sent!
{"component":{"packageName":"NA","className":"NA"}}
Sending GET request to https://192.168.200.33:1926/6/activities/tv
Request sent!
{"channel":{"ccid":1141,"preset":"117","name":"PRO TV HD"},"channelList":{"id":"allcab","version":"8"}}
Sending GET request to https://192.168.200.33:1926/6/ambilight/currentconfiguration
Request sent!
{"styleName":"FOLLOW_VIDEO","isExpert":false,"menuSetting":"COMFORT","stringValue":"Comfort"}
Sending POST request to https://192.168.200.33:1926/6/menuitems/settings/current
Request sent!
{"values":[{"value":{"Nodeid":2131230774,"Controllable":true,"Available":true,"string_id":"Switch on","data":{"value":false}}}],"version":0}
^CTraceback (most recent call last):
  File "pylips.py", line 412, in <module>
    pylips = Pylips("settings.ini")
  File "pylips.py", line 95, in __init__
    self.start_mqtt_updater(self.verbose)
  File "pylips.py", line 409, in start_mqtt_updater
    time.sleep(int(self.config["DEFAULT"]["update_interval"]))
KeyboardInterrupt

Hey @mtzro2003 , thank you for your input - this is extremely useful!

Question: shouldn't it try to ping first and THEN try to connect to API?

Well yes, but actually no :) PING sometimes takes quite a lot of time to complete, so I am using it purely as a safety net to help me debugging possible problems. So the logic is "Try the endpoints => if no response, then try to ping => let user know what has happened (e.g., if TV is responding to PING, but not the endpoints, then it's probably an API version issue...). So it's a feature, not a bug - although I do admit it's somewhat counter-intuitive. Maybe I should look into PING parameters and set a short timeout or something, I dunno. I'll think about it.

On line 72, I believe it should be if self.check_if_paired() is False

Yep, my bad!

I turned OFF the TV (standby actually), by remote, and pylips reports that it's ON. Here's the JSON that is posted to the MQTT topic:

Great, my TV behaves differently in Standby mode... Sometimes I really hate Phillips...

Maybe, when it detects that the TV is in standby or OFF, it should query only the powerstate.

Yeah, I think this is a good idea given how your TV handles standby mode.

After a while, it reports that the powerstate changed - TV was responding to ping:

Sorry, not sure what you mean here. TV was responding to ping, but Pylips was reporting it as OFF?

If apiv parameter in settings.ini is configured manually, pylips gets no reply from the TV. When I leave it blank, everything is OK:

Thanks, there is a small bug in port discovery (1925 vs 1926), should be easy to fix.
I should be able to make all the fixes today or tomorrow, I'll let you know when it's ready.

After a while, it reports that the powerstate changed - TV was responding to ping:

Sorry, not sure what you mean here. TV was responding to ping, but Pylips was reporting it as OFF?

Here's how my TV, Philips 49PUS8303, behaves when you turn it "OFF" bye remote - OFF is actually a standby, something like when you turn off the screen on an Android phone or tablet:
when I press the OFF button, the screen (of course) turns off, but the TV continues to respond to ping and to API interrogations.
after some time (something like 5 minutes), the TV stops responding to ping and to API
What I meant was that pylips (in MQTT mode) reported the powerstate as ON even is the TV was turned "OFF" by remote. Querying directly the powerstate from command line (pylips old-style) reported that the TV is in standby.
Not sure how to explain further.
I'll wait for the new version and I'll fiddle with it some more...

Got it, thanks! Mine behaves the same with the exception that my "Standby" mode lasts for 5-10 seconds, then it becomes "OFF" and the API stops responding, so I don't really implement a proper "Standby" mode. That's super-easy to fix, will do to.
Thank you again for your help, it's extremely hard to catch all the edge cases with just one TV model...

@mtzro2003 Quick question:

If apiv parameter in settings.ini is configured manually, pylips gets no reply from the TV. When I leave it blank, everything is OK:

So I've noticed that in the first scenario (where you had specified apiv 6) the port is 1925 in the config, that's why it's failing. In the second scenario (with blank apiv) the port is being overriden by apiv discovery, that's why it works.
So the question is: did you manually specify port 1925 in config (then it is working as intended) or was port 1925 added at some point by Pylips (then it's a bug). Thanks!

Damn!
Indeed, there is a typo in settings.ini... My bad! I put the port
manually and it was the wrong one...
The port should be 1926.
On Thu, Apr 25, 2019 at 11:55 AM Evgeny Slavnov notifications@github.com
wrote:

@mtzro2003 https://github.com/mtzro2003 Quick question:
If apiv parameter in settings.ini is configured manually, pylips gets no
reply from the TV. When I leave it blank, everything is OK:
So I've noticed that in the first scenario (where you had specified apiv
6) the port is 1925 in the config, that's why it's failing. In the second
scenario (with blank apiv) the port is being overriden by apiv discovery,
that's why it works.
So the question is: did you manually specify port 1925 in config (then it
is working as intended) or was port 1925 added at some point by Pylips
(then it's a bug). Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/eslavnov/pylips/issues/9#issuecomment-486580187, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAQWPIWJJVZFIO6X62BPJFLPSFWY3ANCNFSM4HEHULBA
.

Nice, one less bug to fix! :) Thanks for a quick response, appreciate it!

I've pushed an update, check it out when you have time! Thanks!

Well, it's running smoothly for 1 day -  no issues so far.
Didn't yet had time to integrate it with openHAB - just 2-3 status items: powerstate, volume and such.
I'll be out of town for the next week so, when I'll get back, I'll dig into it some more.
Wonderful job, @eslavnov, thousand thanks!

Good to hear! Thank you again for your help with the testing!

In the mean time...
How would I use MQTT to retrieve the ambilight brightness for example...
From what I understand, I should post to topic_pylips (in my case pylips/Livingroom_TV/command) a JSON like:
{ "command": "post", "path": "menuitems/settings/current", "body": {"nodes":[{"nodeid":2131230769}]} }

where 2131230769 is the menu entry for ambilight brightness.
But how do I get the return value (JSON) in such a use case?
Also, it looks like I can't get it to work from command line, not MQTT - see below curl is working, but pylips is not, username and password are the same. What am I missing? (pylips is not running in MQTT mode in the example)
$ cat settings.ini
[DEFAULT]
verbose = True
MQTT_listen = True
MQTT_update = True
num_retries = 3
update_interval = 3
[TV]
host = 192.168.200.33
port = 1926
apiv = 6
user = XXXXXXXXX
pass = XXXXXXXXXX
protocol = https://
[MQTT]
host = 127.0.0.1
port = 1883
user = pylips
pass = XXXXXXXXXX
TLS = False
topic_pylips = pylips/Livingroom_TV/command
topic_status = pylips/Livingroom_TV/status

$ python3 pylips.py --command post --path menuitems/settings/current --body '{"nodes":[{"nodeid":2131230769}]}'
Sending POST request to https://192.168.200.33:1926/6/menuitems/settings/current
Request sent!

   <title>Status page</title>

Bad Request

The request could not be understood by the server due to malformed syntax

You can get technical details here.

Please continue your visit at our home page.

$ curl -sS -X POST --digest --insecure -u XXXXXXXX:XXXXXXXXXXXX -d '{"nodes":[{"nodeid":2131230769}]}' https://192.168.200.33:1926/6/menuitems/settings/current
{"values":[{"value":{"Nodeid":2131230769,"Controllable":true,"Available":true,"string_id":"Brightness","data":{"value":2}}}],"version":0}

One more thing: maybe it would be useful to increase the verbosity... For example, to log MQTT messages from subscribed topic and published messaged to the other one...

Hey, so there was a small bug that affected some of the POST requests, I've just pushed a fix and updated README with better examples (see MQTT section), let me know if this helps with your issue. I've also noticed that you are sending different body when using pylips vs curl, so this might also be the reason....

For example, to log MQTT messages from subscribed topic and published messaged to the other one...

You can just subscribe to the MQTT topics from any client and see what's being published, so I am not sure there is much sense in logging it in Pylips...

let me know if this helps with your issue.

Yes, now it's working - same command as above:
$ python3 pylips.py --command post --path menuitems/settings/current --body '{"nodes":[{"nodeid":2131230769}]}'
Sending POST request to https://192.168.200.33:1926/6/menuitems/settings/current
Request sent!
{"values":[{"value":{"Nodeid":2131230769,"Controllable":true,"Available":true,"string_id":"Brightness","data":{"value":2}}}],"version":0}

I've also noticed that you are sending different body when using pylips vs curl

What is different? I don't see any difference between them... But nevermind, now pylips is working :+1:
Moving forward and trying one of your examples: to change brightness through MQTT.
Running
$ mosquitto_pub -h 127.0.0.1 -u pylips -P XXXXXXXXXXXXX -t pylips/Livingroom_TV/command -m '{"command":"post", "path": "menuitems/settings/update", "body": {"values":[{"value":{"Nodeid":2131230769,"Controllable":"true", "Available":"true","string_id":"Brightness", "data":{"value":10}}}]}}'

I saw somewhere on pylips' output a Please provide a 'path' argument error.
Taking a look at the code I noticed the following lines:
                    if message["command"] == "get":
                        if len(path)>0:
                            return print("Please provide a 'path' argument")
                        self.get(path,self.verbose)
                    elif message["command"] == "post":
                        if len(path)>0:
                            return print("Please provide a 'path' argument")

changing the len(path)>0 to len(path) == 0 got it working :smile:
Trying  mosquitto_pub -h 127.0.0.1 -u pylips -P XXXXXXXXXXXX -t pylips/Livingroom_TV/command -m '{"command":"ambilight_brightness", "body":{"value":10}}' doesn't work, but my python knowledge is limited...
python3 pylips.py --command ambilight_brightness --body '{"value":10}' works, but sending the command to MQTT topic doesn't

updated README with better examples (see MQTT section)

Well, the examples are always welcome, but my question was about GETTING the value of ambilight brightness.
Something like below, but using MQTT:
$ python3 pylips.py --command post --path menuitems/settings/current --body '{"nodes":[{"nodeid":2131230769}]}'
Sending POST request to https://192.168.200.33:1926/6/menuitems/settings/current
Request sent!
{"values":[{"value":{"Nodeid":2131230769,"Controllable":true,"Available":true,"string_id":"Brightness","data":{"value":1}}}],"version":0}

How can something like that be archived using MQTT?
I tried posting the following to the topic_pylips:
$ mosquitto_pub -h 127.0.0.1 -u pylips -P XXXXXXXXXXXX -t pylips/Livingroom_TV/command -m '{"command":"post", "path":"menuitems/settings/current", "body":{"nodes":[{"nodeid":2131230769}]}}'

and I see the result in pylips' output:
Request sent!
{"styleName":"FOLLOW_VIDEO","isExpert":false,"menuSetting":"COMFORT","stringValue":"Comfort"}
Sending POST request to https://192.168.200.33:1926/6/menuitems/settings/current
Request sent!
{"values":[{"value":{"Nodeid":2131230774,"Controllable":true,"Available":true,"string_id":"Switch on","data":{"value":false}}}],"version":0}
{"values":[{"value":{"Nodeid":2131230769,"Controllable":true,"Available":true,"string_id":"Brightness","data":{"value":1}}}],"version":0}

but how can I receive the API reply THROUGH MQTT?

What is different? I don't see any difference between them... But nevermind, now pylips is working 👍

Sorry, I've misread your commands, they are indeed the same!

I saw somewhere on pylips' output a Please provide a 'path' argument error.

Yep, I am an idiot :) Thanks for noticing! I really need to research how to write tests in Python...

Trying mosquitto_pub -h 127.0.0.1 -u pylips -P XXXXXXXXXXXX -t pylips/Livingroom_TV/command -m '{"command":"ambilight_brightness", "body":{"value":10}}' doesn't work, but my python knowledge is limited...

Hmm, that's strange - it works for me, I've just tested it. Is the message actually getting published? (use mosquitto_sub to check your topic).

but how can I receive the API reply THROUGH MQTT?

Ah, I see what you mean, but I am not sure how this can be implemented. Since you are just publishing a message over MQTT, you can't really get anything back. I've envisioned this purely as a control method (e.g., "set the brightness to X") as opposed to "get the current brightness" (with the exception of some status items that I manually collect like power, mute, etc.). Theoretically speaking, I can publish a response as an MQTT message on a separate topic, for example, but how are you going to map a specific response to a specific command? If I dump all raw responses into the same topic, it will be a mess of different responses/formats. Creating a separate topic for each command is also not an option (we have 80+ commands). Finally, I could send responses in a format like {"your_command":{...}, "your_response":{...} - this could work, but you still need to write some logic on your side to parse it correctly, so it also kinda sucks.
I would recommend just using the manual mode with --verbose False for such use-cases:
python3 pylips.py --command post --path menuitems/settings/current --body '{"nodes":[{"nodeid":2131230769}]}' --verbose False

{"values":[{"value":{"Nodeid":2131230769,"Controllable":true,"Available":true,"string_id":"Brightness","data":{"value":10}}}],"version":0}

But if you have any better ideas how to handle replies over MQTT, I am all ears...

But if you have any better ideas how to handle replies over MQTT, I am
all ears...

One idea would be to design some configurable (by user) status message...
Something like you have in available_commands.json where someone can add
at any time his own commands.
Could be interesting...
As I'm out of town for the next week, I'll have time to think about it and
maybe come up with a proposal. :smile:
If not feasible, then the pylips in command line mode is the only way -
which is not at all bad.
Once again, excellent job! Many-many-many thanks!!! :laughing:
On Mon, Apr 29, 2019 at 10:50 AM Evgeny Slavnov notifications@github.com
wrote:

What is different? I don't see any difference between them... But
nevermind, now pylips is working 👍
Sorry, I've misread your commands, they are indeed the same!
I saw somewhere on pylips' output a Please provide a 'path' argument error.
Yep, I am an idiot :) Thanks for noticing! I really need to research how
to write tests in Python...
Trying mosquitto_pub -h 127.0.0.1 -u pylips -P XXXXXXXXXXXX -t
pylips/Livingroom_TV/command -m '{"command":"ambilight_brightness",
"body":{"value":10}}' doesn't work, but my python knowledge is limited...
Hmm, that's strange - it works for me, I've just tested it. Is the message
actually getting published? (use mosquitto_sub to check your topic).
but how can I receive the API reply THROUGH MQTT?
Ah, I see what you mean, but I am not sure how this can be implemented.
Since you are just publishing a message over MQTT, you can't really get
anything back. I've envisioned this purely as a control method (e.g., "set
the brightness to X") as opposed to "get the current brightness" (with the
exception of some status items that I manually collect like power, mute,
etc.). Theoretically speaking, I can publish a response as an MQTT message
on a separate topic, for example, but how are you going to map a specific
response to a specific command? If I dump all raw responses into the same
topic, it will be a mess of different responses/formats. Creating a
separate topic for each command is also not an option (we have 80+
commands). Finally, I could send responses in a format like {"your_command":{...},
"your_response":{...} - this could work, but you still need to write some
logic on your side to parse it correctly, so it also kinda sucks.
I would recommend just using the manual mode with --verbose False for
such use-cases:
python3 pylips.py --command post --path menuitems/settings/current --body '{"nodes":[{"nodeid":2131230769}]}' --verbose False
{"values":[{"value":{"Nodeid":2131230769,"Controllable":true,"Available":true,"string_id":"Brightness","data":{"value":10}}}],"version":0}
But if you have any better ideas how to handle replies over MQTT, I am all
ears...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/eslavnov/pylips/issues/9#issuecomment-487481637, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAQWPIVB2JKXBGZWS524YT3PS2SC7ANCNFSM4HEHULBA
.

I'll close this issue for now, please create a separate one with your proposal when you come up with one. Thanks!

repo: eslavnov/pylips


text:
indent-binary-ops: Indentation Adjustment When ‘(’ Is Included in the Logical Expression

Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guide.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.

Describe the bug
There was a formatting behavior related to indentation that changed due to modification A, which caught my attention https://github.com/eslint-stylistic/eslint-stylistic/issues/530, which caught my attention.
after
const a = (
  (flag1
    && flag2)
    || (flag3
      && flag4)
)

before
const a = (
  (flag1
    && flag2)
  || (flag3
    && flag4)
)

Indentation is now deeper when logical expressions are at the same level but contain (.
I would like each logical expression to be indented at the same level when using comparison operators., even if it contain (.
// Cases without (
const a = (
  flag1
  || flag2
  || flag3
)

//  Hope it's the same as above.
const b = (
  (flag1
    && flag2)
  || (flag3
    && flag4)
  || (flag5
    && flag6)
)

I think this is because needAdditionIndent is determined to be true in this section.
// Before the left token is a opening bracket
(['[', '(', '=>', ':'].includes(tokenBeforeAll?.value || '') && firstTokenOfLineLeft?.loc.start.line === tokenBeforeAll?.loc.start.line)

Reproduction
https://stackblitz.com/edit/github-d1geg2?file=src%2Findex.ts
Contributes

[X] I am willing to submit a PR to fix this issue
[X] I am willing to submit a PR with failing tests

Not entirely sure this is the same or a similar scenario, but this one caught my attention when trying to configure Stylistic to taste:

I use the following settings for indent:
'@stylistic/indent': ['error', 2, {
  VariableDeclarator: 'first',
  SwitchCase: 1,
}],

This results in the following error in the scenario above: Expected indentation of 4 spaces eslint[@stylistic/indent-binary-ops](https://eslint.style/rules/plus/indent-binary-ops)
It wants to "correct" it to:
const hasZero = (
  firstCheck
  && [0, 1, 2]
    .includes(0)
    && secondCheck
);

This looks very weird to me, as && secondCheck instinctively should be at the same level as the first two checks.
It doesn't seem possible to configure @stylistic/indent-binary-ops to accept this, so I've turned it off entirely for now 😐

repo: eslint-stylistic/eslint-stylistic


text:
Load jquery, bootstrap and anchor from CDNJS

Use CDNJS to load 3-party libraries with https + http/2.0 support, which is faster and safer.

Sure,  why not. Thanks for doing this.

authors: PeterDaveHello ilyavolodin


text:
Print available, print possible and print request

Convience methods existed for printing available CMOR names based on the table and what could be produced based upon what is available in the output folder.
What is available depended on some hard coded "string" which was a copy of an element of the FORTRAN code. @pgierz does not like this.

from Pavan's pad:
- hardcoded variables names (fortran code block thing).
- Don't know its real purpose. Has no role in processing steps. Sort of dummy

Below a list of the methods related to this issue. We might need them all or not. This issue is to discuss which ones do we include and to track which ones we have already included:

[ ] Print request: Print data request variables for json tables at PATH
[ ] Print available: Prints FESOM output variables available in the specified directory.
[ ] Print possible: Prints variables that FESOM could possibly produce. This is the one @pgierz does not like. I don't love it either.
[ ] match available: Prints matches of FESOM output variables for a given data request.
[ ] match possible: Prints matches of variables that FESOM could possibly produce for a given data request.

authors: mandresm pgierz

repo: esm-tools/pymorize


text:
Request: better handling of DMA buffers for realtime audio using I2S

Background: realtime audio requires low latency, therefore small buffers (like 16-64 samples) are required. Also, with sample rates like 48kHz and above in combination with multichannel audio, copying of data should be avoided.
Currently, the write_dma_circular() method of I2sTx takes a single buffer which has to be of more the 4k size. Any new output data then has to be pushed into the buffer.
The desired solution is to configure two independent buffers of any allowed size (1..4095) bytes that are transferred alternately. These can be of small size to allow low latency. The transfer API should then provide a mutable reference to the buffer that is currently not transferred by the DMA so that it can be filled with new data. Ideally, the API should provide both, a sync and an async method to accomplish this. The async method could work in conjunction with a waker called from a transfer complete interrupt.

Any pointers to a Rust HAL which implements things in a suitable way?

I can't give you an example here, because I'm just familiar with STM32 which is doing things completely different since it does not have a link-list DMA but uses double buffering and half-transfer flags and interrupts.

I'm also not sure if we can safely give mutable access to parts of the DMA buffer - that's why I'm asking for an implementation which does it

That's the reason 2 buffers are needed: you cannot give access to the buffer that is currently transferred. It's even forbidden by the owner bit in the DMA control register. With circular buffers, you always need at least 2, otherwise a continuous transfer cannot be achieved.

If I understand the TRM correctly, you can also append the desciptor list on the fly. So one possible solution to make the handling more secure could be to remove the buffer that is currently filled by the CPU (or read in case when you receive data) and add it back to the lister later after the CPU has done its task.

Sure, our hardware is quite flexible so many solutions are possible

At least as far as I understand it:
The owner bit is not meant to forbid working with the chunk of the buffer that's transferred by the dma descriptor in question. It's basically just to tell you which chunk has been sent to the device and can now be overwritten collision-free (which is important for audio).
From a hardware POV, it's not problematic in anyway to overwrite the buffer while it's being transferred though. This is actively done in the lcd component of esp-idf.

authors: bjoernQ seijikun sourcebox

repo: esp-rs/esp-hal