Hot module reloading not working in Firefox but works in Chrome

Hi,
When developing using create-react-app in Firefox 66.0.1, hot module reloading isn't working, and I get this error in console when using npm run start:
The connection to ws://localhost:3000/sockjs-node/800/q2e1i5qh/websocket was interrupted while the page was loading. websocket.js:7

This doesn't happen in Chrome, and HMR works there as expected. I didn't have problems in the past with Firefox, I'm not sure if it's triggered by a Firefox update, or new versions of react-scripts.  It may even be specific to my app.
I'm using react-scripts versions 2.1.8
Does anyone know what would cause this, and how I could get HMR working again? I'm not really sure where to look.
Thanks

@andygock what version of create-react-app are you using? Also, this is an old issue, but it could be related to this issue with socket.io in the past: https://github.com/socketio/socket.io/issues/1123

@andygock what version of create-react-app are you using?

@Jbonez87
I'm using version 2.1.8

@andygock I'm not able to reproduce this error using npm run start or yarn start. What version of npm are you using? I'm using this version:
npm -v
6.9.0

@andygock  this is happening because you did close your open WebSocket. Try closing them socket.close(); and retry.

@andygock this is happening because you did close your open WebSocket. Try closing them socket.close(); and retry.

@Developerayo Where and how should I do this in a create-react-app project? I'm not using any WebSocket in my app itself, so I'm guessing the sockets are part of the HMR implementation.

i started a new project yesterday, and i know it was working yesterday.  react-scripts 2.1.8, yarn 1.12.3, node v8.15.1.  i see firefox updated a few hours ago, so i'm going to blame firefox 66.0.2 for this one (had 66.0.1 yesterday)

@jayenashar it could be webpack-dev-server too..

@andygock I think this is an issue with ws and webpack-dev-server, not create-react-app itself. I would open a bug ticket on ws and on webpack-dev-server

i didn't update any node modules between yesterday and today.  the only thing i can think of that has changed is firefox.

@jayenashar it doesn't look there were any javascript changes here in the latest version of Firefox: Firefox changelog
If you still think the issue is with Firefox, it might be more beneficial to create a bug ticket here: Bugzilla

I just did some experiments:
Firefox 60.6.1 ESR - works okay
Firefox 66.0.2 - websocket error
Clean PortableApps install, no add-ons or extensions.
On creating a blank project using e.g npx create-react-app test - no problems in both browsers. There may be something going on with my app as well I think. Can't pin point it or have any clue of where to start debugging.

