ESP12E keeps throwing exceptions whenever Token needs to be refreshed

Hi Mobizt,
now I am using oauth2.0 tokens with google analytics 4 API, it seems that the token never gets refreshed successfully, whenever it expires it keeps throwing -4 error connection lost repeatedly until the ESP crashes, sometimes it's OOM exception this time it's exception 29 which is storeprohibitedcause.
I use the token every 30mins, I relied earlier on the fact that it's refreshed automatically but it gave me errors, then added a call to the refresh token function but still the same problem
Am I not having enough memory for my ESP12E?, does the library require anything I am not aware of ?
my code is attached, Arduino IDE
Board: Node MCU V1.0 ( ESP12E )
Core: latest
Please help asap

Code.txt

Library works normally which it was intensively tested long enough over months. This library also used in my other library project without error.
You should debug your code for memory leaks and use ESP exception decoder for decode the stack traces.

For SSL Client usage, you should update your esp8266 core to v3.x.x and set the MMU option in Arduino IDE to gain more heap.
MMU option 3, 16KB cache + 48KB IRAM and 2nd Heap (shared).

The error "connection lost" is about no WiFi connection. Library will check for WiFi status before sending the request to googleapis server to exchange the auth toke. When WiFi was disconnected, library will be trying to reconnect the WiFi by calling WiFi.disconnect() and WiFi.reconnect() and do it in the next 10 seconds if WiFi still lost.
No memory involved for the network checking process during refreshing the token because it calls the callback for reporting the status and exit.
Calling WiFi.disconnect() and WiFi.reconnect()  in the token refreshing process may cause the wdt reset due to low free heap and system tasks may fail to work.
Then you should find why your device free heap is too low and should make sure that you choose MMU option 3 already.

The error "connection lost" is about no WiFi connection. Library will check for WiFi status before sending the request to googleapis server to exchange the auth token. When WiFi was disconnected, library will be trying to reconnect the WiFi by calling WiFi.disconnect() and WiFi.reconnect() and do it in the next 10 seconds if WiFi still lost.
No memory involved for the network checking process during refreshing the token because it calls the callback for reporting the status and exit.
Calling WiFi.disconnect() and WiFi.reconnect() in the token refreshing process may cause the wdt reset due to low free heap and system tasks may fail to work.
Then you should find why your device free heap is too low and should make sure that you choose MMU option 3 already.

Ok, thanks a lot for your reply
I didn't know I should be choosing MMU option 3, you didn't mention it in the library's main page unlike your Firebase Client library, so if you can add it in there will be a big help
Regarding WiFi connection, what you're saying is basically I don't need to manage that myself as the repeated calling causes the wdt resets, is there an option in the library to disable WiFi management ?

There is no option for WiFi reconnection disable and it has no conflicts with WiFiManager library.
If you want to stop library to work when you want, just ignore or skip to execute Signer.tokenReady().

Changing the MMU option solved it for me, amazing library, please add the instructions to choose the shared option in the main page as you only talk about enabling PSRAM there

It's not about the PSRAM in this case but internal memory which sheared between the stack and heap.
This MMU configuration is available in ESP8266 since core v3.0.x which programmer should see the different free heap when update from v2.x.x to v3.0.x. Did you never check this?
Why this MMU option mentioned in my other Firebase and ESP Google Sheet client libraries documentation and does not mention in this library?
It is because changing MMU option from default to option 3 is not required by the library as it has enough free heap for JWT creation, signing and sending auth token exchanging to googleapis server.
My other libraries involved the SSL and TCP session that may be needed to keep open and large memory reserved all the time then I have to write this MMU option in documentation for ESP8266.

There is no option for WiFi reconnection disable and it has no conflicts with WiFiManager library.
If you want to stop library to work when you want, just ignore or skip to execute Signer.tokenReady().

Awesome, will keep that in mind if I ever need to use this library with my own WiFi Manager library

It's not about the PSRAM in this case but internal memory which sheared between the stack and heap.
This MMU configuration is available in ESP8266 since core v3.0.x which user should verify the different free heap when updates from v2.x.x to v3.0.x. Did you never check this?
Why this MMU option mentioned in my other Firebase and ESP Google Sheet client libraries documentation and does not mention in this library?
It is because changing MMU option from default to option 3 is not required by the library as it has enough free heap for JWT creation, signing and sending auth token exchanging to googleapis server.
My other libraries involved the SSL and TCP session that may be needed to keep open and large memory reserved all the time then I have to write this MMU option in documentation for ESP8266.

Great insights, thanks for sharing, your work came in clutch for me as always I really appreciate those libraries, thanks


Multilevel Switch current level value is never refreshed after a Set - Heatit ZDim

Checklist:

[x] My problem is not within Home Assistant or the ZWave JS integration. Or: a Home Assistant developer has told me to come here.
[x] My problem is not within ZWaveJS2MQTT. Or: a ZWaveJS2MQTT developer has told me to come here.
[x] I have checked the troubleshooting section and my problem is not described there.
[x] I have read the changelog and my problem was not mentioned there.

Describe the bug
When toggeling the "Light" swith in Home Assistant, the multilevel switch current level value is never refreshed after a Set
Device information
Which device(s) is/are affected (manufacturer/model)?  Thermofloor Heatit Z-Dim https://devices.zwave-js.io/?jumpTo=0x019b:0x0003:0x2200:0.0
What is/are the node IDs? 031
Did you change anything?

[ ] Yes: (please describe)
[x] No

Did this use to work before?

[x] Don't know, this is a new device <--- I have 20 of them, so not a dud
[ ] No, it never worked anywhere
[ ] Yes, in: (specify application with versions)

How are you using node-zwave-js

[ ] zwavejs2mqtt (latest) docker image
[ ] zwavejs2mqtt (dev) docker image
[ ] zwavejs2mqtt Manual Docker build

node-zwave-js branch:
zwavejs2mqtt branch:

[ ] ioBroker.zwave2 adapter
[x] HomeAssistant version  0.1.21
[ ] Pkg
[ ] Manual Docker build

node-zwave-js branch:
zwavejs2mqtt branch:

[ ] node-red-contrib-zwave-js

Module version (double click node):

[ ] Manually built (as described in the docs)
[ ] Other:

To Reproduce
Steps to reproduce the behavior:

Go to 'the dimmer in for instance home assistant'
Click on 'toggle the "light" switch
It will stay on for a second or so before switching off (the ui switch), the light itself turns on at previous level

Additional context
Not operating properly breaks the home assistant lovelace frontend card for the dimmer. If one toggles the binary switch, the "light" switch will turn on, and stay on. However as the frontend operates on the "light" switch, this does not help
Logfile:
zwave_debug_log.zip
zwave_js_dump.zip
When toggeling the dimmer, the multilevel Switch current level value is never refreshed after a set. This makes the dimmer unusable with the HomeAssistant Lovelace UI.

Logs from pastebin: logs.txt
I told @henrikeri to submit this issue, because it looks like the Multilevel Switch Set is supervised, but the Supervision Report doesn't seem to provide anything from what I can tell, so the current value is never refreshed. On the other hand, the Binary Switch Set is not supervised, and the node responds on its own with Binary and Multilevel Switch reports.

@kpine So you think we need to disable Supervision?