@andygock I know in the past create-react-app has had issue when using npm and npx (the one that comes to mind for me is "Cannot resolve module 'chalk'". Just as a sanity check, could you try starting your app with yarn? What OS are you using? You can install yarn with homebrew if you don't have it already

On creating a blank project using e.g npx create-react-app test - no problems in both browsers. There may be something going on with my app as well I think. Can't pin point it or have any clue of where to start debugging.

I'm having the same issue. Everything works fine in Chrome but in Firefox:
The connection to ws://localhost:3000/sockjs-node/698/osuont4q/websocket was interrupted while the page was loading. websocket.js:7
Clean create-react-app works fine.

i'm not using any extra packages.
i have found that oddly it works the first time, but not again until i restart firefox.

i have found that oddly it works the first time, but not again until i restart firefox.
Yeah on closer inspection it might not be related to the redirect. Sometimes it works and sometimes it doesn't but I can't seem to find a pattern to when it works.

Firefox 60.6.1 ESR - works okay
Just tested this and can confirm this release has no issues.

https://github.com/socketio/socket.io/issues/2016#issuecomment-392241457
looks like some ip/hostname issues?

There is an entry in the Mozilla issue tracker:
https://bugzilla.mozilla.org/show_bug.cgi?id=1536843

There is an entry in the Mozilla issue tracker:

Following up from that bug (which was just resolved as invalid, because it seems like

...mozregression pointed to a bug 1417463. That bug changed default accept header and further testing showed that it's server side issue. For some reason, server goes mad when "text/html" is missing in the accept header and after few frames it sends some unexpected HTTP response over the websocket connection.

So possibly a down-stream sockjs-client issue? I'll file a bug over there.

Just checked same for Firefox 66.0.3 (now using 65.0.2)
For 66.0.X works only after removing proxy from package.json

Just checked - same issue for Firefox 66.0.3 (now using 65.0.2)
For 66.0.X works only after removing proxy option from package.json

@dmile looks consistent with other responses and analysis done by Firefox team. Now we only need to figure out which product is misbehaving. Good news is that it is not Firefox.
I have created one more issue in webpack-dev-server.

sockjs/sockjs-client#474

Hot reloading functionality is always here
https://github.com/facebook/create-react-app/blob/2add1288358f5d8ed6c162af32530255087153ce/packages/react-scripts/config/webpackDevServer.config.js#L63-L68
this endpoint already used by webpackHotDevClient
https://github.com/facebook/create-react-app/blob/2add1288358f5d8ed6c162af32530255087153ce/packages/react-dev-utils/webpackHotDevClient.js#L66-L67
and it's not a part of user defined functionality. What is the reason for hiding it behind proxy?
For example, it may be excluded (before accept header analyzing) by changing mayProxy method to
  // If proxy is specified, let it handle any request except files in the public folder and WebpackDevServer endpoint.
  function mayProxy(pathname) {
    const maybePublicPath = path.resolve(appPublicFolder, pathname.slice(1));
    const isPublicFileRequest = fs.existsSync(maybePublicPath);
    const isWdsEndpointRequest = pathname.startsWith('/sockjs-node'); // used by webpackHotDevClient
    return !(isPublicFileRequest || isWdsEndpointRequest);
  }

@mrmckeb @iansu , what do you think?

As a temporary workaround, using the manual proxy config instead of using the proxy entry in package.json worked for me.

Mine also worked after removing proxy option in package.json in my react app

Don't close it stale bot! 😇

Bumping to keep the issue from closing. Still using the manual proxy workaround.

Sorry for the very late reply here. I'd be happy for you to raise a PR to fix this. Keep in mind that @gaearon also has a PR in the works to improve HMR for React which may modify how some of this works.

@mrmckeb please take a look at #7318


Basic usage questions... maybe a request for the docs?

Please forgive the newbie questions, but I'm trying to understand how this library is supposed to be used.  I see that a call to the reset_password endpoint will generate a token and a signal, enabling a function to send an email to the given email address with that token in it.  I presume that when the user clicks the link in the email, they can then be presented with a form to fill in a new password.  What I don't get is:

What endpoint should be in that initial email?  The example in the documentation uses reverse('password_reset:reset-password-request').  But wouldn't that just be a circular loop, since that's the endpoint that generated the email in the first place?

How can links access the endpoints in this library as POSTs, as they require?  At least in plain text emails, when clicked these only seem to show up as GETs.

Perhaps somebody can explain the basic data flow for how these endpoints should be used?  What is provided, what must be written?

Thanks!

Hello, i also didn't get how to send this token to fronted. Have you found out something?

I ended up ditching this for django-allauth and django-rest-auth, which I found to be much more useful for me.


Add missing fields for tournaments

Add missing fields like team password (#88), player/manager pseudo and max number of teams in a tournament (#49). Also fixing unique registration per event validation.

I would realy appreciate some help for fixing tests :)

I'm not sure that the validator checking if a manager is not also a player is correct. The last failing test is about if we should raise IntegrityError or ValidityError.

Hi, so, I finally managed to focus enough to run the tests and investigate what's wrong, here's what I found out

I'm not sure that the validator checking if a manager is not also a player is correct. The last failing test is about if we should raise IntegrityError or ValidityError.

Yes and no. Yes: the validation test is completely broken at the moment. No: it's not a matter of validation error or not; test code is raising errors on the first instance of registration, where no conflict should exist yet. Something is wrong with validation in a way that I haven't pinned down yet but which is definitely exhibited by our tests.
As for the second kind of tests, they happen to crash because test code was pushed in the pull request, and user tests previously written by @Lugrim check for the presence of the email validation URL in the body of emails returned by calling the registration URL.
So we have two things to do before we can merge this PR:

Write an actual body in the content of the email and change the tests to check for that instead
Fix the registration conflict validation

(oh of course we will have to rebase this whole mess with dev before merging)


Screenshot has superfluous scroll bars

Within the main UI there exists a "Screenshots" icon/tab.
The image shown in this tab differs from what I currently see in my browser in unexpected ways that are difficult to attribute to the full-page rendering. As an example, https://nasa.gov from the Damage service:

vs. what I see in my browser:

Note the strange scrollbars over the blue meatball image.

Hi @machawk1,
Did you run this URI https://nasa.gov/ using the web service on http://wsdl-docker.cs.odu.edu:8880/? What browser did you use?
I run the URI using 4 different browsers: Firefox, Chrome, Ubuntu web browser, and Vivaldi. I also run the URI on 3 different versions of memento-damage: the one that runs on http://wsdl-docker.cs.odu.edu:8880/, the one that runs on my local docker, and the non-docker version in my local machine. But I cannot find any strange scroll bars.
Here is the screenshot that I got:

Could you please try to run the URI again and see if the 'superfluous scrollbars' still exist?
Thanks.

@erikaris I am using the instance at http://memento-damage.erikasiregar.tk/memento/check?url=http://nasa.gov&type=URI-M&fresh=false&fresh=true . I cannot replicate this screenshot at  http://wsdl-docker.cs.odu.edu:8880/ . Is the instance at http://memento-damage.erikasiregar.tk an old version?
I am running Chrome on macOS.

Yes, the one that is running on http://memento-damage.erikasiregar.tk/ is the old version and no longer exist. I think the "superfluous scroll bars" problem happened because you used the older version.
Right now, anyone who accesses the old version will be automatically redirected to http://memento-damage.cs.odu.edu/.
Could you please try it again and let me know if the scrollbar problem persists?

@erikaris The screenshot is never shown when I use http://memento-damage.erikasiregar.tk/ now with http://nasa.gov. An HTTP 500 is displayed in the console.

I did not get this error when I run http://nasa.gov using the docker instance of memento-damage that run on my local machine.

Perhaps there is a problem with the service that runs on http://memento-damage.cs.odu.edu/.
I will send an email to Sawood to ask him to re-run the docker image and see if it can solve the problem or not.
In the meantime, maybe you could run the docker instance and see if it still return the same error?
Thanks.

@erikaris Can you replicate the error for nasa.gov at http://memento-damage.erikasiregar.tk/?

The service on http://memento-damage.erikasiregar.tk/ is no longer exists and you will be automatically redirected to http://memento-damage.cs.odu.edu/. There is no superfluous scrollbar in this new memento-damage version.
Do I have to replicate the error for nasa.gov at http://memento-damage.erikasiregar.tk/? I think I can try to revive the old version and see the error...

@erikaris http://memento-damage.cs.odu.edu/memento/check/?url=http%3A%2F%2Fnasa.gov#screenshots reports the same Error 500. No screenshot is shown. I cannot verify that the scrollbar issue does not exist in an undisplayed screenshot.

Sawood just restart the service for http://memento-damage.cs.odu.edu/. I have tried it for http://nasa.gov: http://memento-damage.cs.odu.edu/memento/check/?url=https%3A%2F%2Fwww.nasa.gov%2F&fresh=true#summary  and it works well.

LGTM


Modal refactoring classes

This change refactors the modals used to utilize a common modal class.
Testing:
The upload and download modals need to be tested on each screen. There are some extra modals that have been merged as well which are shown in the plus comments
Tests:
annotation_catagories - http://<IP_ADDRESS>:3000/en/assignments/2/annotation_categories
assignments - http://<IP_ADDRESS>:3000/en/assignments
criteria - http://<IP_ADDRESS>:3000/en/assignments/7/criteria
grade_entry_forms - http://<IP_ADDRESS>:3000/en/grade_entry_forms/3/grades
graders - http://<IP_ADDRESS>:3000/en/assignments/7/graders
groups - http://<IP_ADDRESS>:3000/en/assignments/2/groups
plus: assignment_group_use, create_group, rename_group_modal
marking_schemes - http://<IP_ADDRESS>:3000/en/marking_schemes
marks_graders - http://<IP_ADDRESS>:3000/en/grade_entry_forms/3/marks_graders
peer_reviews - http://<IP_ADDRESS>:3000/en/assignments/11/peer_reviews
results - [Student] http://<IP_ADDRESS>:3000/en/assignments/2/submissions/16/results/16/view_marks
students - http://<IP_ADDRESS>:3000/en/students (broken csv download)
tags - http://<IP_ADDRESS>:3000/en/assignments/2/tags
plus: create_new (edit modal was not refactored)
tas - http://<IP_ADDRESS>:3000/en/tas

Okay, I went through and made those changes. Here are the links I tested and the results.
Tests:
annotation_catagories http://<IP_ADDRESS>:3000/en/assignments/2/annotation_categories
- Works as expected
assignments http://<IP_ADDRESS>:3000/en/assignments
- YML does not download; opens new page instead
criteria - http://<IP_ADDRESS>:3000/en/assignments/7/criteria
- App crash if invalid YML upload
- YML does not download; opens new page instead
grade_entry_forms - http://<IP_ADDRESS>:3000/en/grade_entry_forms/3/grades
- Upload button is not disabled when no file is selected
- Upload does not upload the downloaded file; claims invalid format
graders - http://<IP_ADDRESS>:3000/en/assignments/7/graders
- Upload button is not disabled when no file is selected
groups - http://<IP_ADDRESS>:3000/en/assignments/2/groups
plus: assignment_group_use, create_group, rename_group_modal
- Works as expected
marks_graders - http://<IP_ADDRESS>:3000/en/grade_entry_forms/3/marks_graders
- Works as expected
peer_reviews - http://<IP_ADDRESS>:3000/en/assignments/11/peer_reviews
- Works as expected
results - [Student] http://<IP_ADDRESS>:3000/en/assignments/2/submissions/16/results/16/view_marks
- Works as expected
students - http://<IP_ADDRESS>:3000/en/students
- YML does not download; opens new page instead
- App crash; csv download
tags - http://<IP_ADDRESS>:3000/en/assignments/2/tags
plus: create_new
- YML does not download/maybe throws an error; opens new page instead
tas - http://<IP_ADDRESS>:3000/en/tas
- Works as expected


Add condition to setting "_edit_layout_mode" meta

Related issue: #61343
Ensures that Control::_set_layout_mode() only sets
"_edit_layout_mode" meta if the layout mode is LAYOUT_MODE_ANCHORS
because the alternative, LAYOUT_MODE_POSITION, is the default
value and not needed in the meta.
This fixes #61343

@KoBeWi If your original suspicion was correct, then keeping the position layout mode that was removed 4 commits ago would be a sufficient fix. However, later you yourself changed how checks work and removed has_* checks, so I'm not sure this would even work the same at this point. It's bad that the code is so brittle, sorry for that. But some checks were there specifically to prevent unnecessary updates and to account for possible ambiguity between runtime values and stored values (and stored values may also be missing).
All in all, the logic has changed too much for me to be sure, so I trust your testing more. I'd have to retest every commit done since that touched the meta to figure out possible regressions.

So the proper fix should be to remove remove_meta("_edit_layout_mode"); and test the reproduction then.

This would reintroduce #58940 though.

This would reintroduce #58940 though.

We already store this meta if it's not the position mode. It just seems that storing it when it is the position mode is not actually unnecessary 🙃

This PR fixes the regression though, even if it doesn't make sense that it works.

I have an idea. Metadata was exposed to the inspector after the initial layout PR, right? So setting it, at any point, may trigger the inspector to update. Which isn't great, given that editor-only meta properties shouldn't even be editable in the inspector in the first place.

Unless you find some new issue it creates, it should be good to merge.

I'm not a fan of changing code further from the state that worked without understanding the changes. I won't block this PR if you insist on this solution, but this makes it harder and harder to maintain this delicate piece of logic based on hacks and good will. 👀

I actually found some flaws in the current code. They don't seem to break anything (in an obvious way at least), but we should probably fix it.
First thing is that we need a default value for _edit_layout_mode. When setting layout mode to this value, don't store the meta. Then the code should consistently use the default value when it doesn't exist. I checked other layout modes and they are determined in a different way, so meta value is irrelevant there.
The problem I found in the current code is that it doesn't use default value.
Here:
https://github.com/godotengine/godot/blob/9b78d68605d88c6984737ced7feeebd46430d0e2/scene/gui/control.cpp#L1502
If the value doesn't exist, it will use the current value as default. That's not how defaults work...
Similar thing here:
https://github.com/godotengine/godot/blob/9b78d68605d88c6984737ced7feeebd46430d0e2/scene/gui/control.cpp#L1591
It uses LAYOUT_MODE_ANCHORS as default, while the code changes in this PR assume LAYOUT_MODE_POSITION as default.
So here's what I propose: add const int DEFAULT_LAYOUT_MODE = LayoutMode::LAYOUT_MODE_POSITION then change every get_meta for _edit_layout_mode to get_meta("_edit_layout_mode", DEFAULT_LAYOUT_MODE).
As a topping to these changes, change this thing:
https://github.com/godotengine/godot/blob/9b78d68605d88c6984737ced7feeebd46430d0e2/scene/gui/control.cpp#L1540-L1544
To return (LayoutMode)int(get_meta("_edit_layout_mode", DEFAULT_LAYOUT_MODE));
It changes some logic, but I did a quick test and doesn't seem to break things. Will test again after you apply these changes.

I believe you've introduced this code when you removed has_* checks. This preserved the original logic, as the logic used has_* checks differently in different contexts.

I know why the code was there, I just questioned whether keeping the old logic is actually necessary. _edit_layout_mode isn't used much, so it's likely it won't break anything.

@KoBeWi I've read through this discussion and applied the changes you suggested. Though when playing around in the editor to make sure the issue is still resolved I noticed this: When starting to drag a ColorRect, the first movement seem subject to a noticable lag/delay, after which the movement becomes smooth.
Now I know to little to guess why this is and don't want to speculate. Though I did try the 3.4.2 stable release which I had sitting around and it does not have an initial lag when dragging control nodes. Though I'll check if this laging existed before #59185.

Something is still wrong. When layout mode is anchors, the slowdowns are still happening :/

@KoBeWi are you sure that the performance issue was introduced in #59185? I checked out this PR and dragging is smooth for me. When you check out PR #59185 do you experience the lagging?

I have an idea. Metadata was exposed to the inspector after the initial layout PR, right? So setting it, at any point, may trigger the inspector to update. Which isn't great, given that editor-only meta properties shouldn't even be editable in the inspector in the first place. And while this PR doesn't change the logic, it reduces the number of calls to set_meta().

You can see if this ^ is plausible. That would explain why your initial fix has an effect, for one.

are you sure that the performance issue was introduced in https://github.com/godotengine/godot/pull/59185? I checked out this PR and dragging is smooth for me. When you check out PR https://github.com/godotengine/godot/pull/59185 do you experience the lagging?

Not sure what you mean by "checking out the PR", I just re-added the 2 lines it removed and it fixed the lag. I didn't do much more testing.

Metadata was exposed to the inspector after the initial layout PR, right? So setting it, at any point, may trigger the inspector to update.

That would be interesting. Editor metadata is not visible in the inspector, so if it was causing inspector refresh then it's a bug.

Not sure what you mean by "checking out the PR", I just re-added the 2 lines it removed and it fixed the lag. I didn't do much more testing.
Checking out as in checkout out the resulting commit of the PR. I checked it out and dragging was smooth. So I guess while re-adding the lines fixes the issue, they did not cause the performance issue by themselves. I guess this can be explained by what YuriSizov said about setting metadata triggering inspector update.

I'm currently running git bisect to see where I first notice the performance regression but it will take some time.

I have an idea. Metadata was exposed to the inspector after the initial layout PR, right? So setting it, at any point, may trigger the inspector to update. Which isn't great, given that editor-only meta properties shouldn't even be editable in the inspector in the first place. And while this PR doesn't change the logic, it reduces the number of calls to set_meta().

I looked into this and it seems like the correct hypothesis. The commit 09b951b, which makes properties editable in inspector, is the first that causes the regression if combined with the changes introduced in 59185. Specifically, 09b951b adds calls to notify_property_list_changed() in Object::set_meta() (in object.cpp) which if commented removes the regression.
I agree that this PR is just a band-aid and not an actual solution. As said earlier, editor-only properties should not be editable in the inspector. So if these were not visible in the inspector, there would be no need to call notify_property_list_changed() when setting editor-only meta. Is there a way to identify if a property is editor-only? 09b951b's commit message states "Properties are editable in inspector (unless metadata name begins with _)", does that imply that properties that start with "_" are editor-only? If so it feels like there is a straight forward way to resolve the issue, by simply not triggering the inspector updates in these cases.
@YuriSizov @KoBeWi do you think I have the right idea here? Then I'd be happy to draw up a new solution and create a PR. Also, since this current PR is not viable should I use the original issue for further discussion?

does that imply that properties that start with "_" are editor-only?

Yes, the metadata starting with _ don't show in the inspector, so changing them shouldn't affect the inspector.

It's been a hectic weekend but I finally have some time to work on this. There seems to be something weird going on with EditorInspector (editor_inspector.cpp). notify_property_list_changed() triggers a call to _edit_request_change() which sets the update_tree_pending flag that triggers inspector updates. This method does take a parameter for the changed property, which should make it easy for us to only set the flag if the property isn't editor-only. But this parameter is set to an empty string in practice so not sure what that is about.
Anyways, I have some ideas what's going on and don't anticipate the solution will be too hard.. Just wanted to let people know that this is still being worked on.

It's been a hectic weekend but I finally have some time to work on this. There seems to be something weird going on with EditorInspector (editor_inspector.cpp). notify_property_list_changed() triggers a call to _edit_request_change() which sets the update_tree_pending flag that triggers inspector updates. This method does take a parameter for the changed property, which should make it easy for us to only set the flag if the property isn't editor-only. But this parameter is set to an empty string in practice so not sure what that is about.

There is no need to go so in-depth with this. notify_property_list_changed() is the culprit, and you should simply avoid calling it in set_meta() for meta properties that won't be displayed. I looked at how https://github.com/godotengine/godot/pull/59452 filters them in inspector, and all that is checked here, basically, is name.begins_with("metadata/_"). So for set_meta() you can check if p_name begins with the underscore, and avoid calling notify_property_list_changed() if that's the case.

There is no need to go so in-depth with this. notify_property_list_changed() is the culprit, and you should simply avoid calling it in set_meta() for meta properties that won't be displayed

That was my first thought. However, I considered that there might be subscribers other than EditorInspector that are listening to property_list_change that might have interest in changes to editor-only properties. However, if you think that this is not a concern I will go with the simple option.
And thanks for the encouragement! I'm happy to help

Looks like this is patching something that is hacky, should not not be better to fix whatever is causing the problem?

Discussed with @reduz and decided it's better to move away from metadata all together to solve the problem with controls updating. The change that we've agreed upon in this discussion before affects core in a way that we don't really want (it's fine to have this hack in editor code, but not in core code).
So we should replace control.cpp's use of metadata with hidden properties. I'll work on it this week. Sorry for taking so long, and thanks for contributing nonetheless!

Isn't this change useful anyway? The inspector doesn't need to be refreshed on _meta properties.

@KoBeWi I agree, but @reduz finds this solution hacky and doesn't want to include hacky code in core. It's okay to have such code in editor, but not in core.


1610811: 17 files with lengthened SEO descriptions.

For User Story 1610811: SEO OKR: [ms.prod-console] Short description issue (33).

Docs Build status updates of commit b335c32:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/attachconsole.md
:white_check_mark:Succeeded
View

docs/closepseudoconsole.md
:white_check_mark:Succeeded
View

docs/console-font-info-str.md
:white_check_mark:Succeeded
View

docs/console-history-info.md
:white_check_mark:Succeeded
View

docs/console-readconsole-control.md
:white_check_mark:Succeeded
View

docs/console-screen-buffer-info-str.md
:white_check_mark:Succeeded
View

docs/console-screen-buffer-infoex.md
:white_check_mark:Succeeded
View

docs/console-selection-info-str.md
:white_check_mark:Succeeded
View

docs/createpseudoconsole.md
:white_check_mark:Succeeded
View

docs/getconsoleoriginaltitle.md
:white_check_mark:Succeeded
View

docs/getconsolescreenbufferinfo.md
:white_check_mark:Succeeded
View

docs/index.md
:white_check_mark:Succeeded
View

docs/input-record-str.md
:white_check_mark:Succeeded
View

docs/resizepseudoconsole.md
:white_check_mark:Succeeded
View

docs/scrollconsolescreenbuffer.md
:white_check_mark:Succeeded
View

docs/setconsolescreenbuffersize.md
:white_check_mark:Succeeded
View

docs/window-buffer-size-record-str.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 in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

#sign-off


fix(search-dropdown): fix done-button not working issue

To Reviewers

[ ] Skipping review is not a problem (style, chore ONLY)
[ ] Not that difficult

Type of Change

[ ] New feature
[x] Bug fixes
[x] Feature improvement

[x] These changes require a usage change

[ ] Others (performance improvement, refactoring, CI/CD, etc.)

Checklist

[x] Updated Storybook documents
[x] Tested with console

Description

Add click-done event to context-menu
Bind forceHideMenu event in search-dropdown to context-menu
Update context-menu docs
console QA-307

here

:tada: This PR is included in version 1.1.0-beta.430 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[feature request] we need issue templates to get more meaningful issues

Also see:
https://github.com/BrainLesion/tutorials/issues/40

Meanwhile, we do have issue templates, see: https://github.com/BrainLesion/tutorials/tree/main/.github/ISSUE_TEMPLATE
@neuronflow: I think this issue can be closed

@evamariie no this needs to be implemented for this repository :)
see what happens if you create an issue here for example:
https://github.com/BrainLesion/preprocessing/issues


Metal LB L2 Doesn't support different subnet from Node Subnet?

Hi,
We have setup a Metal LB configuration that is using L2 with the expected IP range for the Services of <IP_ADDRESS> -- <IP_ADDRESS>. The K8S host nodes are in a subnet of <IP_ADDRESS>/24. When we try to bring up the services with this configuration we get the following in the logs:
{"caller":"main.go:231","event":"endUpdate","msg":"end of service update","service":"default/nginx","ts":"2019-04-30T16:31:12.313383588Z"}
{"caller":"main.go:159","event":"startUpdate","msg":"start of service update","service":"default/service1","ts":"2019-04-30T16:31:12.313432991Z"}
{"caller":"main.go:229","event":"serviceAnnounced","ip":"<IP_ADDRESS>","msg":"service has IP, announcing","pool":"my-ip-space","protocol":"layer2","service":"default/service1","ts":"2019-04-30T16:31:12.313499851Z"}
{"caller":"main.go:231","event":"endUpdate","msg":"end of service update","service":"default/service1","ts":"2019-04-30T16:31:12.313563061Z"}
{"caller":"main.go:185","error":"assigned IP not allowed by config","ip":"<IP_ADDRESS>","msg":"IP allocated by controller not allowed by config","op":"setBalancer","service":"default/service1","ts":"2019-04-30T16:31:09.836280503Z"}
{"caller":"main.go:186","event":"endUpdate","msg":"end of service update","service":"default/service1","ts":"2019-04-30T16:31:09.836304077Z"}
and we never get the ARP requestsand thus, there is no connectivity externally to these services...
When we configure it to use a range in the same .52.0/24 subnet, this all works as expected, it gets assigned, ARPs, and we can connect from external nodes.
Now reading a bit more into the code and log message there, I noticed that the message indicates that it still was assigned a .52 IP subnet despite asking for an IP in the .50 subnet and because they mismatched, the service is destroyed. That makes sense... but not sure why are we getting an IP in the wrong pool.
Therefore, couple of questions:

Is this a known issue/limitation or just our setup? -- seems like this should be do-able
What determines the Pool's available IPs in Layer 2 (if not the config map)?
Is there a configuration necessary to use different subnets other than the K8S' Hosts

Any help is greatly appreciated.
Thanks!

With L2 and having Services not on the same network as the nodes you have to setup your own static routing on your network.
e.g.
1 - Node IP <IP_ADDRESS>
2 - Service IP : <IP_ADDRESS>

on cisco switch
ip route <IP_ADDRESS> <IP_ADDRESS> <IP_ADDRESS>

on comware switch
ip route-static <IP_ADDRESS> 32 <IP_ADDRESS>

on a windows system (works only if you are in the 10.120.52.x subnet)
route add -4 <IP_ADDRESS> mask <IP_ADDRESS> <IP_ADDRESS>

But in case the service is moved to a different node you have to adjust the routing again.

i considered how i too would run into this issue when trying to set up a kubernetes cluster with nodes that span different subnets.. ultimately i feel that using the L2 mode is not going to be possible, since the IP services are could not be on either subnet for them to be reacher from the greater network.. i think this is a usecase you pretty much have to turn to the BGP mode (and have that separate subnet be reachable based on routing decisions at L3 of the upstream routers, which get fed their information ala BGP via metallb)

This is just "how networks work". In L2 mode, the rest of the network has to know where the subnet is located, so that the machines know when they should forward packets via a router, or when they should make ARP requests to find a machine on the local ethernet segment.
Basically, to use an IP range for k8s service IPs, the rest of the network (non-k8s machines, routers, ...) must be configured just like if you had regular machines with those IPs.
I want to keep this tracker specifically for bugs and features, so I'm going to close this. At some point I may have time to write general troubleshooting documentation, but as a first step towards that I need to clear up the issue tracker.
You could try asking for help on the #metallb channel on the Kubernetes slack.


Allow multiple environments to be specified

We should allow multiple environment tags to be specified in the command line switch, so that there can be a loose grouping of scripts into 'environments' and different sets of them can be applied as needed.
E.g. If I have a set of scripts which should be applied to ALL qa environments, but also have one script which differs across each of the qa environments.

Thinking just allowing something comma delimited, e.g. --environment qa,foo,bar,baz

Merged in this feature in pull request https://github.com/paybyphone/soothsayer/pull/10


Make file header on git commit preview clickable to open file

Summary

When inspecting a commit, each file affected has a header in the commit preview:

My feature request is to turn this into a clickable link, if the file still exists in the repository. If the file doesn't exist, the link can appear faded, unclickable, give a "File was deleted" alert on click, or any combination of the above.
Motivation

Currently, if we want to look at an entire file that was changed in a commit from the commit preview tab, read the entire file path from the header and manually navigate to that file in the file explorer.
Describe alternatives you've considered

I think this makes sense to include in the main branch since it's just fleshing out an existing user interface feature and improving the Atom git workflow.

is this still a current request or has this been completed?