@zwave-js-bot add compat flag to 0x019b:0x0003:0x2200:0.0
"commandClasses": {
			"remove": {
				"0x6c": {
					// The device does not support supervision although it is mandatory for the device type
					"endpoints": "*"
				}
			}

@zwave-js-bot add compat flag to 0x019b:0x0003:0x2200:0.0
"commandClasses": {
			"remove": {
				"0x6c": {
					"endpoints": "*"
				}
			}

@zwave-js-bot add compat flag to 0x019b:0x0003:0x2200:0.0
"commandClasses": {
	"remove": {
		"0x6c": {
			"endpoints": "*"
		}
	}
}

@AlCalzone See the error message on the bot. It looks like there is a bug in the code.

@kpine So you think we need to disable Supervision?

It came to mind, but I couldn't remember what was supposed to actually happen with Supervision and setting the target value to 0xFF (last level).

I staged the PR but I'm not actually sure this is right:
2021-05-20T21:31:41.487Z DRIVER » [Node 031] [REQ] [SendData]
                                  │ transmit options: 0x25
                                  │ callback id:      128
                                  └─[SupervisionCCGet]
                                    │ session id:      56
                                    │ request updates: true
                                    └─[MultilevelSwitchCCSet]
                                        target value: 255
2021-05-20T21:31:41.489Z SERIAL « [ACK]                                                                   (0x06)
2021-05-20T21:31:41.496Z SERIAL « 0x0104011301e8                                                       (6 bytes)
2021-05-20T21:31:41.496Z SERIAL » [ACK]                                                                   (0x06)
2021-05-20T21:31:41.497Z DRIVER « [RES] [SendData]
                                    was sent: true
2021-05-20T21:31:41.513Z SERIAL « 0x010700138000000368                                                 (9 bytes)
2021-05-20T21:31:41.513Z SERIAL » [ACK]                                                                   (0x06)
2021-05-20T21:31:41.514Z DRIVER « [REQ] [SendData]
                                    callback id:     128
                                    transmit status: OK
2021-05-20T21:31:41.528Z SERIAL « 0x010b0004001f056c0238ff0043                                        (13 bytes)
2021-05-20T21:31:41.528Z SERIAL » [ACK]                                                                   (0x06)
2021-05-20T21:31:41.529Z DRIVER « [Node 031] [REQ] [ApplicationCommand]
                                  └─[SupervisionCCReport]
                                      session id:          56
                                      more updates follow: false
                                      status:              Success
                                      duration:            [Duration: 0 seconds]

It does see a Supervision report back. @AlCalzone ?

Supervision is not the problem - its the fact that we don't refresh the value after setting it to 255.

I got in contact with Thermofloor today, they were aware of the issue and supplied an OTA firmware update that resolves the issue.

they were aware of the issue and supplied an OTA firmware update that resolves the issue.

So the expected behavior is that the device reports the actual status on its own?
That's good to know but we still need to handle those device that don't.

they were aware of the issue and supplied an OTA firmware update that resolves the issue.

So the expected behavior is that the device reports the actual status on its own?
That's good to know but we still need to handle those device that don't.

I would assume that's the expected behaviour given the fact that they did have an OTA update ready. However, they did not specifically elaborate as to wheter this expected or not.


use open api of alphaess

I modified the code to allow the usage of the openAPI branch of the alphaess python library

Thank you for all this work.  I have one comment and one conversation I need to have....
First the easy comment - even if this isn't part of core Home Assistant I am trying to follow their best practices.  One best practice is only to use modules that are hosted on Python Package Index PyPI.  I'd suggest modifying the PR to use a manifest.json file that refers to a named and version specific library rather than a github connection to an external module.
Which brings me on to the conversation.  I had originally hoped to just cut-over to the official Open API for AlphaESS as soon as it was available.  Unfortunately the Open API is still missing some data which is available in the unofficial API.  Should I continue to hold off on publishing a true release of both the library and/or the Home Assistant integration or should I go ahead and effectively internally fork my own work to be able to chose which to rune - legacy setup or new stuff.

Thank you for all this work. I have one comment and one conversation I need to have....
First the easy comment - even if this isn't part of core Home Assistant I am trying to follow their best practices. One best practice is only to use modules that are hosted on Python Package Index PyPI. I'd suggest modifying the PR to use a manifest.json file that refers to a named and version specific library rather than a github connection to an external module.
Which brings me on to the conversation. I had originally hoped to just cut-over to the official Open API for AlphaESS as soon as it was available. Unfortunately the Open API is still missing some data which is available in the unofficial API. Should I continue to hold off on publishing a true release of both the library and/or the Home Assistant integration or should I go ahead and effectively internally fork my own work to be able to chose which to rune - legacy setup or new stuff.

To facilitate that conversation can you share what data is available in the current integration that isn't supported via the official API?

To facilitate that conversation can you share what data is available in the current integration that isn't supported via the official API?

The most significant difference is in the aggregation of detail, for example the current unofficial API is able to provide instantaneous power details for two separate strings of panels.  The official API only provides an overall combined figure.  I know there are some folk using the Home Assistant integration who like to have the figures broken out (for example south facing compared to another orientation).  Anyone needing the more segregated information will be taking a step backwards if there is just one set of code.  @Spookster was it yourself who had asked for the more detailed figures?  I know there is an open request from @joitde to add individual voltage figures, again I presume those are unlikely to be available from the Official API as it is today.
I am interested in trying to get consensus or at least a majority point of view on the trade off between moving entirely to the Official API vs forking this code base to provide options for Official vs Unofficial.

I'm not using AlphaESS PV - just a battery - so this would not effect me. However, I can understand what others would choose not to lose functionality, so I think am option to adopt the official API or stay with the legacy unofficial API would be best for this community.

To be fair, I havent had a look at the 'official' API as I didnt want to beta test the interface.
I was hoping for a more fully featured option from them, but it seems to be a hobby project at present

One of the initial concerns from the 'official' developer was the number of server requests that would be handled
My preference and #1 want is network access to the data, hence I wasnt interested in another external option. Local data, Problem solved

Closing as the integration has now moved to using the Official Open API.


does reduxMountPoint support paths instead of a single key?

I've gotten in the habit of telling a lot of redux components/actions the path where the their state is found within the redux state.  This makes for maximum reusability as it can be used on redux state living absolutely anywhere.  Is it possible to do that with this library?

reduxMountPoint is going away in v6. You should use getFormState, which should provide you with all the flexibility you could need.


Add TLS support

The nodes should be able to set up a TLS connection.
Node-Red already provides a "tls" internal node which is used by the "mqtt" node for configuring TLS (CA certificate, private key, ...) and maybe it's possible to reuse the same node for this purpose.

Hi there. I'm trying to connect the plugin to an Eclipse Hono broker in order to receive messages from the AMQP backend. However, the plugin doesn't want to connect (the receiver node keeps saying "Disconnected"). Has anyone tried this before ? The official Hono Java sample works fine.

I was also struggeling with TLS, because I was using the officially released v0.0.2 that is available on NPM. V0.0.2 doesn't come with support for TLS yet.
When do you plan to release a new version so that the additional changes make it to the NPM package registry and somebody who installs this library through nodeRED or via npm by name gets TLS support?
Right now instead of
yarn add node-red-contrib-rhea
I have to use
yarn add https://github.com/amqp/node-red-contrib-rhea#master

@Whitewater81 did you solved that problem? I'm in the same situation..


#38: Add an auto-incremental id to jobs

This will solve #38 : Add autoincremental id to jobs.
This new Job parameter, a number (although a wrapper is going to be created as part of the issue) will be included in the message, mandatorily.
When the first job of a queue is created, the id will be 0 (zero), incrementing for each new job in the queue.

@yeraydavidrodriguez Great Work :)


Set up travis to publish new versions of the extension when we tag a release

Though we have published the first version of the extension manually (https://marketplace.visualstudio.com/items?itemName=camel-tooling.yo) we need to set up the automated process to do the same thing.
We should be able to use a method similar to the LSP VSCode extension (https://github.com/camel-tooling/camel-lsp-client-vscode/blob/81802cba0dafd888746d2bec67f6bf75c923f238/.travis.yml#L22)

Uncommented and will test when we release the next version


[NAV350] NAVPoseData yaw incorrect

Hello folks,
I am in the process of writing a ROS2 node that combines the localisation data from 2 NAV350s. I have already successfully started two instances of the driver and get scan and reflector data displayed correctly in RViz (including transformation via my robot URDF).
For the combiner node I now wanted to use the "/sick_nav350/nav_pose" topic to query additional things like "pose_valid" or "infostate". I noticed that "pose_yaw" is apparently not sent in the ROS coordinate system but in the scanner coordinate system (0° backwards instead of forwards). Can anyone confirm this behaviour? If so, is this the intended behaviour? All other data (LaserScan etc) use the "correct" ROS coordinate system, which ensures that you can use either the scan data (0° forwards) or the pose data (0° backwards) with your URDF.
Thanks in advance!

Thanks for your feedback. Topic "/sick_nav350/nav_pose" publishes the original data from the NAV-350 without transforms (just converted to a ros message). This is intended. ROS Pointcloud- and Laserscan- messages are transformed to ROS coordinates.

Thanks for the answer! Then I will rotate the data in the downstream node.
One suggestions: I would rephrase the comment here to "pose in ros units" instead of " pose in ros coordinates". This would avoid confusion in the future.

@p0rys Thanks for the hint! We will correct the comment.


Prompt before closing pane with multiple client apps

Description of the new feature/enhancement
Some console apps, like vim, neovim, far, etc, are ignored when you accidentally hit Ctrl+W and your unsaved work is gone forever.

Proposed technical implementation details (optional)
I'm not sure how to do that, but it would be nice to offer an API or something to block closing if some return code is not met.

You know, I was going to just close this as a combo of #5301, #2976 and #5065. However, none of those cover this specific case, where we prevent closing a terminal tab/pane when there's more than one client in the process tree.
We really don't have a comprehensive discussion of all these requirements anywhere, do we?

I want to never be prompted for confirmation
I want to be prompted for confirmation when I close the window with multiple tabs
I want to be prompted for confirmation when I close a tab with multiple panes
I want to be prompted for confirmation when I close a pane with multiple clients
I want to be prompted for confirmation when I close a pane always
possibly more scenarios?

Uhg, so the way I see it is something like this

which is, unwieldy to fill out, and I'm not super passionate about filling in right now. If someone has a better idea, please feel free to chime in.

You know, I was going to just close this as a combo of #5301, #2976 and #5065. However, none of those cover this specific case, where we prevent closing a terminal tab/pane when there's more than one client in the process tree.
We really don't have a comprehensive discussion of all these requirements anywhere, do we?
Scenarios

I want to never be prompted for confirmation

I want to be prompted for confirmation when I close the window with multiple tabs

I want to be prompted for confirmation when I close a tab with multiple panes

I want to be prompted for confirmation when I close a pane with multiple clients

I want to be prompted for confirmation when I close a pane always

possibly more scenarios?

I want to be prompted for confirmation when I close a pane with multiple clients, but I don't care about closing multiple tabs/panes with a single client in each.

Furthermore, we've only got one setting so far - confirmCloseAllTabs. This basically enables 1 and 2. #5874 enables 3 for everyone, without a way to opt-out.

@zadjii-MSFT I think your comment is covered with #2976

Okay yea, i should have been more specific. We want to enable settings to enable/disable the prompts for each of these scenarios. Just prompting before the user quits, regardless of the content, isn't something that I think most people want.
Maybe it's gotta be a flag enum?
enum ConfirmOnClose
{
  Never = 0x0,
  MultipleProcesses = 0x1,
  MultiplePanes = 0x2,
  MultipleTabs = 0x4,
  Always = 0x8,
}

I'm adding the Always as another flag, for "I want to be prompted always, even if there's only one process in one pane in one tab"

Alright, I think I filled out actually just half this table, but here's an update

I'm not sure the "multipleTabs" columns of this table will be informative, but I might do them monday.
Now I need to make sure that the above scenarios are all reflected as actual cells in this grid.

Alright, I think I've done this as comprehensively as possible:

We've also got a bunch of scenarios listed above, so to re-iterate:
Scenarios

I want to never be prompted for confirmation
I want to be prompted for confirmation when I close the window with multiple tabs
I want to be prompted for confirmation when I close a tab with multiple panes
I want to be prompted for confirmation when I close a pane with multiple clients
I want to be prompted for confirmation when I close a pane always
possibly more scenarios?
I want to be prompted for confirmation when I close a pane with multiple clients, but I don't care about closing multiple tabs/panes with a single client in each.
I want to be prompted always, even if there's only one process in one pane in one tab

The above chart was made with one key assumption. There are basically three actions - closePane, closeTab, and closeWindow. Each one of these actions fundamentally also performs each of the preceding actions on all of the panes/tabs within the tab/window. If any of the preceding actions wants to warn the user, then the executed action should wait for the warning.
So if the user wants to be warned when they close multiple panes in a single tab, and they try to closeWindow a window which has a single tab with multiple panes, that should wait for a warning to be shown.
In my understanding, scenario 5 is no different than scenario 8.
I also considered another setting structure that was more like:
closePaneWarning: ["never", "multipleProcesses", "always"]
closeTabWarning: ["never", "multiplePanes", "always"]
closeWindowWarning: ["never", "multipleTabs", "always"]

This would be a more expressive set of settings with 27 possible combinations (as opposed to the 9 unique cases above). However, if we stick with the same assumption as above, I'm not sure there are actually 27 unique cases. If any child warning "infects" a parent command, then I hypothesize these 27 cases would simplify down to the same 9 cases.
This raises the question if our original assumption is useful or not. Do users really want to be able to be warned when they closeTab with multiple panes, but not when they closeWindow with a tab with multiple panes (simultaneously)? That doesn't really make sense to me. I'm sure there's some user out there who might want that behavior, but I'd argue that it's confusing enough that most users wouldn't want it and it would lead to more confusion than not.

So, in my opinion, using the ConfirmOnClose: [Never, MultipleProcesses, MultiplePanes, MultipleTabs, Always] values make sense to me, and seem to get us the full level of fidelity that would be expected.
Now it's another matter of

how exactly do we express this setting
technically, how do we get a pane close warning to prevent the window from closing?

This includes questions like: "if the user tries to close the window and one tab doesn't want to close, then do we wait until all that tab's warning is accepted before closing any tabs? What if two tabs want to warn on an exit?"

@zadjii-msft I read your comment with the szenarios. What technicality means "multiple processes"? Does this means two pames where aech of them is running a process (e. g. ssh connection)?

"multiple processes" means that in any pane, there's more than just the immediately attached child running. So case in point would be launching ssh.exe from your "Command Prompt" profile. In that case, the immediate child is cmd.exe, but there's a child of that cmd.exe (the ssh.exe).
It notably could mean one tab, one pane, but in that pane is multiple processes.

@zadjii-msft
Isn't this a by design behavior? So if a process is runing in cmd it always have multiple processes? Then imo the case will be "on running processes/jobs" and not "on multiple processes", which can be confusing.

Yea? In this case "multiple processes" === "on running processes/jobs".

Yea? In this case "multiple processes" === "on running processes/jobs".

@zadjii-msft
What do you want to say with the question mark behind Yea?

... nothing in particular? It's just what my inner monologue said when I read your comment 😄

Since #11335 was set as a duplicate of this, the scope of the issue needs to be widened.
I want this warning in all cases.

Is it still active issue?
#11335 Maybe simply hide [X] tab button option for some profiles(but keep context menu). Stateless apps will be happy when you'll can't close them by miss click

Yea, it's active in the sense of "we'd like to get to this soon", we've just had other priorities in front of it. Basically, we need to take my comment above, turn it into a spec, get consensus on that, and then just do the work. The actual warning isn't hard, but making sure there's a set of unambiguous settings for all use cases is 😄

My current workaround for this is to always open two tabs, and that way I can get a confirmation whenever I'm closing a Terminal window. But having the ability to confirm on close when Neovim has unsaved work would be at the top of my wishlist for sure.
Has there been any progress on this? Even if the options aren't added in the GUI, if we could just set them in the .json, that would be fantastic.

Yea, it's active in the sense of "we'd like to get to this soon"

Any chance this has been spec'd and / or is slated for kind of soon-ish? 😊

Unfortunately not. This keeps on treading water just below the cut line, unfortunately. I might be able to sneak the spec work in soon, but certainly won't have the cycles to do the dev work.

Appreciate the update! Any progress is good progress if you are indeed able to sneak that spec work in!

I find this specification too complex.
https://github.com/microsoft/terminal/issues/6549#issuecomment-675494526
I believe useful progress can be made by implementing the most critical case which is closing a tab that is in the middle of running some application.

That's actually probably the hardest to implement, because currently the Terminal doesn't really track the whole process tree of things spawned by the Terminal. We'd have to do that first, and plumb that all through.
Big-picture, when I'm writing specs, I find that it's usually best practice to enumerate all the related scenarios in a single doc. That way, designs for a single part won't conflict with the requirements for other related parts.
Ultimately, I think that design ends up being pretty elegant for every possible scenario that we've been asked for. Just one setting that can cover all these use cases seems like best case scenario:
// Just prompt always
"confirmOnClose": "always",

// Prompt on multiple processes, but not for multiple panes/tabs
"confirmOnClose": "multipleProcesses",

// combine flags
"confirmOnClose": ["multipleProcesses", "multiplePanes", "multipleTabs"]

Does the the terminal "own" the X icons on tabs? Because my own case is mostly just that I accidentally close tabs when I mean to activate them, so if it that button could confirm instead of just killing, that would -- I think -- solve that part without needing to track down all spawned processes, etc.

This close button without prompt is definitely for me the worst part of Windows terminal.
I'm always have multiple pane, and sometime I click to change tabs, and too often I hit the X and it closes the entire split tab... A confirm would have been nice :(
I've use the workaround described in another issue to hide the X icons:

Open JSON settings file
Search for the entry "themes":
For me, I use the "Dark" theme, so I took the default settings of the dark theme and I added the "showCloseButton": "never" entry.

Full example:
    "themes":
    [
         {
            "name": "dark NO CLOSE BUTTON",
            "tab":
            {
                "background": "terminalBackground",
                "iconStyle": "default",
                "showCloseButton": "never",
                "unfocusedBackground": "#00000000"
            },
            "tabRow":
            {
                "background": null,
                "unfocusedBackground": "#333333FF"
            },
            "window":
            {
                "applicationTheme": "dark",
                "experimental.rainbowFrame": false,
                "frame": null,
                "unfocusedFrame": null,
                "useMica": false
            }
        }
    ]

NB: I can now close tabs with CTRL+W or MiddleMouseButton.

I just closed a tab that I had active work in as I had switched to another tab and wanted to go back... Most of my navigation is done with the keyboard and for my use case I never want to close a terminal tab with the mouse, never ever ever. I can type Ctrl-D or  exit or whatever and actually shut down my shells... I literally never ever want to close the window when the command shell is running.... (unless there's a runaway process maybe but then ProcExp will find that.)
I would be satisfied enough with a "do you want to close" confirmation any time I hit the X but honestly I would prefer to have the X button just gone. I get what the above poster has done to create a theme without the close button but now I'd have to figure out how to clone my current theme... and this is not something that has anything to do with theming. (Why would a rando user want a theme to decide the behavior of the close button?)
In my opinion the above matrix is way overwrought. There are three options for each of two settings and they are disjoint:

closing tabs with UI: don't/disable (e.g. hide the close button), always warn, just do it without warning
closing application: don't/disable (e.g. hide the close button), always warn, just do it without warning

Sure, getting more complicated for things like looking at the process tree is all fine and good but for almost every single person commenting above it was, "I was trying to switch tabs and I closed it instead." That is what should be addressed and then worry about the rest. Another way to go would be to "never close a not-foreground tab", and maybe that's easiest... but the accidental tab closures are not limited to background tabs. (Personally, I find any application that allows you to mutate state with the mouse when it is not in focus to be terrifying because inevitably something is changed with a mouse click and you have no way to know what.)

This can be implemented more easily once Windows Terminal is its own console server. Of course, that doesn't work for ssh, but that can't ever work. Always showing a confirmation message would be in line with how other terminals behave.


HTML based plots that work responsively?

mpld3 plots are nice but they aren't responsive to changes in screen size.
Is there some other javascript package that will do this (even if it doesn't work with matplotlib)?

Chart.js looks promising.
It even allows for click events on data points. link

Basic example of clickable datapoints taken from stackoverflow
<html>
    <head>
        <script type="text/javascript" src="http://code.jquery.com/jquery-2.0.2.js"></script>
        <script type="text/javascript" src="Chart.js"></script>
        <script type="text/javascript">
            var data = [
                {
                    value: 300,
                    color:"#F7464A",
                    highlight: "#FF5A5E",
                    label: "Red"
                },
                {
                    value: 50,
                    color: "#46BFBD",
                    highlight: "#5AD3D1",
                    label: "Green"
                },
                {
                    value: 100,
                    color: "#FDB45C",
                    highlight: "#FFC870",
                    label: "Yellow"
                }
            ];

            $(document).ready(
                function () {
                    var ctx = document.getElementById("myChart").getContext("2d");
                    var myNewChart = new Chart(ctx).Pie(data);

                    $("#myChart").click(
                        function(evt){
                            var activePoints = myNewChart.getElementsAtEvent(evt);
                            var url = "http://example.com/?label=" + activePoints[0].label + "&value=" + activePoints[0].value;
                            alert(url);
                        }
                    );
                }
            );
        </script>
    </head>
    <body>
        <canvas id="myChart" width="400" height="400"></canvas>
    </body>
</html>


Previous results naming

Results can be saved and named after running a model.
Configurations can be uploaded.
Results and config can be downloaded.

redundant


Add fontawesome cdn domains to whitelist. Solves #59

I don't see any reason for not adding fontawesome cdn domains to the list.
pro.fontawesome.com
use.fontawesome.com

@pahakalle Thanks for the PR. Merging.


Is it possible to add storage functionality (permanent rather than temporary history) to the search and replacement surface of VS.

Is it possible to add storage functionality (permanent rather than temporary history) to the search and replacement surface of VS.
Some commonly used search and replace content, hoping to be stored as XML file.
Simply select when needed, including search and replace content, without the need to re-enter each time.
It is permanent, not just a historical record.
Adobe Indesign has done a great job in this area and is worth referring to.
Thank you very much~

Have you tried using the Search Editor? You can store search configuration and results to your disk and restore it another time.

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


Allow setting permissions and default_permission on context_menu and cog_context_menu

Discord's permissions API allows setting permissions on any application commands including the newly added context menu commands. We should expose these options as well in this library, for example
@slash.context_menu(
    target=ContextMenuType.MESSAGE,
    name="commandname",
    guild_ids=[12345678],
    default_permission=False,
    permissions={
        12345678: [create_permission(99999999, SlashCommandPermissionType.ROLE, True)],
    }
)
async def commandname(ctx: MenuContext):
    await ctx.send(content="whatever")

I've verified that the @slash.permission and @cog_ext.permission decorators are correctly emitting the permission setting api calls. However without the ability to set default_permission it's not possible to restrict commands only to specific roles.
This seems like only a matter of adding some missing parameters being given hardcoded values, so I'm happy to submit a PR if it helps.

I'll most likely address this with v4.0 instead because we'll be utilizing different class object logic.


call + pop pattern not handled by default

In shellcode, this pattern is used quite often. It uses a combination of call + pop to load the address of a string into a register.

Note, the default behavior is even more problematic -- the disassembly would continue to disassemble the string "VirtualProtect" and produce garbage. To get what is shown in the image, I have already set the function to a no-return to stop the control flow.
The tricky part of this is there is no easy way to handle this. If we wish to patch the code, the space is not enough. We would have to create a new segment and put some code there, which is complex

One person has used this example as support for having IDA-style define/undefine data/code, but I believe that is NOT the best way to handle this. That will break the continuity of control flow

Related to #4428

We already handle the "call +5" case https://github.com/Vector35/arch-x86/blob/ce54c270537a36255608cd1f67df64f971558d0e/il.cpp#L1237-L1242. But this cannot be easily changed to handle "call + pop", since the lifter only has the info of the current instruction, it cannot know the target of the call is an pop instruction.

While I was looking at https://github.com/Vector35/binaryninja-api/issues/5583, an idea suddenly strikes me, that setting the called function as no-return and then get it inlined might help with the situation. I created a monimal PoC and it seems to be working! As verified by the API, our analysis actually knows rdx is 0x5 after the pop

oxfoo1m3.zip
A relevant binary

Here is the database containing the code shown in the 1st screenshot in this issue:
ffmodule.exe.bndb.zip
The code originally looks like this:

Setting the function sub_1400173d4 to be inlined does seem to fix the code at the IL level. However, the disassembly still goes on wildly regardless:

Setting the function sub_1400173d4 to be inlined and no-return does fix the code at the IL level, but the disassembly is not continuing, which is not ideal:


Html Formatter not working when use style attribute

VSCode Version: 1.8.1
OS Version: win8.1

Html formatter is not working when attribute style is applied to an element.

duplicates #17637


added shortcuts

Closes https://github.com/caskroom/homebrew-cask/issues/16151.
Alternatively, we could call this lock-logout-restart-shutdown-sleep. The number of utilities should only increase, though, so that may not be the best idea. Since this is a collection of apps, it might warrant this exception.

Wouldn't suite 'system', :target => 'Shortcuts' be more appropriate in this case?

Wouldn't suite 'system', :target => 'Shortcuts' be more appropriate in this case?

That sounds about right. I always considered it (even when originally discussing the rule) as the case to use only when necessary (i.e. it wouldn’t work without it), but it makes sense to do it for a group of related applications as well (and looking at it, we even considered that case in the documentation).

That sounds about right. I always considered it (even when originally discussing the rule) as the case to use only when necessary (i.e. it wouldn’t work without it), but it makes sense to do it for a group of related applications as well (and looking at it, we even considered that case in the documentation).

Merged as 397b3ce5bba476c535e79bead4ea47c045fdaaf5.

Merged as 397b3ce5bba476c535e79bead4ea47c045fdaaf5.


Move distributor to its own package

Fixes #16
Will need post-merge review #97

Had completely forgot about #16, otherwise would have done this myself. Thanks!
LGTM.

I was just looking for low hanging fruit as a diversion.
On Mon, Nov 7, 2016 at 4:48 AM, Jonathan Lange<EMAIL_ADDRESS>wrote:

Had completely forgot about #16
https://github.com/weaveworks/cortex/issues/16, otherwise would have
done this myself. Thanks!
LGTM.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/weaveworks/cortex/pull/104#issuecomment-258827028,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAbGhaIpBMOzLNfmTJ_gC7HAkvHepMG0ks5q7x4QgaJpZM4Kqo-I
.


Replace most common emojis with colorful emoticon text in minecraft

For example, replace 😄 with §6:D§r

There are now support for 30 different kind of emoji. Might add more later.


AutoSPInstaller Example Code

#398
Added Example that would take an AutoSPInstaller.xml file and generate a DSC Configuration. This is still in a preliminary stage, but wanted to put in a pull request to solicit feedback on approach before I go too far down the rabbit hole.

[X] Change details added to Unreleased section of changelog.md?
[NA] Added/updated documentation and descriptions in .schema.mof files where appropriate?
[NA ] Examples updated for both the single server and small farm templates in the examples folder?
[X] New/changed code adheres to Style Guidelines?
[ ] Unit and Integration tests created/updated where possible?

This change is

Hi @mrpullen, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by Microsoft and real humans are currently evaluating your PR.
TTYL, MSBOT;

My bad. I branched from another pull request. I will clean up the MSFT_SPWebApplication updates tomorrow from this branch. Let me know if this fits with the basic idea of getting DSC to work with the SPAutoInstaller, or if you want to refactor to make the entire thing cleaner. It might be nice to "convert" the XML into a $Configuration hash table or something so we would have a standard object to work with, then pass in the object instead of passing in the XML.

I will review this one when I get a little more time, but gut feeling says we are on the right path. Shooting from the hip a couple of thoughts:

I think we might need to look at the credential management stuff in a little more detail. I wanna run some tests to make sure they encrypt right
I think I want to move the folder out of that examples folder, but will give that some thought too
We will need to look at unit testing for this, but again I want to give that some thought too

I'll get back to a full review ASAP though

Reviewed 1 of 4 files at r2.
Review status: 1 of 3 files reviewed at latest revision, all discussions resolved, some commit checks failed.

Comments from Reviewable

Another option, and maybe something that would work better would be to write a function that would take the XML and just generate a PowerShell data file. Then we could just build a standard Configuration that would take the PowerShell data file configuration. The benefit is that once you ran the script you would be back in "native" DSC land. I might work up a quick sample of this as well. We could push all the specifics into a data file like.
Uploaded a quick sample of what I thought that might look like

@mrpullen I'm not sure about the second one, I think as a middle ground the initial idea of just parsing the xml like you have to start with is the better approach to take on this one.

Ok. Will finish up on an xml parser.

I am going to build this out as a set of composite resources. That way each "top level" XML node can be broken out, making testing each specific piece a bit simpler. I am going to close this PR and submit a new one once that's ready. Finishing a project now, but this will be first up on my list once I am clear.


How to make the modal background transparent.

Is there a way to present a modal that instead of having a white background as it is by default. It has a transparent or blurred background ? currently the blurred option in MZ just blurs the outside background of the modal.
I intent to have a ViewController that is showing a camera feed, and I would like to present a modal on top of that, with blurred background so I can still see the camera refreshing in the back.

Check the Objective-C example there is one case for that and probably you are interested to present using style: OverCurrentContext on MZFormSheet..

Thanks, I ended up using the blurred effect, changed the size of the presented view controller, and setting to 0 the top inset. These are all MZForm settings. But indeed I need to configure the "overCurrentContext" of the presented view controller to have its background transparent as clear color.


Update go-packages.csv

@ronniegeraghty what's the procedure for deprecation? I emptied the RepoPath for sdk/cognitiveservices/azopenai because that package is deprecated, however CI requires a value for that field.

@ronniegeraghty what's the procedure for deprecation? I emptied the RepoPath for sdk/cognitiveservices/azopenai because that package is deprecated, however CI requires a value for that field.

Yes, even if the package is deprecated the RepoPath field needs to stay filled. When a package is deprecated, the Support column should be set to "deprecated" and the ReplaceGuide column should be filled with a link to any available migration guide. If none exists, then put NA in the ReplaceGuide column.


E-FishLicense

The fishing license is to be digitized, replacing the paper form. The digital license will include a photo for validation by inspectors.

.


[Go Live][Dec 09]

Push to live

Docs Build status updates of commit 8bb5638:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/index.yml
:white_check_mark:Succeeded
View

msteams-platform/m365-apps/extend-m365-teams-message-extension.md
:white_check_mark:Succeeded
View

msteams-platform/m365-apps/extend-m365-teams-personal-tab.md
:white_check_mark:Succeeded
View

msteams-platform/m365-apps/images/toolkit-search-sample.png
:white_check_mark:Succeeded
View

msteams-platform/m365-apps/overview.md
:white_check_mark:Succeeded
View

msteams-platform/m365-apps/prerequisites.md
:white_check_mark:Succeeded
View

msteams-platform/m365-apps/using-teams-client-sdk-preview.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


weave-npc blocking connections in Kubernetes with no NetworkPolicies (2.6.0)

What you expected to happen?
weave-npc to allow all network connections
What happened?
We upgraded weave in our Kubernetes cluster from version 2.4.1 to 2.6.0 ~2 weeks ago. We've been experiencing intermittent network issues since then. In the pod logs I've noticed multiple applications unable to communicate with other pods in the cluster.  When I checked weave-npc logs, I noticed a ton of blocked connections:
WARN: 2020/01/27 18:45:42.924357 TCP connection from <IP_ADDRESS>:38490 to <IP_ADDRESS>:18000 blocked by Weave NPC.
WARN: 2020/01/27 18:45:42.924378 TCP connection from <IP_ADDRESS>:47620 to <IP_ADDRESS>:80 blocked by Weave NPC.
WARN: 2020/01/27 18:45:45.100358 TCP connection from <IP_ADDRESS>:33848 to <IP_ADDRESS>:8080 blocked by Weave NPC.
WARN: 2020/01/27 18:45:45.100381 TCP connection from <IP_ADDRESS>:38510 to <IP_ADDRESS>:18000 blocked by Weave NPC.
WARN: 2020/01/27 18:45:45.100390 TCP connection from <IP_ADDRESS>:33848 to <IP_ADDRESS>:8080 blocked by Weave NPC.
WARN: 2020/01/27 18:45:46.796350 TCP connection from <IP_ADDRESS>:38510 to <IP_ADDRESS>:18000 blocked by Weave NPC.
WARN: 2020/01/27 18:45:47.884357 TCP connection from <IP_ADDRESS>:47620 to <IP_ADDRESS>:80 blocked by Weave NPC.
WARN: 2020/01/27 18:45:47.884380 TCP connection from <IP_ADDRESS>:33848 to <IP_ADDRESS>:8080 blocked by Weave NPC.
WARN: 2020/01/27 18:45:47.884387 TCP connection from <IP_ADDRESS>:38510 to <IP_ADDRESS>:18000 blocked by Weave NPC.
WARN: 2020/01/27 18:45:49.260360 UDP connection from <IP_ADDRESS>:38592 to <IP_ADDRESS>:53 blocked by Weave NPC.
WARN: 2020/01/27 18:45:49.260381 UDP connection from <IP_ADDRESS>:38592 to <IP_ADDRESS>:53 blocked by Weave NPC.
WARN: 2020/01/27 18:45:49.260389 UDP connection from <IP_ADDRESS>:42516 to <IP_ADDRESS>:53 blocked by Weave NPC.
WARN: 2020/01/27 18:45:49.260395 UDP connection from <IP_ADDRESS>:42516 to <IP_ADDRESS>:53 blocked by Weave NPC.
WARN: 2020/01/27 18:45:49.260401 UDP connection from <IP_ADDRESS>:52150 to <IP_ADDRESS>:53 blocked by Weave NPC.

Note that we don't have any network policies in our cluster:
$ kubectl get networkpolicies --all-namespaces
No resources found.

How to reproduce it?
I'm unsure how to actually "trigger" the blocked connections.  As soon as I saw the timeouts I downgraded weave to 2.4.1 in our cluster to get it back up and running. We don't observe this behavior in 2.4.1.
It should be noted that we went to 2.4.1 instead of 2.5.2 since we suffered from the default-deny of traffic until network policies are validated which was introduced in 2.5 (and discussed in this issue: https://github.com/weaveworks/weave/issues/3464).
Anything else we need to know?
Kubernetes v1.15.6
managed w/ Kops
running in AWS
Versions:

$ weave version: 2.6.0
$ docker version
Client:
 Version:           18.06.3-ce
 API version:       1.38
 Go version:        go1.10.3
 Git commit:        d7080c1
 Built:             Wed Feb 20 02:28:26 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.3-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       d7080c1
  Built:            Wed Feb 20 02:26:51 2019
  OS/Arch:          linux/amd64
  Experimental:     false

$ uname -a
Linux ip-172-20-118-147 4.9.0-11-amd64 #1 SMP Debian 4.9.189-3+deb9u1 (2019-09-20) x86_64 GNU/Linux

$ kubectl version:
Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.6", GitCommit:"7015f71e75f670eb9e7ebd4b5749639d42e20079", GitTreeState:"clean", BuildDate:"2019-11-13T11:20:18Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.6", GitCommit:"7015f71e75f670eb9e7ebd4b5749639d42e20079", GitTreeState:"clean", BuildDate:"2019-11-13T11:11:50Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}

Not that I don't have Logs or IP tables output since I don't have any nodes running v2.6.0 currently since I've downgraded everything.  If needed I can see about updating back to 2.6.0.
It should be noted that other than the numerous blocked connections I didn't see anything remarkable in the weave or weave-npc container logs. I did not inspect the IP tables.

@chrisghill thanks for reporting the issue.

We've been experiencing intermittent network issues since then.

Could you please elobrate what symptoms you have noticied? Are you using default CIDR (<IP_ADDRESS>/12) for Weave or different CIDR? Reason I ask is from the weave-npc logs it seems connections are blocked are hotsts in different CIDR's <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS> etc

I've got the same problem.
Here are the logs
ubuntu@ip-10-21-157-154:~$ sudo docker ps | grep weave
986975948a24        174e0e8ef23d                                                             "/home/weave/launch.…"   12 days ago         Up 12 days                              k8s_weave_weave-net-qkcgt_kube-system_4721554a-4289-11ea-99e3-0a82cb5b9985_1
2bc401cb2118        weaveworks/weave-npc                                                     "/usr/bin/launch.sh"     12 days ago         Up 12 days                              k8s_weave-npc_weave-net-qkcgt_kube-system_4721554a-4289-11ea-99e3-0a82cb5b9985_0
bffeab27e086        k8s.gcr.io/pause-amd64:3.0                                               "/pause"                 12 days ago         Up 12 days                              k8s_POD_weave-net-qkcgt_kube-system_4721554a-4289-11ea-99e3-0a82cb5b9985_0

ubuntu@ip-10-21-157-154:~$ sudo docker exec -ti 986975948a24 /home/weave/weave --local status

        Version: 2.6.0 (up to date; next check at 2020/02/10 22:06:21)

        Service: router
       Protocol: weave 1..2
           Name: 0e:8b:bc:6c:af:28(ip-10-21-157-154.ec2.internal)
     Encryption: disabled
  PeerDiscovery: enabled
        Targets: 26
    Connections: 27 (27 established)
          Peers: 28 (with 756 established connections)
 TrustedSubnets: none

        Service: ipam
         Status: ready
          Range: <IP_ADDRESS>/12
  DefaultSubnet: <IP_ADDRESS>/12

root@ip-10-21-157-154:~# docker logs --tail 1000 2bc401cb2118 2>/tmp/logs

root@ip-10-21-157-154:~# grep blocked /tmp/logs | tail -10
WARN: 2020/02/10 20:35:11.722769 UDP connection from <IP_ADDRESS>:37587 to <IP_ADDRESS>:53 blocked by Weave NPC.
WARN: 2020/02/10 20:35:11.722812 UDP connection from <IP_ADDRESS>:37587 to <IP_ADDRESS>:53 blocked by Weave NPC.
WARN: 2020/02/10 20:35:11.722828 UDP connection from <IP_ADDRESS>:57715 to <IP_ADDRESS>:53 blocked by Weave NPC.
WARN: 2020/02/10 20:35:11.722840 UDP connection from <IP_ADDRESS>:57715 to <IP_ADDRESS>:53 blocked by Weave NPC.
WARN: 2020/02/10 20:35:11.722854 UDP connection from <IP_ADDRESS>:37950 to <IP_ADDRESS>:53 blocked by Weave NPC.
WARN: 2020/02/10 20:35:11.722868 UDP connection from <IP_ADDRESS>:37950 to <IP_ADDRESS>:53 blocked by Weave NPC.
WARN: 2020/02/10 20:35:11.722906 TCP connection from <IP_ADDRESS>:40068 to <IP_ADDRESS>:8080 blocked by Weave NPC.
WARN: 2020/02/10 20:35:11.722920 TCP connection from <IP_ADDRESS>:50472 to <IP_ADDRESS>:8080 blocked by Weave NPC.
WARN: 2020/02/10 20:35:11.722936 UDP connection from <IP_ADDRESS>:55513 to <IP_ADDRESS>:53 blocked by Weave NPC.
WARN: 2020/02/10 20:35:11.722949 UDP connection from <IP_ADDRESS>:55513 to <IP_ADDRESS>:53 blocked by Weave NPC.

root@ip-10-21-157-154:~# iptables-save | grep DROP
:KUBE-MARK-DROP - [0:0]
-A KUBE-MARK-DROP -j MARK --set-xmark 0x8000/0x8000
-A FORWARD -o weave -j DROP
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A KUBE-FIREWALL -m comment --comment "kubernetes firewall for dropping marked packets" -m mark --mark 0x8000/0x8000 -j DROP

@kostyrev please open a seperate bug with complete weave-npc logs, dump of iptables and ipset and details of any network policies applied

@murali-reddy thanks but I decided just to disable npc because I don't use network policies anyway.
just in case if anyone needs quick fix
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')&disable-npc=true"

This is also an issue for us.
I have a v1.17.6 Kubernetes cluster deployed via kops 1.17.0 that installs weave 2.6.2

We have no network policies installed.

$ kubectl get networkpolicies --all-namespaces
No resources found

Weave Status

$ kubectl -n kube-system exec -it weave-net-9mfc2 -- ./weave --local status

        Version: 2.6.2 (up to date; next check at 2020/06/09 04:44:51)

        Service: router
       Protocol: weave 1..2
           Name: 2e:a0:a6:72:c7:7c(ip-10-8-90-217.ap-southeast-2.compute.internal)
     Encryption: disabled
  PeerDiscovery: enabled
        Targets: 32
    Connections: 32 (32 established)
          Peers: 33 (with 1056 established connections)
 TrustedSubnets: none

        Service: ipam
         Status: ready
          Range: <IP_ADDRESS>/11
  DefaultSubnet: <IP_ADDRESS>/11

ps entries showing the kube-proxy --cluster-cidr lining up with the weave ipalloc-range value

root      6180  6162  0 Jun08 ?        00:00:31 /usr/local/bin/kube-proxy --cluster-cidr=<IP_ADDRESS>/11 --conntrack-max-per-core=131072 --hostname-override=ip-10-8-35-150.ap-southeast-2.compute.internal --kubeconfig=/var/lib/kube-proxy/kubeconfig --master=https://<IP_ADDRESS> --oom-score-adj=-998 --v=2 --logtostderr=false --alsologtostderr --log-file=/var/log/kube-proxy.log

root      7719  7645  0 Jun08 ?        00:06:24 /home/weave/weaver --port=6783 --datapath=datapath --mtu 8192 --name=7e:4c:54:dc:81:1b --host-root=/host --http-addr=<IP_ADDRESS>:6784 --metrics-addr=<IP_ADDRESS>:6782 --docker-api= --no-dns --db-prefix=/weavedb/weave-net --ipalloc-range=<IP_ADDRESS>/11 --nickname=ip-10-8-35-150.ap-southeast-2.compute.internal --ipalloc-init consensus=30 --conn-limit=200 --no-masq-local <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS>

Relevant parts from the kops network configuration for the cluster with some <- comments showing what uses the subnets.

  additionalNetworkCIDRs:
  - <IP_ADDRESS>/16                         <- Additional VPC Subnet we created for Kube (See subnets below)
  networkCIDR: <IP_ADDRESS>/16              <- VPC Subnet (contains AWS resources like Memcached, Redis, RDS)
  nonMasqueradeCIDR: <IP_ADDRESS>/10      <- Pods, Services
  subnets:
  - cidr: <IP_ADDRESS>/19                  <- Nodes
    egress: nat-0c140307fe5cfddc3
    name: ap-southeast-2a
    type: Private
    zone: ap-southeast-2a
  - cidr: <IP_ADDRESS>/19                  <- Nodes
    egress: nat-0dc48c2c278755238
    name: ap-southeast-2b
    type: Private
    zone: ap-southeast-2b
  - cidr: <IP_ADDRESS>/19                  <- Nodes
    egress: nat-082f1f6547b7cc981
    name: ap-southeast-2c
    type: Private
    zone: ap-southeast-2c
  - cidr: <IP_ADDRESS>/22                   <- Internal LB
    name: utility-ap-southeast-2a
    type: Utility
    zone: ap-southeast-2a
  - cidr: <IP_ADDRESS>/22                   <- Internal LB
    name: utility-ap-southeast-2b
    type: Utility
    zone: ap-southeast-2b
  - cidr: <IP_ADDRESS>/22                   <- Internal LB
    name: utility-ap-southeast-2c
    type: Utility
    zone: ap-southeast-2c

Important AWS resources within our VPC.

Redis: <IP_ADDRESS>
Memcached: <IP_ADDRESS>, <IP_ADDRESS>
RDS r/w: <IP_ADDRESS>
RDS r/o: <IP_ADDRESS>

Following are random examples of log entries showing  blocked connections.
To pods/services in the same Kube cluster...
WARN: 2020/06/08 06:10:20.698359 TCP connection from <IP_ADDRESS>:39446 to <IP_ADDRESS>:8200 blocked by Weave NPC.
WARN: 2020/06/08 06:03:56.195224 TCP connection from <IP_ADDRESS>:53362 to <IP_ADDRESS>:9200 blocked by Weave NPC.

To nodes in the cluster...
WARN: 2020/06/08 06:10:20.698315 TCP connection from <IP_ADDRESS>:44590 to <IP_ADDRESS>:443 blocked by Weave NPC.

To AWS Redis, RDS, & Memcached within the VPC...
WARN: 2020/06/08 06:09:19.329505 TCP connection from <IP_ADDRESS>:53104 to <IP_ADDRESS>:6379 blocked by Weave NPC.
WARN: 2020/06/08 06:07:21.137738 TCP connection from <IP_ADDRESS>:37366 to <IP_ADDRESS>:5432 blocked by Weave NPC.
WARN: 2020/06/08 06:07:17.916156 TCP connection from <IP_ADDRESS>:51984 to <IP_ADDRESS>:11211 blocked by Weave NPC.

To a public address..
WARN: 2020/06/08 06:05:19.486866 TCP connection from <IP_ADDRESS>:50504 to <IP_ADDRESS>:443 blocked by Weave NPC.

Plenty of connection were working too, otherwise we would have had a full outage.
These blocks appear to be random, and result in semi-regular timeouts in various parts of our applications.
This is a production cluster so I've removed the NPC container from the daemonset afterwards (and set EXPECT_NPC=0 on the  weave container) since we have no network policies anyway, and this stops the traffic from being blocked.

@jim-barber-he Are the connections really blocked, or you are just seeing log messages saying they are?
It could be a timing thing - the first packet can be dropped before netfilter is updated, but TCP will retry shortly afterward and nothing is really blocked.

We seem to have connection timeouts occurring in our jobs, so it looks like they are really blocked.

@jim-barber-he please open a new issue and supply logs.

All I've got is what I supplied above.
Production is the only cluster that gets enough traffic to see the problem, and we're not willing to run weave-npc on it because its causing issues with our production applications.

Hello, same problem here.
k version --short
Client Version: v1.17.3
Server Version: v1.17.3

Logs:
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.770207 UDP connection from <IP_ADDRESS>:48243 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.770225 TCP connection from <IP_ADDRESS>:56854 to <IP_ADDRESS>:8080 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.770240 UDP connection from <IP_ADDRESS>:50157 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.770252 UDP connection from <IP_ADDRESS>:41309 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.827087 UDP connection from <IP_ADDRESS>:44588 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.839587 UDP connection from <IP_ADDRESS>:50070 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.839610 TCP connection from <IP_ADDRESS>:41222 to <IP_ADDRESS>:3128 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.839889 UDP connection from <IP_ADDRESS>:47313 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.839909 UDP connection from <IP_ADDRESS>:51281 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.839920 UDP connection from <IP_ADDRESS>:49717 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.839933 TCP connection from <IP_ADDRESS>:58080 to <IP_ADDRESS>:3128 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.900280 UDP connection from <IP_ADDRESS>:53244 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.900320 UDP connection from <IP_ADDRESS>:39520 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.900334 UDP connection from <IP_ADDRESS>:34770 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.900345 UDP connection from <IP_ADDRESS>:42984 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.900362 TCP connection from <IP_ADDRESS>:49844 to <IP_ADDRESS>:3128 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.900373 UDP connection from <IP_ADDRESS>:56910 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.900383 UDP connection from <IP_ADDRESS>:43250 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.900397 UDP connection from <IP_ADDRESS>:41626 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.900415 UDP connection from <IP_ADDRESS>:39687 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.951314 UDP connection from <IP_ADDRESS>:53369 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.951332 TCP connection from <IP_ADDRESS>:45138 to <IP_ADDRESS>:3128 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.951343 UDP connection from <IP_ADDRESS>:52342 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.951355 UDP connection from <IP_ADDRESS>:42649 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.951365 UDP connection from <IP_ADDRESS>:42744 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.951386 UDP connection from <IP_ADDRESS>:53798 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.951405 TCP connection from <IP_ADDRESS>:42222 to <IP_ADDRESS>:5432 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.951437 UDP connection from <IP_ADDRESS>:46769 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:11.951448 UDP connection from <IP_ADDRESS>:49686 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:12.035726 UDP connection from <IP_ADDRESS>:38544 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:12.035746 TCP connection from <IP_ADDRESS>:42224 to <IP_ADDRESS>:5432 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:12.035757 TCP connection from <IP_ADDRESS>:42226 to <IP_ADDRESS>:5432 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:12.035768 TCP connection from <IP_ADDRESS>:42228 to <IP_ADDRESS>:5432 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:12.035780 TCP connection from <IP_ADDRESS>:42232 to <IP_ADDRESS>:5432 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:12.035792 TCP connection from <IP_ADDRESS>:42230 to <IP_ADDRESS>:5432 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:12.035805 UDP connection from <IP_ADDRESS>:42616 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:12.035817 UDP connection from <IP_ADDRESS>:56818 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:12.035828 UDP connection from <IP_ADDRESS>:47116 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:13.038099 UDP connection from <IP_ADDRESS>:57161 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:13.038112 UDP connection from <IP_ADDRESS>:35883 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:13.038130 TCP connection from <IP_ADDRESS>:36762 to <IP_ADDRESS>:5432 blocked by Weave NPC.
weave-net-z9sqg weave-npc WARN: 2020/06/29 20:30:13.038151 TCP connection from <IP_ADDRESS>:36168 to <IP_ADDRESS>:443 blocked by Weave NPC

ks exec -it weave-net-npt9n -c weave -- /home/weave/weave --local status

        Version: 2.6.0 (failed to check latest version - see logs; next check at 2020/06/30 03:32:26)

        Service: router
       Protocol: weave 1..2
           Name: 44:1f:c6:a6:ed:b3(********)
     Encryption: disabled
  PeerDiscovery: enabled
        Targets: 5
    Connections: 5 (5 established)
          Peers: 6 (with 30 established connections)
 TrustedSubnets: none

        Service: ipam
         Status: ready
          Range: <IP_ADDRESS>/12
  DefaultSubnet: <IP_ADDRESS>/12

Looks like connections (TCP && UDP) are randomly denied.
Please, tell me which command I can run to help in debugging this.

I really like Weave products (net, flux, scope) but, for now, I think I will disable Weave NPC. That's a shame because I was setting up Network Policies. I guess I'll try to make it differently, with Istio.
Here are some more traces of random traffic blocked:
weave-net-g4dpt weave-npc WARN: 2020/07/06 16:10:06.742199 UDP connection from <IP_ADDRESS>:47604 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-sgcc9 weave-npc WARN: 2020/07/06 16:10:07.637841 TCP connection from <IP_ADDRESS>:54080 to <IP_ADDRESS>:5432 blocked by Weave NPC.
weave-net-sgcc9 weave-npc WARN: 2020/07/06 16:10:07.637899 UDP connection from <IP_ADDRESS>:40649 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-sgcc9 weave-npc WARN: 2020/07/06 16:10:07.637915 UDP connection from <IP_ADDRESS>:47895 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-sgcc9 weave-npc WARN: 2020/07/06 16:10:07.637938 UDP connection from <IP_ADDRESS>:34244 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-sgcc9 weave-npc WARN: 2020/07/06 16:10:07.637952 UDP connection from <IP_ADDRESS>:33357 to <IP_ADDRESS>:53 blocked by Weave NPC.
weave-net-sgcc9 weave-npc WARN: 2020/07/06 16:10:07.637963 TCP connection from <IP_ADDRESS>:48736 to <IP_ADDRESS>:5432 blocked by Weave NPC.
weave-net-g4dpt weave-npc WARN: 2020/07/06 16:10:07.737999 TCP connection from <IP_ADDRESS>:42616 to <IP_ADDRESS>:443 blocked by Weave NPC.

All of the netpol I've applied to my cluster have a port definition and none of the ports you can read in the traces above are part of it (53, 5432, 443).
So I've no clue of how & why these connections are denied by Weave NPC.
FYI, today I bumped version from 2.6.0 to 2.6.5 with the same result :-/
Finally, I know that's an inappropriate comment - and I'm not sure of the following statement - but ... thinking again about this problem, I can remember when I had my CKA exam I have had some issues, randomly, while trying to resolve a service name from a busybox pod (port 53/UDP to coredns). After the exam, I could not find out why some of these resolve requests were not working. Now I wonder if that was related to traffic being sometimes denied by the weave-net CNI plugin. The point is that the raw output of this nslookup command is tested against the expected correct output. That was the only issue I had during the exam (passed with 96%, first attempt). I hope I'm wrong, but that's definitely NOT what you want to hear from the k8s users..

Please open a new issue, follow the issue template to supply requested information, and do not truncate the logs.

Same issue here. At first, pods became unable to resolve hostnames for Consul pods. After restarting weave and making sure all services are running, some weren't able to connect to redis. Upon checking logs by using --tail=50, I came across the latest failure logs. I'm using the workaround suggested by @kostyrev now. Will reset the whole WeaveNet now.

We are experiencing  the same issue for 2 of our clusters (though all our clusters have same configurations).
WARN: 2021/06/15 11:57:51.527538 UDP connection from xx.xx.xx.52:33703 to xx.xx.xx.212:8125 blocked by Weave NPC.
WARN: 2021/06/15 11:57:51.527556 UDP connection from xx.xx.xx.52:33703 to xx.xx.xx.212:8125 blocked by Weave NPC.
WARN: 2021/06/15 11:57:51.527570 UDP connection from xx.xx.xx.52:33703 to xx.xx.xx.212:8125 blocked by Weave NPC.
WARN: 2021/06/15 11:57:51.527579 UDP connection from xx.xx.xx.52:33703 to xx.xx.xx.212:8125 blocked by Weave NPC.

The ips in the logs are not associated to any pods. The only thing that stood out was the destination port - 8125 is a HostPort
name: monit-agent
    ports:
    - containerPort: 8125
      hostPort: 8125
      name: monitoringport

But we have implemented hostport capabilities to our CNI.
{
    "cniVersion": "0.3.0",
    "name": "weave",
    "plugins": [
        {
            "name": "weave",
            "type": "weave-net",
            "hairpinMode": true
        },
        {
            "type": "portmap",
            "capabilities": {"portMappings": true},
            "snat": true
        }
    ]
}

We are not seeing any impact because of the warn messages, but we are trying to understand the cause of these warning messages.
And yes, we are not using network policies either.
Any help on this is appreciated :)

Hello,
I'm running into the same issue on a production cluster with weaveNet.
We applied network policies in dev and worked well but when applying to our production cluster the network policies were not blocking egress connections at first but after a few trial and redeployments the pods switch to another node and then no way to get any packet going outwards.
We even removed the network policy but the pods are not able to communicate with pods even inside the same namespace.
Working with NPC being essentials for us it would mean a change of CNI if this is not working correctly :/
Is it related to https://github.com/weaveworks/weave/issues/3586 somehow?
Thanks,


Raku rename

I'm opening this PR for the Perl 6 to Raku name change.
This draws on #53 but has a few modifications.

Just a troubleshooter for people having problem to update to raku on debian
To get the lastest version on Debian see rakudo-pkg : I had troubles to bootstrap with Z because I messed all my binaries, the last link restored peace on Intel or AMD
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 379CE192D401AB61
echo "deb https://dl.bintray.com/nxadm/rakudo-pkg-debs `lsb_release -cs` main" | sudo tee -a /etc/apt/sources.list.d/rakudo-pkg.list
sudo apt-get update && sudo apt-get install rakudo-pkg

PS : My initial error before unwinding that was on Net::ZMQ4
Cannot find method 'is_dispatcher' on 'BOOTCode': no method cache and no .^find_method
home#sources/FC1DE5470FF5B7D8A301F6A4F740D2AB33836E50 (Net::ZMQ4::Context):5
home#sources/542A37D8381253B57190B2E0A2580627D9EB8B49 (Net::ZMQ4):6

Aposteriori it was a permission problem (root Vs user install) : I reinstalled all modules in ~/.raku (user) so I will be happy for 100 years (or maybe days).
Take care of the RAKUDODIR hardcoded in Z
In my bashrc
export PATH=$HOME/.raku/share/perl6/site/bin/:$PATH    # zef and jupyter-kernel.raku
export PATH=$HOME/.raku/bin:$PATH

We should have done a Renaming day but someone has to start. So I support 200% your initiative @bduggan.
Time for me to go to pygment and ask for perl6 -> raku to get color.
.local/lib/python3.7/site-packages/jupyter_console/ptshell.py:117: UserWarning: No lexer found for language 'raku'. Treating as plain text.
  warn("No lexer found for language %r. Treating as plain text." % name)
Jupyter console 6.1.1dev

Welcome to Raku (rakudo 2<IP_ADDRESS>.g.78371.bb.0.c).

Thanks for looking into this @tinmarino.  I was wondering about the error message.  Currently with pip install pygments --upgrade I get pygments version 2.5.2, and with pip3 install pygments --upgrade I get 2.6.1 (or even pip3 install git+git://github.com/pygments/pygments --upgrade doesn't seem to help) -- have you had success installing a version that works?

It works here. Strangely my version is also 2.6.1 and pip3 install git+git://github.com/pygments/pygments --upgrade --force-install should have worked. Maybe add the --force-install because the first 2.6.1 release may be old.

Reinstalling jupyter with pip3 (instead of pip) fixed it :-)


Reloading data

Firstly, thanks for creating this fork.
How would one go about refetching data?   E.g. after posting some update, invalidate the current response for some key and rerun the promise.  Currently I am just using react-router-redux -> replace (currentLocation)  but this seems particularly hacky.
Thoughts?

On any route transition redux connect would re-run promises in all of the matched components, optionally filtered by filter func, returned by router.
If you want some of these actions to not refetch smth and use cached values - you should supply logic for it yourseld

So if I want to refetch data for a component, (and if I'm using something like react-router-redux), then I must to do:
dispatch(routeActions.replace(this.props.location)),  (replace the location with the same location)
This seems a bit strange, although I suppose I could replace it with a 'refresh' HoC or something to make the intention clearer.

This would refetch data for all components. You should abstract action to refetch data for a given component and call it in some action handler. Could you elaborate the use-case for refreshing data on the same URL?

On 01 Jun 2016, at 00:07, Joshua Gagnon<EMAIL_ADDRESS>wrote:
So if I want to refetch data for a component, (and if I'm using something like react-router-redux), then I must to do:
dispatch(routeActions.replace(this.props.location)), (replace the location with the same location)
This seems a bit strange, although I suppose I could replace it with a 'refresh' HoC or something to make the intention clearer.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

"This would refetch data for all components."
Would it?  Only if I have set store.reduxAsyncConnect.loadState[SOME_KEY].loaded = false, right?

The use cases I have are as follows:

Submitting a form, but then continuing to show the same page with updated data (e.g edit some user details on a user details page, submit/save but keep me on this page)
Periodically updating some semi-live data.

In my case, updating/creating/deleting a resource invalidates large parts of the store, so there are too many resources to keep track of to manually refresh. Rerunning the promises for every component will fetch all the invalided resources, and so at least seems like the appropriate approach.

Would it? Only if I have set store.reduxAsyncConnect.loadState[SOME_KEY].loaded = false, right?

Not really. This is not widely used and should be fixed when adding more granularity to checks, this key is for you to understand where data had been fetched or not (based on the provided filter function, which is noop by default)
Begin global load action clears state and is invoked by componentWillReceiveProps, which in turn is invoked whenever the route is changed, because router will trigger a transition and run a render on the underlaying components

Submitting a form, but then continuing to show the same page with updated data (e.g edit some user details on a user details page, submit/save but keep me on this page)

Best practice is to handle loading of a user with an appropriate action. You already should have all the logic to handle user updates in the app and reloading is certainly not an answer to this. What you have to do is dispatch same action as you would normally do after user had finished loading in the form onSuccess action (I assume you use redux-form version 6+), then it will trigger chain of events by itself and you wont need to really care about that.
In case you still dont want to be bothered with it, well, refresh the page by using push action from react-router-redux, but then again I dont see why it would be needed

Periodically updating some semi-live data.

Again, it's best to not refetch all the data, but simply write a redux module handling that or add logic to each of your modules for fetching periodic updates and handle it with your reducers
Does it make sense?

Yeah this make sense.
Thanks.

glad I could help :)

Another use case is when we load the same route but with a different, let's say, router param, which causes the async promise to invoke again (let's say there's one in the AsyncProps).
If I dispatch several actions and afterwards resolve the promise, the component will immediately rerender if one of the props have changed because of a dispatch, even before the promise resolved. If we dispatch several actions in the AsyncProps promise, the component is in an unknown state in between dispatches, and possible errors because.
I could clear the key before reloading the route (right?) but I cannot import the action from the library, and even if I could, I would want it as a part of the AsyncProp itself (as options?) to make it block rerendering (I thought this is what automatically happens if the stateToPropMap is used inside the decorator).


Phi3 conversion to tflite

Description of the bug:
I wanted to convert phi3 to tflite, I started modifying phi2.py to apply the differences. In the Attention class of phi3, there is a combined projection layer self.qkv_proj = nn.Linear(self.hidden_size, op_size, bias=False).
I have defined the TENSOR_NAMES for phi3 just like in phi2.py, I am having an issue with ModelLoader class in loader.py where it has:
  @dataclass
  class TensorNames:
    attn_query_proj: str
    attn_key_proj: str
    attn_value_proj: str
    attn_output_proj: str
    ...

Do i pass the self.qkv_proj  tensor to all 3 query, key and value to the data loader class?
Thanks!
Actual vs expected behavior:
No response
Any other information you'd like to share?
No response

Thanks for reporting the issue! Yes as you mentioned, Phi-3 has an updated attention mechanism which is different from what the library provides as of today. Adding @hheydary to look into the issue (who is original author for the phi-2 example).

Greetings,
We just added a new field to the loader class attn_fused_qkv_proj. Please use that to load model parameters.

Thank you for the quick fix @haozha111 @hheydary


PVWatts plus TPO (Host) doesn't run

In the release branch, the PVWatts with Third-Party Ownership model fails to run with:

Closed with the latest release branch commit


examples/media: Fix the compiler wanring after off_t type change

Summary
Found by https://github.com/apache/incubator-nuttx/pull/4193
Impact
Minor warning fix.
Testing

LGTM


Sample reward_function method documentation wrong

In the documentation of the reward_function methods that are given as sample, the documentation explains the parameters to the function. Waypoints are explained as follows:

@waypoints (ordered list) :: list of waypoint in order; each waypoint is a set of coordinates
(x,y,yaw) that define a turning point

This is actually not true, because the simulator only provides x and y coordinates for the waypoints, not the yaw.

We are working on updating the documentation and will post an update to this thread once corrected. Thanks for bringing this to our attention.


BODY Swagger ParameterName uppercase

Information

Version: 5.31
Type: Issue

Description
The Swagger Schema generated using @BodyParams prevent every Swagger CodeGen to generate the right sdk stub.
Let's take a very straightforward sample :
PassportCtrl.login(BodyParams() user : User) {
}

When we use official Swagger TypeScript Fetch generator, the following stub is generated :
   passportCtrlLogin(options: any = {}): FetchArgs {
            // verify required parameter 'body' is not null or undefined
            if (body === null || body === undefined) {
                throw new RequiredError('body','Required parameter body was null or undefined when calling passportCtrlLogin.');
            } (...)

Instead of :
passportCtrlLogin(**body: PassportCtrlLoginPayload**, options: any = {}): FetchArgs {
            // verify required parameter 'body' is not null or undefined
            if (body === null || body === undefined) {
                throw new RequiredError('body','Required parameter body was null or undefined when calling passportCtrlLogin.');
            }

This is due to the fact that the body parameter in spec.json is spelled as BODY in uppercase instead of lowercase. Many code gen tools does not complaint and fail silently to generate the parameter. Others raise "Parameter Type does not exist" and stop.
I'm surprised that I don't see any issue on this topic given that it is a nominal case... People don't use code gen with swagger ?
btw, Ts.ed is really an awesome project ...
Cheers,
Sami

Hello @dngconsulting
Hoo I see the problem. I remember I already fix this problem. But maybe latest release has introduce a regression. A quick fix is possible :)
See you

Hello @dngconsulting
For me the swagger is correctly generated. Here the swagger used by my unit test: https://github.com/TypedProject/ts-express-decorators/blob/master/test/integration/data/swagger.spec.json
it look sound good ^^

Sorry to have opened this ticket for nothing @Romakita and have wasted your time. My Ts.ED version was recent but not the swagger module. That's better now. Cheers


v2.8 issues

Hi there,
I found a couple of issues after building v2.8 (commit: da1254f6055d2df01b3382a4be6de92219e8423f) , I couldn't find the compiled vsix on visual studio gallery.
I created a new project using .net 4.5.2, choosing default options:
1) _ViewImports.cshtml
Referencing Microsoft.Framework.OptionsModel but should be referencing Microsoft.Extensions.OptionsModel
2) gulpfile.js
autoprefixer = require("gulp-autoprefixer") missing comma at the end  of line
There is an warning using "strict" in gulpfile.js for require, it states that "Using a variable (property or object) without declaring it is not allowed in  in 'strict mode', You may need to declare var require;
3) JSHint Errors)
If you choose the JsHint option then there is an error with gulpfile, if you don't choose JsHint as an option everything works correctly
Failed to run "D:\Programming\Projects\AspNetMvcBoilerPlate\WebApplication4\WebApplication4
\Gulpfile.js"...
cmd.exe /c gulp --tasks-simple
module.js:338
    throw err;
          ^
Error: Cannot find module 'jshint/src/cli'
    at Function.Module._resolveFilename (module.js:336:15)
    at Function.Module._load (module.js:278:25)
    at Module.require (module.js:365:17)
    at require (module.js:384:17)
    at Object.<anonymous> (D:\Programming\Projects\AspNetMvcBoilerPlate\WebApplication4\WebApplication4\node_modules\gulp-jshint\src\extract.js:1:79)
    at Module._compile (module.js:460:26)
    at Object.Module._extensions..js (module.js:478:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Module.require (module.js:365:17)
    at require (module.js:384:17)

Failed to run "D:\Programming\Projects\AspNetMvcBoilerPlate\WebApplication4\WebApplication4\Gulpfile.js"...
cmd.exe /c gulp --tasks-simple
module.js:338
    throw err;
          ^
Error: Cannot find module 'jshint/src/cli'
    at Function.Module._resolveFilename (module.js:336:15)
    at Function.Module._load (module.js:278:25)
    at Module.require (module.js:365:17)
    at require (module.js:384:17)
    at Object.<anonymous> (D:\Programming\Projects\AspNetMvcBoilerPlate\WebApplication4\WebApplication4\node_modules\gulp-jshint\src\extract.js:1:79)
    at Module._compile (module.js:460:26)
    at Object.Module._extensions..js (module.js:478:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Module.require (module.js:365:17)
    at require (module.js:384:17)

The latest commit is not released due to a problem with RC1. Please see the latest closed pull request for more info.
I'll add your fixes to my list.

Excellent thank you

First two errors fixed. Thanks.

Apparently there will be a ASP.NET 5 RC1 Update 1 release soon. Hopefully it will fix the issues so I can release.

Oh great, thanks for the update. Is there any page where they have announced upcoming ASP.NET 5 RC1 Update 1?

Only discussed in the ASP.Net community standup meetings.

Thanks once again I will definitely check out those videos

I got another issue which I'm not sure if you have come across, I've posted on StackOverflow because I'm unsure if it's an issue with Firefox / IIS or this project:
http://stackoverflow.com/questions/34034068/firefox-https-404-errors
Basically I'm using this method to run the project
https://github.com/tuespetre/dnx-watch-iis

Not sure, I haven't used dnx watch yet. Does Browser Link not work for you? It achieves the same objective I think. Not sure what the difference is yet, need to do some reading.
FYI, I'm keeping this open until I fix the JSHint errors.

Thanks for keeping the issue open until JSHint is fixed
The firefox is as follows:
<IP_ADDRESS> local-foo.com
In IIS I set a binding for HTTP and HTTPS for local-foo.com and create a self signed certificate.
Using your template I get these aborted request errors, but if I use the ASP.NET template instead then I do not get these errors. I know your template makes use of security features I'm just wondering something must be making Firefox act differently.
I have tried different computers but the issue only exists with Firefox in HTTPS mode using IIS.
I'm just worried that in published mode that Firefox might have issues with HTTPS with this template?

Well, NWebSec does not exist yet for ASP.NET 5, so no security features yet. Let me know if you figure anything out on your side.

Yes I definitely will, just debugging and see what's different between the two solutions.

Looks like there is nuget update for dnx RC1 update1
https://www.nuget.org/packages/dnx-clr-win-x86/1.0.0-rc1-update1

Cool, nice spot.

In case you didn't know the installer is now available for RC 1 update 1 @ http://get.asp.net/

All updated. Just doing some final testing.


Usage docs

Wrote this a while ago and I think it should be okay to merge.

Definitely! Thanks @meisekimiu , totally missed the docs folder.


i am not receiving OTP, I only get a call from a number and the call hangs up as soon I pick.

I am having the same issue. I am not receiving OTP, I only get a call from a number and the call hangs up as soon I pick.

I am having the same issue.

Same issue

Same problem.

same

the same problem verification failed ,  any solution


Jupyter Kernel installed under Library/Jupyter  rather than virtual environment

I have a Django project that uses pipenv to manage its virtual environment, in which I have installed Jupyter and "django-extensions" and run /manage.py shell_plus --notebook.
It seems the "django_extensions" jupyter kernel gets installed in Library/Jupyter/kernerls, making is accessible to other jupyter projects. By contrast, it seems like the python3 kernel is installed within the virtual environment.
Here is what I see when running jupyter kernelspec list, inside my project cc-dashboard with its respective pipenv activated.
jupyter kernelspec list

Available kernels:
  django_extensions    /Users/dustinmichels/Library/Jupyter/kernels/django_extensions
  python3              /Users/dustinmichels/.local/share/virtualenvs/cc-dashboard-15QDmC0q/bin/../share/jupyter/kernels/python3

Is there a way to get the kernel to install itself under the virtual environment's share/jupyter folder instead? Thanks.
Specs

django -- version: 2.2.1
django-extensions -- version: 2.1.7
jupyter -- version: 4.4.0
python -- version: 3.7.3
pipenv -- version 2018.11.26
OS -- MacOS Mojave (10.14.5)

The directory is taken from user_kernel_dir as follows:
ksm = app.kernel_spec_manager
kernel_dir = os.path.join(ksm.user_kernel_dir, 'django_extensions')

If we can also get the kernel_dir from the virtualenv I think it would make sense to install it in there by default and adding a command line flag to be able to force shell_plus to use the user globally available user_kernel_dir instead.

having the same problem.  Actually it tries to do this with shell_plus even if I don't add --notebook

@jcquarto I do not see how that should be possible install_kernel_spec is only called when using --notebook.

Please see https://github.com/django-extensions/django-extensions/pull/1500

@jcquarto I do not see how that should be possible install_kernel_spec is only called when using --notebook.

@trbs this may have been related to e8d5daa06e5b6419e54d6c925f86a0adbe58ce8b


Enable aliased imports in shell_plus pre- and post-imports

Basically I just wanted 'from pprint import pprint as p'

Coverage decreased (-0.06%) to 31.464% when pulling c3eb9c8eac8326b2dba113f76e0621fe78f770e5 on MattFisher:master into f40be190de1102f663573e65cbb19b4d7da83864 on django-extensions:master.

Like this :)
(Now I'm also thinking why we cannot use normal import strings which we parse instead of the complicated list of tuples... so for users the normal python syntax would work...)

Could you write some tests for you patch ?
And update the docs/shell_plus.rst documentation file.
Alternatively if you want I'm thinking of something like:
import ast
import six

def parse_import_line(import_line):
    if not isinstance(import_line, six.string_types):
        raise Exception("Argument must be a string type")
    node = ast.parse(import_line)
    if len(node.body) != 1:
        raise Exception("Invalid import line. Please only specify exactly one import.")
    node = node.body[0]
    if not isinstance(node, (ast.Import, ast.ImportFrom)):
        raise Exception("Only specify import statements")
    from_module = getattr(node, 'module', None)
    name = node.names[0].name
    as_name = node.names[0].asname

    return (from_module, name, as_name)

print parse_import_line("import os")
>>> (None, 'os', None)

print parse_import_line("import os.path")
>>> (None, 'os.path', None)

print parse_import_line("import os.path as ospath")
>>> (None, 'os.path', 'ospath')

print parse_import_line("from os.path import isfile")
>>> ('os.path', 'isfile', None)

print parse_import_line("from os.path import isfile as ospathisfile")
>>> ('os.path', 'isfile', 'ospathisfile')

as an alternative way of describing the imports.
People could then just use normal python import lines. Which is far more intuitive... It would (after deprecating the old way) also clear up the code for this.

Hello, can you clarify if it is now possible to use aliases? Thank you very much.

fixed in master


Fix #12

block motion logic still activated when a block should be fixed, which made this issue happen.  adding a return should fix it, if I'm reading right.

Thanks! I do still want to enable horizontal motion on the final tick so people can slot blocks in left or right-wards, but clearly need a better way of doing it.

I can fix that too but it'll take me a while, I might send another pr tonight or tomorrow if I get a chance

Closing this to make more changes, will open a new one when I'm done

Thank you! It's tricky and this is very much a prototype. Ideally I'd add some tests to make refactoring easier.


max_n seems complicated

For this code:
from copy import deepcopy

def max_n(arr, n=1):
    numbers = deepcopy(arr)
    numbers.sort()
    numbers.reverse()
    return numbers[:n]

https://github.com/kriadmin/30-seconds-of-python-code#max_n
Why not just do:
def max_n(arr, n=1, reverse=True):
    return sorted(arr, reverse=reverse)[:n]

In fact, this seems so basic you wouldn't need a snippet for it?

Why reinvent the wheel? The standard library already has this (and it has a better time complexity).
heapq.nlargest(n, arr)
See also heapq.nsmallest.

@gerardlouw If you would have looked at the snippets most of them are already implemented in the standard library. This snippets not for someone to use in production but just to learn the pythonic way to do things.

Fixed via #30

@gerardlouw If you would have looked at the snippets most of them are already implemented in the standard library. This snippets not for someone to use in production but just to learn the pythonic way to do things.

Some other snippets mention existing implementations in the standard library..