I think (I'm not sure) that you should edit https://github.com/atom/github/blob/master/lib/models/patch/file-patch.js some where is somebody wants to contribute.
Personally, I'd hack it with some JavaScript

Okay. I am going to give it a shot
Sent from my iPhone

On Feb 19, 2021, at 11:10 AM, ThatXliner<EMAIL_ADDRESS>wrote:

I think (I'm not sure) that you should edit https://github.com/atom/github/blob/master/lib/models/patch/file-patch.js some where is somebody wants to contribute.
Personally, I'd hack it with some JavaScript
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.


Add working Node artifact builder for all platforms

This fixes #4768.
The build succeeded on all platforms

needs resolving.

LGTM


Update 'Dictionary' Feature : Fix Dictionary List Panel Display Bug

Codecov Report

Merging #256 (c463bff) into master (f4987ef) will decrease coverage by 0.04%.
The diff coverage is 42.85%.

@@             Coverage Diff              @@
##             master     #256      +/-   ##
============================================
- Coverage     57.59%   57.55%   -0.05%
+ Complexity      832      828       -4
============================================
  Files           169      169
  Lines          3139     3145       +6
  Branches        314      314
============================================
+ Hits           1808     1810       +2
- Misses         1206     1207       +1
- Partials        125      128       +3

Impacted Files
Coverage Δ
Complexity Δ

...e/logic/commands/ShowDictionaryContentCommand.java
25.00% <ø> (ø)
2.00 <0.00> (ø)

...va/seedu/dictionote/ui/DictionaryContentPanel.java
0.00% <0.00%> (ø)
0.00 <0.00> (ø)

...dictionote/logic/parser/EditNoteCommandParser.java
80.00% <100.00%> (ø)
7.00 <0.00> (ø)

...main/java/seedu/dictionote/model/ModelManager.java
68.07% <100.00%> (+2.21%)
45.00 <0.00> (+1.00)

.../dictionote/logic/commands/FindContentCommand.java
33.33% <0.00%> (-22.23%)
2.00% <0.00%> (-3.00%)

...l/dictionary/ContentContainsKeywordsPredicate.java
71.42% <0.00%> (-14.29%)
3.00% <0.00%> (-2.00%)

Continue to review full report at Codecov.

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


Select multiple messages/attachments to be able to forward together all at once

No content

Issue created by BlueBubbles Bot in the BlueBubbles commnity on behalf of @Blank in #requests.

Backlogged because we have a ton of other issues we need to get done

This might be related to issue #542

done


color.space and color.spaceId should be immutable

There is literally no reason to ever change a color's color space, it's trivial to just create a new object via color.to(whatever) and it's what most demos do. Making it immutable will simplify implementation and improve performance and is more consistent with the Color API.

Fixed via #149


CHEF-2691 add preserve_mode true to remote_directory provider

If you have secret files you want to chmod 600 in your remote_directory but you want the default to be 644 for the rest of the files there's no way to specify that.  It would be nice to have preserve_mode true added to remote_directory so that .ssh priv keys could be copied out, and a subsequent file resource could repair their modes to 600 and then on a subsequent run the file mode would get preserved and the resources wouldn't thrash.

link to @jkeiser's original ticket: https://tickets.opscode.com/browse/CHEF-2691

BUMP! This is rather annoying.

This oldie by goodie is causing problems for me today.  So there is still some desire to see this new preserve_mode attribute to the remote_directory resource.  Thanks!

maybe preserve_mode [ <array of file paths> ] would be even better, then enforcement could happen on most of the files remote_directory manages, but exceptions could be made, rather than just turning off enforcement for everything.


sap.m.SplitApp / sap.m.Container -- Opacity value interpretation

SAPUI5 version 1.36.11
Browser/version (+device/version): Chrome / Windows
URL (minimal example if possible):
http://jsbin.com/socekewate/edit?html,output
Steps to reproduce the problem:

just use the slider to check the values and the transparency / opacity of the background image
documentation says: between 0 (fully transparent) and 1 (fully opaque)
I guess it works the other way

What is the expected result?
Documentation does not fit to the implementation.
What happens instead?
The opposite.
Any other information? (attach screenshot if possible)

By the way, try to use the slider with min:0.0 and max: 1.0

I would also prefer to have non transparent app by default. If you add a background image with theme designer the page looks bad. Or is there a way to define a background image just for the Fiori Launchpad? Maybe it would make sense to introduce some property only for Fiori Launchpad. In a normal application a background image is not so helpful.

Thanks sfd..., thats a really important finding. I forwarded it straight to the developer that did the change and he will give you an update soon. Internally tracked as #1680052675
Kind regards,
Michael

Erm, no: the documentation clearly states that this property controls the opacity of the background image, and that's what it does: value==1 means the colorful triangles image, which is configured as background image, is fully visible.

Thanks for clarifiying, i was too fast with my analysis

And not sure what is strange about using 0.0 to 1.0 as slider range. Ok, the slider has a default step size of 1, so you can only toggle between 0 and 1, but this works fine for me. It feels better of course when there are more steps in between, so one could set step: 0.01 to make it smoother.
(Of course you divide the slider value by 100, so the resulting range (0.0..0.01) is not reasonable for opacity values anymore.)


Add static directory with github badge

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

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

People will be able to add this badge to their repo using the following markdown:
[![Scribble](https://github.com/ConsenSys/scribble/raw/develop/static/annotated_badge.png)](https://github.com/consensys/scribble)

People will be able to add this badge to their repo using the following markdown:
[![Scribble](https://github.com/ConsenSys/scribble/raw/develop/static/annotated_badge.png)](https://github.com/consensys/scribble)


[FR] Enhancing BoM exporting with subassemblies by splitting subassemblies on other sheets

Please verify that this feature request has NOT been suggested before.

[X] I checked and didn't find a similar feature request

Problem statement
When exporting a BoM including subassemblies, the resulting BoM is completely flattened when selecting level 0 and might make the file a bit tough to read.
Suggested solution
When exporting to .xlsx or .xls, an option could be added to put the BoMs of the subassemblies on other sheets. For csv files, the subassembly BoMs could simply be exported as multiple files zipped.
This makes the files more readable, and makes it better for being printed out : all subassemblies can be printed independently to perform real-life stock allocation.
Describe alternatives you've considered
This could also be done with a simple "post-prod" python script, that reads a csv file and splits the subassemblies to other files, or perform the splitting in .xls / .xlsx sheets.
Examples of other systems
No response
Do you want to develop this?

[ ] I want to develop this.

@JambonLeVrai I am not sure if we can export to sub-sheets with our existing tech stack. Of course exporting multiple sub files for each sub assembly is already possible (although manual and time consuming).
Exporting all files as a single archive would be achievable but could potentially take some time for the server to format and zip. This will require some further though


add cache dir

Description
Add temp cache dir to load the tokenizer and model into
Checklist:

[ ] My code follows the code style of this project, as detailed in our contribution guidelines.
[ ] I have added tests.
[ ] I have updated the documentation accordingly.

I think you'll need to tear down the tmp directory manually at the end of the notebook, like in the last cell of this notebook. Otherwise, the tmp directory will be there for a while or until you reboot the machine, I'm not exactly sure.

I think you'll need to tear down the tmp directory manually at the end of the notebook, like in the last cell of this notebook. Otherwise, the tmp directory will be there for a while or until you reboot the machine, I'm not exactly sure.

Shouldn't be a big deal. The most recent k dirs will stay until new tests are run.

I think you'll need to tear down the tmp directory manually at the end of the notebook, like in the last cell of this notebook. Otherwise, the tmp directory will be there for a while or until you reboot the machine, I'm not exactly sure.

Shouldn't be a big deal. The most recent k dirs will stay until new tests are run.

@daden-ms I think you investigated this at one point and figured out tearing down the directories at the end of the notebook was necessary.

Yes, it might be helpful for the users if we put removing temp directory in the notebook. Some notebooks download large amounts of data and save the models multiple times and it can cost quite some disk space. If the user doesn't restart their machine often, it can cause a mysterious notebook and bash problems which can be hard to debug.


Add support for marker icons from classpath

This feature is probably really hackish to implement.

Since there's no real need for this, I close this issue as wontfix.


Update uuid to version 3.0.0

Version 3.0.0 of uuid just got published.
Hi there,
This week a new version of the uuid module got released. The old module which was available by the name node-uuid got deprecated and will show error message upon every install of the module.
To get rid of those install errors I've created this automated pull request. I've run some checks against your code base to test whether you're using one of the deprecated apis, but this isn't the case.
Please test the changes against your code. I didn't run any tests and therefore can't guarantee that it isn't breaking. You can also just close this pr if you don't want to update your module.
In case there's already another pr open to upgrade uuid, I'm sorry for the effort I'm causing.

thank you for your initiative, @marcbachmann!
recognised the same thing yesterday evening during tinkering with my libs. very appreciate! will check & merge as soon as possible.


This change was premature because moved methods in Track class
are not pure virtual and return nullptr by default.
Test: builds

the change in question was not yet pushed. This one is fine.


ext_authz Envoy filter dosen't take effect

(NOTE: This is used to report product bugs:
To report a security vulnerability, please visit https://istio.io/about/security-vulnerabilities
To ask questions about how to use Istio, please visit https://discuss.istio.io)
Bug description
Hi, I am trying to apply an ext_authz envoy filter which expect to talk with my external authz server, but it seems doesn't take effect. I am not sure if it's due to the istio/envoy version or not and expect to find some workaround if possible.
Here is the configuration.
apiVersion: v1
kind: Service
metadata:
  name: ext-authz
  namespace: stg-php
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

---

apiVersion: v1
kind: Endpoints
metadata:
  name: ext-authz
  namespace: stg-php
subsets:
  - addresses:
      - ip:  <exteranl-authz-server-ip-address>
    ports:
      - port: 80

---

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: ext-authz-ef
  namespace: stg-php
spec:
  workloadSelector:
    labels:
      # Here I am selecting the workload, instead of applying it to the istio-ingressgateway
      app: <the-workload-labels>.
  filters:
  - listenerMatch:
      listenerType: SIDECAR_INBOUND
      listenerProtocol: HTTP
    insertPosition:
      index: FIRST
    filterName: envoy.ext_authz
    filterType: HTTP
    filterConfig:
      http_service:
        server_uri:
          uri: http://ext-authz.stg-php.svc.cluster.local:80
          cluster: outbound|80||ext-authz.stg-php.svc.cluster.local
          timeout: 0.25s
          failure_mode_allow: false

and I tried to examine the workload pod, by istioctl pc listener <workload-pod-name> --port 80 -ojson , but cannot find the filter envoy.ext_authz
Affected product area (please put an X in all that apply)
[ ] Docs
[ ] Installation
[x] Networking
[ ] Performance and Scalability
[x] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
[ ] Upgrade
Affected features (please put an X in all that apply)
[ ] Multi Cluster
[ ] Virtual Machine
[ ] Multi Control Plane
Expected behavior
Expect the ext_authz filter would appear on my workload listener filter chain.
Steps to reproduce the bug
Version (include the output of istioctl version --remote and kubectl version --short and helm version --short if you used Helm)
client version: 1.2.7
citadel version: 1.2.7
galley version: 1.2.7
ingressgateway version: 1.2.7
ingressgateway version: 1.2.7
pilot version: 1.2.7
pilot version: 1.2.7
pilot version: 1.2.7
pilot version: 1.2.7
pilot version: 1.2.7
policy version: 1.2.7
sidecar-injector version: 1.2.7
telemetry version: 1.2.7
How was Istio installed?
helm
Environment where the bug was observed (cloud vendor, OS, etc)
Additionally, please consider running istioctl bug-report and attach the generated cluster-state tarball to this issue.
Refer cluster state archive for more details.

B.T.W, I am not able to use patch syntax as suggested in https://github.com/istio/istio/issues/24462 and https://github.com/istio/istio/issues/26805. So that's why I raise the issue here to see if anyone has some idea about it.

B.T.W, I am not able to use patch syntax as suggested in https://github.com/istio/istio/issues/24462 and https://github.com/istio/istio/issues/26805. So that's why I raise the issue here to see if anyone has some idea about it.

I tried to reproduce this on 1.8.0 using app=httpbin.  Pilot does a push when the EnvoyFilter is created.  Envoy logs some unrelated deprecation warnings but does not log anything about this filter nor did I see this filter in the /config_dump.

I tried to reproduce this on 1.8.0 using app=httpbin.  Pilot does a push when the EnvoyFilter is created.  Envoy logs some unrelated deprecation warnings but does not log anything about this filter nor did I see this filter in the /config_dump.

You are using a version that has been EOL for a very very long time. Please update to Istio 1.8: https://istio.io/latest/news/support/announcing-1.6-eol/

You are using a version that has been EOL for a very very long time. Please update to Istio 1.8: https://istio.io/latest/news/support/announcing-1.6-eol/

I tried to reproduce this on 1.8.0 using app=httpbin. Pilot does a push when the EnvoyFilter is created. Envoy logs some unrelated deprecation warnings but does not log anything about this filter nor did I see this filter in the /config_dump.
ProxyStatus was all matches
istioctl ps httpbin-779c54bf49-2jdg9
Clusters Match
Listeners Match
Routes Match (RDS last loaded at Mon, 04 Jan 2021 09:18:23 EST)

Pilot doesn't seem to be sending this filter to Envoy, but also not rejecting it as invalid.

Thank you @esnible . Does it mean the configuration is not correct even if tested on istio 1.8?

I tried to reproduce this on 1.8.0 using app=httpbin. Pilot does a push when the EnvoyFilter is created. Envoy logs some unrelated deprecation warnings but does not log anything about this filter nor did I see this filter in the /config_dump.
ProxyStatus was all matches
istioctl ps httpbin-779c54bf49-2jdg9
Clusters Match
Listeners Match
Routes Match (RDS last loaded at Mon, 04 Jan 2021 09:18:23 EST)

Pilot doesn't seem to be sending this filter to Envoy, but also not rejecting it as invalid.

Thank you @esnible . Does it mean the configuration is not correct even if tested on istio 1.8?

@hustshawn Your EnvoyFilter contents aren't being sent to Envoy.  I suspect this is because you couldn't get "patch" working.  It is needed.  It might be best to start with some Istio config, such as manifests/charts/istio-control/istio-discovery/templates/telemetryv2_1.8.yaml , and try to mutate that.

@hustshawn Your EnvoyFilter contents aren't being sent to Envoy.  I suspect this is because you couldn't get "patch" working.  It is needed.  It might be best to start with some Istio config, such as manifests/charts/istio-control/istio-discovery/templates/telemetryv2_1.8.yaml , and try to mutate that.

@esnible Thank you again. I did notice the syntax of EnvoyFilter changed a lot between Istio 1.2.7 and Istio 1.8+, and not compatible. Due to many complex reasons, we are not able to upgrade the legacy Istio right now.
It seems I really cannot get the EnvoyFilter working on the Istio 1.2.7.

@esnible Thank you again. I did notice the syntax of EnvoyFilter changed a lot between Istio 1.2.7 and Istio 1.8+, and not compatible. Due to many complex reasons, we are not able to upgrade the legacy Istio right now.
It seems I really cannot get the EnvoyFilter working on the Istio 1.2.7.


Tableau Dialect Definition File // Mapping of a function dependent on the version of the Denodo server

About You:
Name: Carlos Santos Canelles
Company: Denodo Technologies
Your question:
In the Tableau Dialect Definition File (.tdd file), can I define the mapping of a function to depend on the version of the Denodo server I am connecting?
Or maybe, to include two .tdd files in the .taco and that the connector chooses one or the other depending on the version of Denodo that the user is connecting to. Is this currently possible (or in the roadmap)?
Our goal
Due to customer request, we are considering adding a function like split_part(string text, delimiter text, field int) to support the Tableau feature Split a Field into Multiple Fields. Currently, Denodo does not have any function like split_part so our connector cannot support the "split field into multiple fields". If we add the function "split_part", we will only add it to the latest major version of Denodo (v8.0) but not to the previous one (v7.0) but we still want the connector to be compatible with both version 8.0 and 7.0.
We have other similar use cases raised by customers where we would also need to do something like this.
Background Information
Tableau already has a native connector for Denodo, which uses the PostgreSQL ODBC driver to connect to Denodo. This connector was added to Tableau 6 years ago.
We have developed a new connector that uses the JDBC driver of Denodo, which performs better than the PostgreSQL ODBC driver. This new connector is already in the Tableau Gallery, in beta.

Internal tracking id: 1343832

@jie-d, is this currently possible? By reading the documentation of the SDK, it seems this is not possible. I just want to confirm that I understood the documentation correctly.
It would be great if this is possible in the future but right now, I just want to know if it is possible or not.

Hi Carlos,
I am a Product Manager in the Connectivity team. This functionality is currently not possible. You read the documentation correctly.
Thanks & Regards,
Vasanthi Neelagiri
Product Manager,
Connectivity


Alphabetical file sorting also sorts components/add-ons

Images are from staging, but the issue is the same on production.
Steps
1. Visit a project with multiple components and an add-on (https://staging.osf.io/frzcd/)
2. Note the order of the components on the right
3. Note that the order of the components in the file tree on the left matches the order on the right
![screen shot 2015-01-26 at 3 28 31 pm](https://cloud.githubusercontent.com/assets/4965832/5907831/306d8978-a570-11e4-956f-647a5dd6f63a.png)
4. Click on the sort by name button to make the files sort alphabetically (ascending or descending)
Expected
1. Components/Add-ons would stay in their original order
2. Files within each add-on or component would sort alphabetically
Actual
1. Components and add-ons are included in the alphabetical sorting. They are sorted by the first letter that is displayed, meaning components like "Component: ZZZ" (starts with a C) is placed before the top-level project's OSF storage (starts with an O).
![screen shot 2015-01-26 at 4 12 05 pm](https://cloud.githubusercontent.com/assets/4965832/5908501/1e2051aa-a576-11e4-9a4e-4ce6dfc06d11.png)

Within each component/add-on folder, files are sorted alphabetically (correctly)

This might be more of a discussion item, but I would prefer that components and other add-ons stay in their position when files are sorted, and just those files within them get alphabetized. This way top-level file storage and add-ons don't get misplaced.

@caneruguz With Treebeard -- What is our intended / expected functionality here? All  files + folders in alphabetical or reverse alphabetical order depending on selection?

For some reason I didn't get a notification for being tagged in this issue or what's mroe likely it that I archived it with many other github notices coming my way.  I would have addressed this issue before our release otherwise.
Treebeard is a library so it's rules are very general, the intended behavior is that it applies throughout the entire list.
However Files page has already many of its own functionality so we can easily add something here that makes the sorting start at a certain depth. It would be very easy to do.
Can someone assign me to this?

@caneruguz Done!


Add proxy support (error ECONNREFUSED)

Please add proxy support. Currently it throws exception if proxy is required (for all http connections).
Exception:
events.js:72
              throw er; // Unhandled 'error' event

Error: connect ECONNREFUSED
      at errnoException (net.js:904:11)

I added these two lines into initDB.js:
var restDef = require('request');
var rest = restDef.defaults({proxy: "http://USERNAME:PASSWORD@PROXY_IP:PORT"});

So command 'node server/initDB.js' works.
But  'node server.js' doesn't (it throws exception above).

i get a unescaped character error after doing your solution using command 'node server/initDB.js'
Checking that admin user does not exist...
rest.get - https://api.mongolab.com/api/1/databases/kcfdb/collections/us
_http_client.js:73
throw new TypeError('Request path contains unescaped characters.');

I am able to run project locally at home.
But when I try to run it at my workplace
I am also getting the same error like @kcferguson1.
I know this is a firewall issue. Please someone update here if you guys found a way to add proxy and run this project smoothly.


install fail with npm error

Elasticsearch version:  6.4.2
Moloch version: lastest git pull
OS name and version:  Ubuntu 16.04.5
How was Moloch built/installed: (rpm, deb, easybutton, ...)  Easybutton
Provide logs, stack traces and steps to reproduce:
After easybutton build, make install fails:
Making install in .
make[1]: Entering directory '/root/manual_installs/moloch'
make[2]: Entering directory '/root/manual_installs/moloch'
npm install
up to date in 1.511s
/usr/bin/install -c -D package.json /data/moloch/package.json
/usr/bin/install -c -D package-lock.json /data/moloch/package-lock.json
(cd /data/moloch ; npm install --production)
up to date in 1.47s
rm -f /data/moloch/package-lock.json
make[2]: Nothing to be done for 'install-data-am'.
make[2]: Leaving directory '/root/manual_installs/moloch'
make[1]: Leaving directory '/root/manual_installs/moloch'
Making install in capture
make[1]: Entering directory '/root/manual_installs/moloch/capture'
/usr/bin/install -c -d /data/moloch/bin
(cd parsers; make install)
make[2]: Entering directory '/root/manual_installs/moloch/capture/parsers'
/usr/bin/install -c *.so *.jade /data/moloch/parsers
make[2]: Leaving directory '/root/manual_installs/moloch/capture/parsers'
(cd plugins; make install)
make[2]: Entering directory '/root/manual_installs/moloch/capture/plugins'
/usr/bin/install -c taggerUpload.pl /data/moloch/bin
/usr/bin/install -c *.so *.jade *.js /data/moloch/plugins
/usr/bin/install -c wiseService/*.js wiseService/wiseService.ini.sample wiseService/package.json /data/moloch/wiseService
(cd /data/moloch/wiseService ; npm install --production)
npm WARN The package jshint is included as both a dev and production dependency.

up to date in 1.227s
/usr/bin/install -c writer-s3/*.js writer-s3/package.json /data/moloch/plugins/writer-s3
(cd /data/moloch/plugins/writer-s3 ; npm install --production)
npm WARN<EMAIL_ADDRESS>No description
npm WARN<EMAIL_ADDRESS>No repository field.
npm WARN<EMAIL_ADDRESS>No license field.

up to date in 0.142s
make[2]: Leaving directory '/root/manual_installs/moloch/capture/plugins'
/usr/bin/install -c *.h thirdparty/http_parser.h /data/moloch/include
/usr/bin/install -c moloch-capture /data/moloch/bin/moloch-capture
make[1]: Leaving directory '/root/manual_installs/moloch/capture'
Making install in db
make[1]: Entering directory '/root/manual_installs/moloch/db'
/usr/bin/install -c daily.sh db.pl elasticsearch.yml.sample runes.sh.sample /data/moloch/db
make[1]: Leaving directory '/root/manual_installs/moloch/db'
Making install in viewer
make[1]: Entering directory '/root/manual_installs/moloch/viewer'
/bin/rm -f /data/moloch/viewer/public/style.css
/usr/bin/install -c *.js package.json package-lock.json /data/moloch/viewer
npm ci

Usage: npm <command>

where <command> is one of:
    access, adduser, bin, bugs, c, cache, completion, config,
    ddp, dedupe, deprecate, dist-tag, docs, doctor, edit,
    explore, get, help, help-search, i, init, install,
    install-test, it, link, list, ln, login, logout, ls,
    outdated, owner, pack, ping, prefix, profile, prune,
    publish, rb, rebuild, repo, restart, root, run, run-script,
    s, se, search, set, shrinkwrap, star, stars, start, stop, t,
    team, test, token, tst, un, uninstall, unpublish, unstar,
    up, update, v, version, view, whoami

npm <command> -h     quick help on <command>
npm -l           display full usage info
npm help <term>  search for help on <term>
npm help npm     involved overview

Specify configs in the ini-formatted file:
    /root/.npmrc
or on the command line via: npm <command> --key value
Config info can be viewed via: npm help config

<EMAIL_ADDRESS>/root/.nvm/versions/node/v8.11.1/lib/node_modules/npm

Did you mean one of these?
    c
    i
Makefile:15: recipe for target 'install' failed
make[1]: *** [install] Error 1
make[1]: Leaving directory '/root/manual_installs/moloch/viewer'
Makefile:326: recipe for target 'install-recursive' failed
make: *** [install-recursive] Error 1

node 8.12 is now required


Can't read games from SD card

I DIY an Esplay Micro compatible device using ESP32 WROVER, flashed esplay base firmware to it, and then successfully flashed "esplay-retro-emu.fw" from SD Card. However once it rebooted into Esplay Retro main interface, it could not find the *.nes games under the \roms\nes folder, always showed "0 games available", do you know what's the issue? Based on my understanding, the base firmware could read and flashed "esplay-retro-emu.fw" file from SD Card, it means the SD Card had been detected successfully. I have made sure the folders on SD Card were unzip from your "skeleton.zip" file.

Hello, could you try to debug using serial, if there's any useful information

Thanks for reply, following is the serial output during boot up:
ets Jun  8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x1b (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:6736
ho 0 tail 12 room 4
load:0x40078000,len:8900
load:0x40080000,len:7392
entry 0x4008039c
I (30) boot: ESP-IDF v3.1-odroid-1-g08f2c8f26 2nd stage bootloader
I (30) boot: compile time 11:33:25
I (30) boot: Enabling RNG early entropy source...
I (36) qio_mode: Enabling default flash chip QIO
I (41) boot: SPI Speed      : 80MHz
I (46) boot: SPI Mode       : QIO
I (50) boot: SPI Flash Size : 16MB
I (54) boot: Partition Table:
I (57) boot: ## Label            Usage          Type ST Offset   Length
I (65) boot:  0 nvs              WiFi data        01 02 00009000 00004000
I (72) boot:  1 otadata          OTA data         01 00 0000d000 00002000
I (80) boot:  2 phy_init         RF data          01 01 0000f000 00001000
I (87) boot:  3 firmware         factory app      00 00 00010000 00040000
I (94) boot:  4 launcher         OTA app          00 10 00050000 00140000
I (102) boot:  5 esplay-nofrendo  OTA app          00 11 00190000 00080000
I (109) boot:  6 esplay-gnuboy    OTA app          00 12 00210000 00070000
I (117) boot:  7 esplay-smsplusgx OTA app          00 13 00280000 00120000
I (125) boot: End of partition table
I (129) esp_image: segment 0: paddr=0x00050020 vaddr=0x3f400020 size=0x7ac54 (502868) map
I (271) esp_image: segment 1: paddr=0x000cac7c vaddr=0x3ffb0000 size=0x031d4 ( 12756) load
I (275) esp_image: segment 2: paddr=0x000cde58 vaddr=0x40080000 size=0x00400 (  1024) load
I (278) esp_image: segment 3: paddr=0x000ce260 vaddr=0x40080400 size=0x01db0 (  7600) load
I (289) esp_image: segment 4: paddr=0x000d0018 vaddr=0x400d0018 size=0xa7718 (685848) map
I (476) esp_image: segment 5: paddr=0x00177738 vaddr=0x400821b0 size=0x1401c ( 81948) load
I (502) esp_image: segment 6: paddr=0x0018b75c vaddr=0x400c0000 size=0x0006c (   108) load
I (515) boot: Loaded app from partition at offset 0x50000
I (515) boot: Disabling RNG early entropy source...
audio_init: sample_rate=44100
input_gamepad_init done.
ILI9341 initialization.
Enable backlight.
Backlight initialization done.
ADC: Characterized using eFuse Vref
E (11685) sdmmc_req: sdmmc_host_wait_for_event returned 0x107
E (11685) sdmmc_sd: sdmmc_check_scr: send_scr returned 0x107
sdcard_open: esp_vfs_fat_sdmmc_mount failed (263)
Ready, AP on channel 5
opendir failed.

I tried several regular SD Cards (9 pins), get the same result. My connection is:
Pin3 CMD I/O -> ESP32 GPIO15
Pin4 -> GND
Pin5 -> 3V3
Pin6 CLK -> ESP32 GPIO14
Pin7 -> GND
Pin8 DAT0 -> ESP32 GPIO2
Pin3, Pin6, Pin8 are pulled up to 3V3 by 10K resistors.
Is it possible to add the same SD Card support as base firmware to the "esplay-retro-emu.fw"?
Thank you very much!

Hmm your connection seems okay, did u compile yourself the fw file?

No, I used your compiled "esplay-retro-emu.fw" file.

It's strange if esplay base firmware works then it should be work for emulator also. Press menu button while powering on should be back to bootloader, then try reflashing the fw file again

Yes, I refreshed several times, it could always see SD card in base firmware and flashed  "esplay-retro-emu.fw" file from SD card successfully, but once booted into esplay retro main screen, it could not see the SD card anymore. It's weird. Not sure if the base firmware and esplay retro use different SD card drivers?

Hi, yes the only different in the driver is in emulator a use highspeed freq mode setting. could you compile yourself esplay emulator from source? try disabling highspeed mode in sdcard driver, cause to use highspeed mode you have to make sure a good connection.

Thank you for the reply. Can you shed me some light on how to disable high speed mode in sdcard driver? Since I am still pretty new to ESP-IDF, if it does not trouble you too much, could you help to compile a firmware with high speed mode disabled? I will try it and report to you the result.

Sorry i broke my esp environtment, i will try next weekend. If you want to try yourself, the driver is in esplay-sdk folder.

Thank you very much! I tried couple times recently, but could not compile successfully, looked like the ESP-IDF V3. 3 I installed was not the right version. If you can compile the firmware for me, that wiil be great!


Contact page

Adds Contact page
Adds form to contact page
Adds link to footer

Subject of the email received is "Openstack Foundation:  Thank you for your inquiry". We should update that to OpenInfra Foundation


Update to use svd2rust 0.6.* API for Exceptions and Interrupt handlers

This template has been deprecated in favor of the cortex-m-quickstart template.


Fallback policy not triggering for retrival intents or sub intents

What problem are you trying to solve?
Hi
I am unable to trigger the fallback policy for rasa retrieval intents or sub-intents of the main faq class.
I’ve 220 faq questions defined as sub intents of the main intent faq. When some random questions such as ‘How is the weather or how is life going or shall I invest in cryptos?’ are asked, the system defaults to faq intent with 0.99 probability.
Afterward, it picks a random faq answer (sub intent/retrieval intent) (with the highest confidence of ~0.1) and throws back its response. I was able to ascertain this by running rasa in debug and nlu mode.
nlu and domain example:
intent: faq/FAQ_ID_08 examples: |
Asset status when workorder is raised for lost tool utter_faq/FAQ_ID_08:
text: 'The workorder status will be UNDER TOOLS SEARCH until the tool is found. ’ Domain:
utter_please_rephrase:
text: I’m sorry, I didn’t quite understand that. Could you rephrase? text: I didn’t quite get it. Can you put it in different words? text: Apologies, I did not understand. Can you ask in again in different words? Rules:
rule: Ask the user to rephrase whenever they send a message with low NLU confidence steps: intent: nlu_fallback action: utter_please_rephrase Config:
name: FallbackClassifier threshold: 0.3 ambiguity_threshold: 0.1 Rasa version: 2.4.3
What's your suggested solution?
The system needs to treat sub-intents or retrieval the same as regular intents while checking intent confidence scores (matching from the existing list of intents) instead of grouping in FAQ singular intent.
The fallback classifier needs to treat each sub-intent as a separate intent while triggering a fallback policy instead of treating faq as a singular intent encompassing all 220 (or more) sub-intents. In an faq heavy chatbot with way more faqs than regular intents, it leads to faq having a confidence score of 0.99 while others including fallback have negligible confidence.
Examples (if relevant)
https://forum.rasa.com/t/fallback-policy-not-triggering-for-retrival-intents-or-sub-intents/45504/2
Is anything blocking this from being implemented? (if relevant)
No response
Definition of Done
If in a >200 sub intent containing system with <10 other intents, the bot is able to trigger the fallback classifier when asked out of context questions.

Have the same problem with a FAQ and would like to see this implemented

Thanks for submitting this feature request 🚀 @amn41 will get back to you about it soon! ✨

That's a great point, I often encounter the same problem where many sub-intents have about the same probability. I don't think the number of sub-intent should matter though.
One workaround you can do (but it's a bit painful and manual) is to create a custom action to answer to this faq and you manually check the confidence of the top N sub-intents that were picked. If you're confident that it's the right sub-intent, you can utter the response and if not, trigger the fallback. It's obviously not ideal and I'd much better have a configurable solution as suggested here!

@amn41 is there any updates on this?

I have the same issue and would like to see a solution implemented.

I have the same issue and would like to see a solution implemented.

+1


Update groups-naming-policy.md

@yyuank : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@yyuank : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Hi @yyuank - This pull request was opened in the public repo. PMs should work in the private repo, per the Microsoft Docs contributor guide. We can keep this PR open for review and merge, but would you make future content updates in the private repo? Thank you!

Hi @yyuank - This pull request was opened in the public repo. PMs should work in the private repo, per the Microsoft Docs contributor guide. We can keep this PR open for review and merge, but would you make future content updates in the private repo? Thank you!

I remembered that right after I submitted this PR. Then I made the PR in my private repro. Could you please help remove this PR?

I remembered that right after I submitted this PR. Then I made the PR in my private repro. Could you please help remove this PR?

@yyuank You bet. Thank you!

@yyuank You bet. Thank you!


New version: Jackett.Jackett version 0.20.3861

Pull request has been created with WinGet Releaser v2 :rocket:
Microsoft Reviewers: Open in CodeFlow

@wingetbot run


Sharing Dynamic Data with a Schedule?

Hi,
I've been messing around with a proof of concept built using Pode but I've hit somewhat of a hurdle with regard to safely sharing state/session data so that I can relay data to the correct client. I've a copy of the demo in a private repository so please let me know if you'd prefer access to it to test things!
Summary of the concept:

Add-PodeRoute for GET /pagename to render a page (.pode file) with a form. Include JavaScript that opens a websocket on the same path.
Add-PodeSignalRoute for /pagename to receive form data over the websocket.

This triggers Invoke-PodeSchedule which runs a (potentially very large and complex) backend script that does a series of 'tasks'.
Finally: Send-PodeSignal with -ClientId $SignalEvent.ClientID back to the client to essentially say 'ok'/'started'.

Backend script that makes (internal) HTTP POST requests to the server.

Add-PodeRoute for POST /pagename to receive task related data and pass it back to the client with Send-PodeSignal.

Custom JavaScript decides on how this is rendered in the browser.

Visually:

Problem
In one line: Invoke-PodeSchedule and the triggered backend script is unable to accurately determine who the client is, so currently updates are broadcast to all clients connected on /pagename (i.e. you'd see the table of tasks and progress visible in any browser open to /pagename).
A bit more information: Whilst Send-PodeSignal -Value @{ message = "x" } -ClientId $SignalEvent.ClientID works for talking back to a client within the route itself, the decoupled scheduled script can't access $SignalEvent, nor can I pass this via Invoke-PodeSchedule (at least not to my knowledge).
I initially thought to use Get/Set-PodeState to save the client id into the pode state file within the route before triggering the scheduled script which could grab said id, but of course technically it's not 'safe' as multiple clients could be executing this page with different data.
Any ideas? :)

Ooo, I never thought about doing Send-PodeSignal from a schedule you know! Interesting.
Schedules/Timers are isolated from Routes in different Runspaces, and outside of any Web/SignalEvent context. You're right with State that it would be unsafe, as it's all client session specific data 🤔.
At the moment I don't think there's actually a clean way of doing this. It looks like it might need a new -ArgumentList parameter on Invoke-PodeSchedule, so you can:
Add-PodeSchedule -Etc -ScriptBlock {
    param($Event, $ClientId)
    Send-PodeSignal -Value @{ message = "x" } -ClientId $ClientId
}

Add-PodeSignalRoute -Etc -ScriptBlock {
    Invoke-PodeSchedule -Etc -ArgumentList @{ ClientId = $SignalEvent.ClientId }
}

Yes, that'd solve the problem! (though I'm using a file for the schedule rather than a script block). This would let me access both the client ID and the form data submitted too - perfect :)

Thanks for adding this to the next milestone :) I opened up the POC over at incase this helps with testing / saves you writing code to test: https://github.com/robinmalik/podedemo

I've added an -ArgumentList to Invoke-PodeSchedule, so you should be able to do:
Invoke-PodeSchedule -Name 'get-user-details' -ArgumentList @{ ClientId = $SignalEvent.ClientId }

to pass the ClientId to the schedule, and in the schedule's file have:
return {
    param($ClientId)

    # ...

    Send-PodeSignal -Value @{} -ClientId $ClientId
}

I had a look through your PoC (awesome btw!), but couldn't find where/somewhere to put an appropriate Send-PodeSignal. I tweaked the timer/schedule examples in Pode, and tested that the args are passed 😃

Ahh amazing, I'll test this later today!

🥳 all working! (the route triggered by form submission can now pass the client ID and the user submitted form data over to the 'scheduled' script and so we can 1) act on submitted form data and 2) return it to the right client).
Thanks so much for adding this. I'll try and find time to review the changes you made as I'd really like to understand how Pode is working under the hood.
I'll close this off now :)


htmlspecialchars() expects parameter 1 to be string, object given

Hi
I get htmlspecialchars() expects parameter 1 to be string, object given error in ckeditor version
laravel 8.11 and file manager version is 2.2

Hi
I get htmlspecialchars() expects parameter 1 to be string, object given error in ckeditor version
laravel 8.11 and file manager version is 2.2

I have the same problem. How did you decide?


sidebar not present

i followed all instructions exactly but when i imported the repo into chrome folder the sidebar vanished. the uc toggle isn't working. when i click the sideberry button the top tabs panel is switching where as the side tabs panel is nowhere to be found. i didn't have this issue previously before my system crash

Yes, in the theme, the sidebar must be activated (press F1 to activate Sidebery) if you want the vertical bar to work - otherwise, if the sidebar is not active, it would shown the horizontal tab bar instead.
After the sidebar is activated, you can toggle the sidebar to be visible or not with the Userchrome Toggle button
Have you put the Userchrome Toggle configuration correctly?

Yes userchrome is configured as you have mentioed in the readme file but F1 is not activating sidebery.

Okay how about... Making a screen record to demo the not-working sidebar? With activating Sidebery, with clicking the UC Toggle button. Is the hovered sidebar working?

Found the sidebar which is activating in hover mode after i toggled sidebery. however you can observe that the sidebey styles editor css is not being applied
video(1).webm

sidebery styles editor css is not being applied

Yeah you have to copy-paste the code to the Style Editor in Sidebery settings page for that. I haven't find a workaround to pre-applied it thru scripts yet

i already did. Another thing the styles applied(i could tell by the pinned tabs) before i pasted the zip contents in chrome folder. Also i customized the Navigation bar and it is there but not the styles editor
so current problems
1)UC toggle not working
2)Sidebery styles are not being applied

Slightly different from original post, but close enough. Any ideas on what might be causing SideBerry to not be active on initially opening firefox?
Initial open I get the the tabs on top bar, and have to manually activate SideBerry for the sidebar to be present? After ensuring SideBerry is active; everything works as expected. Just need this to be active as default when opening firefox.

I don't know. I moved on to zen-browser.

I had the same issue, but I resolved it by adding a whitespace  after ||  prefix in the Userchrome Toggle config (as mentioned in the README, but, well, xD)


Noms

From John Payne: "The one way that CGELBank deviates quite significantly from CGEL itself , it strikes me, is in the treatment of the phrasal category Nom. Quite specifically, Rodney and I did not want CGEL Nom to be identified with the X-bar construct N-bar. Thus in CGEL, it is not the case that Complements are invariably sisters of N and Modifiers are invariably sisters of Nom. If there is just one Modifier, or a Modifier is the lowest dependent, it will be sister of N and daughter of Nom. And if a Complement is not the lowest dependent it will be a sister of Nom. This allows for relatively free ordering of Complements and Modifiers of similar weight (e.g. his exit in haste from the bar) without the necessity for gaps and postposing. It is also compatible with the idea that the distinction between Complements and Modifiers in NP structure is far from secure (no supposed Complements are obligatory; anaphoric one is not an N-bar replacement), as argued explicitly in ‘Anaphoric one and its implications’ (John Payne, Geoffrey K. Pullum, Barbara C. Scholz and Eva Berlage). Language 89.4, 2013, 794-829. Note then that your tree (40) does not reflect CGEL (see CGEL page 1061 for a corresponding CGEL tree). Going back to the N-bar concept strikes me as a retrograde step."
John was the primary author on chapter 5: Nouns and noun phrases. Geoff prefers the N-bar concept but was not an author on chapter 5.

Hmm. I can see the logic of the N-bar concept from a theoretical perspective, and if the goal is to keep the number of grammar rules to a bare minimum. From a practical descriptive perspective, it is kind of tedious to have all those extra unary levels. People might find the data easier to understand without them. Also, the current approach creates puzzles like medial Mods in #49.
One option is to revise the Lexical Projection Principle to say that every lexeme (besides Coordinators/Sdrs) projects a phrasal category, which may contain complements OR a modifier (and modifiers always adhere to binary branching). Would that be straightforward to apply or would it open up new questions?

Looking at his comment I think he's also saying that Complements should be binary-branching within the Nom, and can interleave with Mods to avoid the need for postposing. I don't have a strong feeling about that but I assume it's different from VP structure (for ditransitives or transitive particle verbs we wouldn't want to introduce additional nesting right?).

I've started rereading the Anaphoric one paper. I should have reread it some time ago. I think it will be very helpful here.

It sounds like John is arguing for treating Mods and Comps the same within Noms. A revised approach could be:

Binary Branching Principle: CGELBank branching is no more than binary except in limited circumstances:*

Coordinations with more than two coordinates
Flat structures
Internal complements in VPs (Comp, Obj, Particle, etc.) should be sister to the head V
Supplements never add an additional layer and do not count toward the branching limit

Extra layers are added (typically for Mod) where necessary in order to avoid prohibited ternary+ structures. (But a Mod may also form a binary structure with a lexical head, e.g. [AdjP [Mod:AdvP [Head:Adv very]] [Head:Adj tall]].)

Lexical Projection Principle: Outside of flat structures, and excepting Coordinators and Sdrs, a lexical node almost always projects a phrase of the corresponding category: i.e. N projects Nom (which typically projects NP), V projects VP (which typically projects Clause), P projects PP, Adv projects AdvP, etc. The one exception is that subject-auxiliary inversion targets auxiliaries specifically (rather than the VP they would project in normal position), so if the V_aux in Prenucleus position is monolexemic (not coordinated or modified), it will not project a VP there.

* This assumes that AdjP, AdvP, PP, DP, IntP are more like Noms than VPs—multiple complements (if that ever happens) would be layered.

@BrettRey what do you think of the above, with the special exception for auxiliaries?

Yes, I think this is clear, simple, and accurate. I also think multiple complements are possible: _a bet _[with Nathan] [for $50] [that multiple complements are possible]

Yes, I think this is clear, simple, and accurate.

OK, will work on updating the data

I also think multiple complements are possible: a bet [with Nathan] [for $50] [that multiple complements are possible]

Sorry I meant multiple complements in an AdjP, AdvP, PP, DP, or IntP

happy [for us] [that we've got this far]

OK—would you want those to be layered like in a Nom, or all on the same level like in a VP?

Layered.


Fix 'obsolete' tems

Some obsolete labels and definitions are not following our guidelines.

GO:0052888 'obsolete OBSOLETE:dihydroorotate oxidase (fumarate) activity' -> obsolete dihydroorotate oxidase (fumarate) activity'  (+ def was missing 'OBSOLETE')

Definition contains 'OBSOLETE:' (extra ":")

GO:0000267
obsolete cell fraction

GO:0005678
obsolete chromatin assembly complex

GO:0016585
obsolete chromatin remodeling complex

GO:0044189
obsolete host cell microsome

GO:0005626
obsolete insoluble fraction

GO:0000299
obsolete integral to membrane of membrane fraction

GO:0005624
obsolete membrane fraction

GO:0005792
obsolete microsome

GO:0019204
obsolete nucleotide phosphatase activity

GO:0000300
obsolete peripheral to membrane of membrane fraction

GO:0001950
obsolete plasma membrane enriched fraction

GO:0036044
obsolete protein malonylation

GO:0019718
obsolete rough microsome

GO:0019719
obsolete smooth microsome

GO:0005625
obsolete soluble fraction

GO:0019717
obsolete synaptosome

GO:0006410
obsolete transcription, RNA-dependent

GO:0042598
obsolete vesicular fraction

OBSOLETE  (missing period)
539 cases

Missing obsolete in definition:

obsolete   5-chloro-2-hydroxymuconic semialdehyde dehalogenase activity
obsolete ARID domain binding
obsolete cellular di-, tri-valent   inorganic cation homeostasis
obsolete chromatin silencing at   centromere central core
obsolete deoxyhypusine biosynthetic   process from spermidine
obsolete detection of stimulus involved   in cell shape checkpoint
obsolete flagellum assembly
obsolete generation of a signal involved   in cell-cell signaling
obsolete insulin biosynthetic process
obsolete lamina lucida
obsolete lipid tube assembly involved in   cytokinesis
obsolete meiosis I M phase
obsolete meiosis II M phase
obsolete movement in symbiont environment
obsolete movement on or near symbiont
obsolete N-terminal peptidyl-proline   trimethylation
obsolete negative regulation of G1/S   transition of mitotic cell cycle by positive regulation of transcription from   RNA polymerase II promoter in response to nitrogen starvation
obsolete negative regulation of   transcription from RNA polymerase II promoter involved in fatty acid   biosynthetic process
obsolete plant extracellular matrix
obsolete positive regulation of   regulation of insulin secretion involved in cellular response to glucose   stimulus
obsolete protein amino acid terminal   glycosylation
obsolete protein amino acid terminal   N-glycosylation
obsolete response to cell shape   checkpoint signaling
obsolete signal transduction involved in   cell shape checkpoint
obsolete sublamina densa
obsolete tubulin complex biogenesis

Wrong case (Obsolete)
obsolete atrioventricular node impulse   conduction delay

Consistency check
def: "OBSOLETE. = 2456 instances
is_obsolete: true = 2456 instances
name: obsolete = 2456 instances
:)


Add GSoC 2019 proposal

Add a simplified version of the proposal. We will need to:

confirm/finalise the user interface: how the users will be able to specify the parameters in inventory, do certain things as command parameters

discuss for the helm template feature

what exactly the user is able to do: i.e. is overwriting of the charts via inventory enough?
what is to be done in Go and and what is to be done in Python. This certainly depends on what the user is able to do.

We may want to discuss this on respective issue thread. Once confirmed, shall we ask for any feedback from #kapitan channel on Slack?

Besides the nitpicks the rest looks good to me! :) I can approve once fixed.

Fixes were added, merging this even though the pipeline is still broken because of  https://github.com/deepmind/kapitan/issues/295


BaseBuilder which has all the common functionalities

There's too much repeated code related to starting the activity. An abstract class that enforces certain behaviors (like getBundle()) and has common functionality (like start(context)) etc.

Eh. On second thoughts, doesn't seem like it's worth the effort.


Modularize fedimint-cli commands

A lot of wallet functionality is still implemented "globally" in fedimint-cli, but this gives default modules a weird, special privilege while not allowing working with multiple instances of the same module. Instead all functionality should be made available via the handle_cli_command API:
https://github.com/fedimint/fedimint/blob/d9c007d1ef3c9f265ed6a76800081736c7805aa5/fedimint-client/src/module/mod.rs#L250-L254
Before implementing parsing manually we should look into using clap in modules. But we need to be cautious not to panic from inside the module since the errors would be hard to interpret, instead passing a clap error up to the client will allow us to add more context.

Context: originally there was just fedimint-cli ... and each Fedimint was hardcoded to have 3 modules. Fedimint-cli was written around it.
The modularization happened and every Fedimint can set up arbitrary set of modules, even ones Fedimint developers have no idea about. Also Mints can "install" the same module twice, possibly in a different version or with different config, which might come handy sometimes.
The fedimint-cli's top-level commands work as before, by looking up the first (in order of ids) module of a given type and using if (see get_first_module). Which 99% of the time is the right thing to do.
Now fedimint-cli can't have support for the modules that are not part of Fedimint repo. For these modules there's a fedimint-cli module <kind/id> ... which is forwarded to handle_cli_command so 3rd party modules can expose and handle arbitrary CLI functionality.
But just like 3rd party modules, the standard modules should be able to handle handle_cli_command calls. So if someone having 2 LN modules in their Federation can request a n ln invoice from the second one.
The existing global fedimint-cli commands functionality should be kept, but possibly better refactored to become strictly get_first_module + method call like, maybe even with some options to change the modules being used.

The existing global fedimint-cli commands functionality should be kept, but possibly better refactored to become strictly get_first_module + method call like, maybe even with some options to change the modules being used.

I think fedimint-cli would become much more maintainable by only supporting the modularized commands. By putting all client/module commands in one sub-command we can also be more granular about which sub-commands require which arguments (e.g. --data-dir for client, but API calls can take either a data dir or a direct URL, …).
How I imagine the command structure:
fedimint-cli
├── client
│   ├── join
│   ├── info
│   ├── ...
│   ├── module (to directly address modules by name or id)
│   ├── mint (any unknown command is evaluated as module name)
│   │   ├── spend
│   │   ├── reissue
│   │   └── ...
│   ├── wallet
│   ├── lightning
│   └── ...
├── admin
│   ├── setup (CLI tool to drive initial setup/DKG)
│   ├── status
│   └── audit
└── dev
    ├── api
    │   └── <method> <args...>
    └── ... (maybe even dbtool, recoverytool?)

Thanks for the clarifications! I think I sort of have an idea now and would like to try my luck on this issue

This will be very painful if we actually remove the old default module global commands (but I still think we should) because we'd need to rewrite all the devimint tests. So it might be a good idea to first put in the fedimint-cli client <module_kind> <module_command> <args…> path and then removing the global commands one by one.

I think fedimint-cli would become much more maintainable by only supporting the modularized commands.

I would expect that the global commands (would/already) include at least some cross-module ones, that don't neatly fit into single module api.
Also it seems to me that some most commonly used apis being in a global namespace is just ... convenient. 99% of users will not have multiple instances of these modules. If the whole handler is just get_first_module<MintClientModule>.do_xyz() I don't think it's a huge burden to keep such handler.

There are legitimate cross-module ones like balance, join-federation, config, ... These would obviously stay. But e.g. spend and reissue are part of the mint module and when someone creates a mintv2 module for their mint then they couldn't even remove the old one from the client because the client still depends on the old module type.
Is it that bad to call fedimint-cli client mint spend 42000? Especially with auto completion that even makes it easier to find stuff if one knows the module but not the exact command name. I don't see many people using the CLI directly anyway and for mprocs we can add aliases if needed.

Is it that bad to call fedimint-cli client mint spend 42000

Not too bad, but worse than fedimint-cli spend 42000. And we haven't even seen a single Federation with two mint modules yet. :)

Especially with auto completion that even makes it easier to find stuff if one knows the module but not the exact command name

The auto-completion for module parts of fedimint-cli might be tricky because it crosses the two levels of multiple separate clap parsers. I'm not even sure if it's possible ATM.

And we haven't even seen a single Federation with two mint modules yet. :)

It's less about having two modules of the same kind and more about the inability to fully replace default modules and having to compile in modules that one doesn't want to use anymore.
One thing I'd want to do anyway though is putting all the client commands in their own client namespace, i.e. fedimint-cli client --data-dir=/tmp/foo spend 42000. That way it will be much easier to tell users which arguments are required where. E.g. the dev api call shouldn't require a config but should be able to accept raw websocket URLs imo.

The auto-completion for module parts of fedimint-cli might be tricky because it crosses the two levels of multiple separate clap parsers. I'm not even sure if it's possible ATM.

Good point :/

It's less about having two modules of the same kind and more about the inability to fully replace default modules and having to compile in modules that one doesn't want to use anymore.

The current "get first module of a kind by instance id" is simplistic and provisional. I think eventually long living Federations will have consensus settings to let clients know which module instances are preferable/obsolete etc, and we'll use get_preferred_module::<MintClientModule>() or something smarter. fedimint-cli send might be smart enough to prioritize draining obsolete "liquid/cash" (aka primary atm) modules and fedimint-cli in general smart enough to avoiding receiving funds to obsolete modules.
So global level commands should always be able to do more or less the right thing.

and having to compile in modules that one doesn't want to use anymore

I don't get this part, but hopefully smarter module selecting addresses that as well.

One thing I'd want to do anyway though is putting all the client commands in their own client namespace,

Usability wise seems weird because fedimint-cli is kind of all about client ...
The data-dir being sometimes needed and sometimes not is a bit of a thorn, but I don't think it's a big deal worth making everything slower to type. The current way of making it globally optional seems good enough to me.
In general I would like for fedimint-cli in addition to be useful for scripting and automation, also be a decent human-focused CLI client with convenient UX, because .. why not? If it's not someone will have to write one anyway, because people like me will want it.

Yeah, I think our differences here come from what we think fedimint-cli is/should be. I see it as a swiss army knife for all things fedimint that could potentially be useful for debugging and testing while you are more focused on the end-user client functionality.
Maybe we should actually have both? We could even do the old coreutils trick of having one binary and a bunch of symlinks to it: when it detects being called with a specific name it changes its behavior.
We could have a fmcli (no hyphen, shorter) for end users that acts like the current one without the admin commands, maybe even with a default location for wallets in some XDG directory and other amenities, while fedimint-cli is more explicit and a debug/testing tool.

We can do that, but then why would you use the "bare" one if the "rich" one can do anything that the "bare" one plus more.

We could have a fmcli (no hyphen, shorter) for end users that acts like the current one without the admin commands

I'd like to have admin commands in my end user wallet too! Admins are users too. :)

In this case fedimint-cli is what one can easily port to custom versions of FM, while in fmcli one either needs to fork it or modules are a bit of second class citizens.

I don't understand this one. In the end-user-one there's no problem exposing exactly same per-module cli handling for users that need it, and same 3rd party module injection.
Even for 3rd party modules, thanks to useful abstractions (like an existing "primary module"), even the smart commands can utilize set of common APIs for modules they don't know anything else about.
E.g. balance can calculate and add up balances reported by every module. ln-pay can use any module that can produce liquid hash. backup can backup any module.
In fact that's probably that's a good argument to maintain a "smart end-user CLI command" internally in-tree in the first place - as it forces our design to consider good generalizations that allow generalized operations.

maybe even with a default location for wallets in some XDG directory and other amenities,

If they were two separate command than I guess I'd pursue it, yes. If they're together I think the env var for --data-dir is good enough.
Ideally I'd want by default everything go to ~/.share/fedimint/ and user be able to join multiple federations, give them pet names, set a default one or use a custom via cli argument, and even have some commands that aggregate over them (e.g. show my balance in all federations).
Still, even in that most elaborated visions, I'd like this cli to support everything that the 'bare' client can do, and be usable for scripting (by e.g. just overriding data dir env variable).


AUTOSTART_INTERFACES doesn't work when restarting docker host

I have
AUTOSTART_INTERFACES = wg0
When I restart the container, wg0 comes up as expected.
When I restart the docker host, the container comes up but wg0 doesn't come up.
I don't even know how to start troubleshooting this ...
halp plz ?

closing, I can no longer reproduce...

@Zixim So this is now working as expected?

I guess so? It was 100% reproducible...it isn't anymore.


Serialize Artifacts

Artifacts have UX support but they need ModInfo and export support. Add the artifacts listing to ModInfo, and copy artifacts to the root of the mod archive.

This was completed.