Fix invalid reference

This PR is to fix invalid reference, "">SetErrors<TProperty>" in below link is invalid.
/patterns-practices/reference/errorscontainer-t-seterrors-tproperty-method-expression-func-tproperty-ienumerable-t-mspp-viewmodel">SetErrors<TProperty>

Docs Build status updates of commit ecf8701:
:warning: Validation status: warnings

File
Status
Preview URL
Details

patterns-practices/reference/errorscontainer-t-members-mspp-viewmodel.md
:warning:Warning

Details

patterns-practices/reference/tracelogger-log-method-mspp-logging.md
:warning:Warning

Details

patterns-practices/reference/dispatchereventsubscription-tpayload-invokeaction-method-mspp-pubsubevents.md
:warning:Warning

Details

patterns-practices/reference/subscriptiontoken-equals-method-subscriptiontoken-mspp-pubsubevents.md
:warning:Warning

Details

patterns-practices/reference/defaultnotificationwindow-events-mspp-interactivity-defaultpopupwindows.md
:warning:Warning

Details

patterns-practices/reference/tracelogger-constructor-mspp-logging.md
:warning:Warning

Details

patterns-practices/reference/dispatchereventsubscription-tpayload-invokeaction-method-mspp-events.md
:warning:Warning

Details

patterns-practices/reference/subscriptiontoken-equals-method-object-mspp-pubsubevents.md
:warning:Warning

Details

patterns-practices/reference/defaultnotificationwindow-constructor-mspp-interactivity-defaultpopupwindows.md
:warning:Warning

Details

patterns-practices/reference/tracelogger-class-mspp-logging.md
:warning:Warning

Details

patterns-practices/reference/delegatecommandbase-oncanexecutechanged-method-mspp-commands.md
:warning:Warning

Details

patterns-practices/reference/subscriptiontoken-equals-method-mspp-pubsubevents.md
:warning:Warning

Details

patterns-practices/reference/defaultnotificationwindow-class-mspp-interactivity-defaultpopupwindows.md
:warning:Warning

Details

patterns-practices/reference/threadoption-enumeration-mspp-pubsubevents.md
:warning:Warning

Details

patterns-practices/reference/delegatecommandbase-methods-mspp-commands.md
:warning:Warning

Details

patterns-practices/reference/subscriptiontoken-dispose-method-mspp-pubsubevents.md
:warning:Warning

Details

patterns-practices/reference/defaultdispatcher-methods-mspp-events.md
:warning:Warning

Details

patterns-practices/reference/textlogger-methods-mspp-logging.md
:warning:Warning

Details

patterns-practices/reference/delegatecommandbase-members-mspp-commands.md
:warning:Warning

Details

patterns-practices/reference/subscriptiontoken-constructor-mspp-pubsubevents.md
:warning:Warning

Details

patterns-practices/reference/dataeventargs-tdata-class-mspp-pubsubevents.md
:warning:Warning

Details

patterns-practices/reference/textlogger-members-mspp-logging.md
:warning:Warning

Details

patterns-practices/reference/delegatecommandbase-isactivechanged-event-mspp-commands.md
:warning:Warning

Details

patterns-practices/reference/subscriptiontoken-class-mspp-pubsubevents.md
:warning:Warning

Details

patterns-practices/reference/cyclicdependencyfoundexception-properties-mspp-modularity.md
:warning:Warning

Details

patterns-practices/reference/textlogger-log-method-mspp-logging.md
:warning:Warning

Details

patterns-practices/reference/delegatecommandbase-isactive-property-mspp-commands.md
:warning:Warning

Details

patterns-practices/reference/singleactiveregion-properties-mspp-regions.md
:warning:Warning

Details

patterns-practices/reference/cyclicdependencyfoundexception-methods-mspp-modularity.md
:warning:Warning

Details

patterns-practices/reference/textlogger-dispose.md
:warning:Warning

Details

patterns-practices/reference/delegatecommandbase-fields-mspp-commands.md
:warning:Warning

Details

patterns-practices/reference/singleactiveregion-methods-mspp-regions.md
:warning:Warning

Details

patterns-practices/reference/cyclicdependencyfoundexception-members-mspp-modularity.md
:warning:Warning

Details

patterns-practices/reference/textlogger-dispose-method-mspp-logging.md
:warning:Warning

Details

patterns-practices/reference/delegatecommandbase-execute-method-mspp-commands.md
:warning:Warning

Details

patterns-practices/reference/singleactiveregion-members-mspp-regions.md
:warning:Warning

Details

patterns-practices/reference/cyclicdependencyfoundexception-events-mspp-modularity.md
:warning:Warning

Details

patterns-practices/reference/textlogger-dispose-method-boolean-mspp-logging.md
:warning:Warning

Details

patterns-practices/reference/delegatecommandbase-events-mspp-commands.md
:warning:Warning

Details

patterns-practices/reference/singleactiveregion-events-mspp-regions.md
:warning:Warning

Details

patterns-practices/reference/cyclicdependencyfoundexception-ctor.md
:warning:Warning

Details

patterns-practices/reference/textlogger-ctor.md
:warning:Warning

Details

patterns-practices/reference/delegatecommand-members-mspp-commands.md
:warning:Warning

Details

patterns-practices/reference/singleactiveregion-constructor-mspp-regions.md
:warning:Warning

Details

patterns-practices/reference/cyclicdependencyfoundexception-constructor-string-string-exception-mspp-modularity.md
:warning:Warning

Details

patterns-practices/reference/textlogger-constructor-textwriter-mspp-logging.md
:warning:Warning

Details

patterns-practices/reference/delegatecommand-fromasynchandler-method-mspp-commands.md
:warning:Warning

Details

patterns-practices/reference/singleactiveregion-class-mspp-regions.md
:warning:Warning

Details

patterns-practices/reference/cyclicdependencyfoundexception-constructor-string-mspp-modularity.md
:warning:Warning

Details

patterns-practices/reference/textlogger-constructor-mspp-logging.md
:warning:Warning

Details

This comment lists only the first 50 files in the pull request.

patterns-practices/reference/errorscontainer-t-members-mspp-viewmodel.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/tracelogger-log-method-mspp-logging.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/dispatchereventsubscription-tpayload-invokeaction-method-mspp-pubsubevents.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.
Line 46: [Suggestion] Multiple H1s are not allowed. You can only have one top-level heading. NOTE: This Suggestion will become a Warning on 11/25/2019.

patterns-practices/reference/subscriptiontoken-equals-method-subscriptiontoken-mspp-pubsubevents.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/defaultnotificationwindow-events-mspp-interactivity-defaultpopupwindows.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/tracelogger-constructor-mspp-logging.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/dispatchereventsubscription-tpayload-invokeaction-method-mspp-events.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.
Line 41: [Suggestion] Multiple H1s are not allowed. You can only have one top-level heading. NOTE: This Suggestion will become a Warning on 11/25/2019.

patterns-practices/reference/subscriptiontoken-equals-method-object-mspp-pubsubevents.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/defaultnotificationwindow-constructor-mspp-interactivity-defaultpopupwindows.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/tracelogger-class-mspp-logging.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/delegatecommandbase-oncanexecutechanged-method-mspp-commands.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/subscriptiontoken-equals-method-mspp-pubsubevents.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/defaultnotificationwindow-class-mspp-interactivity-defaultpopupwindows.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/threadoption-enumeration-mspp-pubsubevents.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.
Line 37: [Suggestion] Multiple H1s are not allowed. You can only have one top-level heading. NOTE: This Suggestion will become a Warning on 11/25/2019.

patterns-practices/reference/delegatecommandbase-methods-mspp-commands.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/subscriptiontoken-dispose-method-mspp-pubsubevents.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/defaultdispatcher-methods-mspp-events.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/textlogger-methods-mspp-logging.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/delegatecommandbase-members-mspp-commands.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/subscriptiontoken-constructor-mspp-pubsubevents.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/dataeventargs-tdata-class-mspp-pubsubevents.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.
Line 40: [Suggestion] Multiple H1s are not allowed. You can only have one top-level heading. NOTE: This Suggestion will become a Warning on 11/25/2019.

patterns-practices/reference/textlogger-members-mspp-logging.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/delegatecommandbase-isactivechanged-event-mspp-commands.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/subscriptiontoken-class-mspp-pubsubevents.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/cyclicdependencyfoundexception-properties-mspp-modularity.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/textlogger-log-method-mspp-logging.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/delegatecommandbase-isactive-property-mspp-commands.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/singleactiveregion-properties-mspp-regions.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/cyclicdependencyfoundexception-methods-mspp-modularity.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/textlogger-dispose.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/delegatecommandbase-fields-mspp-commands.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/singleactiveregion-methods-mspp-regions.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/cyclicdependencyfoundexception-members-mspp-modularity.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/textlogger-dispose-method-mspp-logging.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/delegatecommandbase-execute-method-mspp-commands.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.
Line 33: [Suggestion] Multiple H1s are not allowed. You can only have one top-level heading. NOTE: This Suggestion will become a Warning on 11/25/2019.

patterns-practices/reference/singleactiveregion-members-mspp-regions.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/cyclicdependencyfoundexception-events-mspp-modularity.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/textlogger-dispose-method-boolean-mspp-logging.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/delegatecommandbase-events-mspp-commands.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/singleactiveregion-events-mspp-regions.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/cyclicdependencyfoundexception-ctor.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/textlogger-ctor.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/delegatecommand-members-mspp-commands.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/singleactiveregion-constructor-mspp-regions.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/cyclicdependencyfoundexception-constructor-string-string-exception-mspp-modularity.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/textlogger-constructor-textwriter-mspp-logging.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/delegatecommand-fromasynchandler-method-mspp-commands.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/singleactiveregion-class-mspp-regions.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/cyclicdependencyfoundexception-constructor-string-mspp-modularity.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

patterns-practices/reference/textlogger-constructor-mspp-logging.md

[Warning] Missing attribute: author. Add the current author's GitHub ID.
[Warning] Missing attribute: title. Add a title string to show in search engine results.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Importing machines in from Chef. Import-Master as template

Just as a general comment--I wasn't necessarily expecting that we forklift the import infrastructure over from seiso-import_master to seiso-import_chef.  seiso-import_master has a more complex problem, involving importing multiple resource types, and also resources with children that have to be auto-created. So that's why seiso-import_master has callbacks and child importing and such.
In contrast, seiso-import_chef deals only in machines, and they don't have child resources. So the implementation ought not to include child-stuff and not callbacks either, unless there's some reason for it.


config: load accounts from file

Example on how to load accounts from a file

We don't have a full test with file - but the most important step is tested (parsing accounts with different formats) - so the only test which might be missing is just loading the file content. Not sure how important it is (it's just reading a file) - it's a one function call from standard library (fs).


update for the new package driverloader

Signed-off-by: Lai Jiangshan<EMAIL_ADDRESS>

LGTM


Rename webSpeechPonyfillFactory

Is it possible to rename this function? Or perhaps better understand why it is a Ponyfill factory?
Did someone mean to write Polyfill?

Ponyfill is not a typo. Please see this closed PR: https://github.com/microsoft/BotFramework-WebChat/pull/1663

Ponyfill factory is "a function that will create a ponyfill". It is using factory pattern (a function to create something), thus, it is called ponyfill factory.
And ponyfill is better than polyfill, as @sindreshorhus has been pointed out in his article, https://github.com/sindresorhus/ponyfill, ponyfill are pure and is not monkey-patching.
The way ponyfill work, is not overriding what your current environment has, which means, it is pollution-less and preferred in modern JavaScript environment, where tons of packages could load and conflicting with each others.
In the jQuery days, they have ponyfill too. They call it $.noConflict. Using noConflict will not pollute the environment (other than the namespace it own).
You can turn a ponyfill into a polyfill by simply applying the ponyfill over your current environment. For example, in a browser,
const myPonyfill = someoneGiveThisToMe();

Object.keys(myPonyfill).forEach(name => window[name] = myPonyfill[name]);

For Web Speech API, surprisingly, they are not polyfill-able. This is not the primary reason why we use ponyfill. But, you can try out this code in your browser:
window.speechSynthesis = 123;

console.log(window.speechSynthesis === 123); // return false, in Chrome 76

For the factory part of the name, this is primarily because we want to conform to W3C Web Speech API as much as possible.
We need to pass options to the Web Speech API, but we don't want to modify the established standard by adding fields/members unknown to other implementations. Thus, we are using a factory function approach to pass options to the Web Speech API. These options are very local to Web Chat, e.g. reference grammar ID (used for LUIS).
This pattern allow us to use Web Speech engines other than Cognitive Services, because we didn't change the W3C API at all. No behavior change and no adds.
So, the name ponyfillFactory is correct. And every part of its name has its purpose. And the name is not as meaningless as "adapter", and "manager".

Thank you very much for this thorough response! I take a break from web dev for a bit and there are new terms I've never learned about.


Bug: CHROME_VERSION is hardcoded

The problem with hardcoding CHROME_VERSION to 116 is that if you don't have Chrome 116 installed (which is old) then it aborts entirely.
$ ./sdl-0.1.0-linux-x64 --type dub --lang english https://aniwave.to/watch/psycho-pass.mpp/ep-1
12:26:45.547 ERROR > Failed to create ChromeDriver: could not connect to ChromeDriver: error creating new session: webdriver did not create session: session not created: This version of ChromeDriver only supports Chrome version 121
Current browser version is 116.0.5845.96 with binary path /home/gravis/.cache/selenium/chrome/linux64/116.0.5845.96/chrome: webdriver did not create session: session not created: This version of ChromeDriver only supports Chrome version 121
Current browser version is 116.0.5845.96 with binary path /home/gravis/.cache/selenium/chrome/linux64/116.0.5845.96/chrome

This should be fixed in the git version, for which I haven't made a release yet. If you build sdl yourself, it should work.

Could you make a new release? I am unable to build it.

Ok. https://github.com/Funami580/sdl/releases/tag/v0.1.1


Add new games support

Is it possible to add support for farlight 84 & arena breakout?

Is it possible to add support for farlight 84 & arena breakout?

I added farlight 84 for now.

Thanks!


release: kube generate image tags like all other container images

Issue #, if available:
Description of changes:
In https://github.com/aws/eks-distro/pull/753 I am looking to change the KUBE_GET_VERSION in the version file the release tooling uses to generate the final release yaml.  Image tags and binary versions will not match on the kubernetes components.  This change uses the same process to generate the image tags as all the other components in the release tooling.
At this point the only thing the release tooling will be pulling from the version file is the git commit hash.
/hold
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/unhold


Machine mac-34 went dead from network connection monitoring website.

Machine mac-34 went dead from network connection monitoring website.

Machine mac-34 was not dead, I can login remotely from my end,  will check more details on machine.
flutter@flutter-devicelab-mac-34 ~ % uptime
9:19  up  8:11, 2 users, load averages: 0.95 1.04 1.00

Machine mac-34 is back online and running fine, mac-34 is missing git package to run other apps.


Where is sass-planifolia included?

According to ATTRIBUTION.md,

Math functions from sass-planifolia (GNU License)

Clarity includes sass-planifolia. But I cant't find that source code. Where is sass-planifolia included? Also the current licence of sass-plantfolia is MIT not GNU. https://github.com/xi/sass-planifolia/blob/master/LICENSE

@ysds
We are using an early version of one of Tobias' math functions here...
https://github.com/vmware/clarity/blob/master/src/clarity-angular/utils/vendor/mathPow.clarity.scss


Maximum number of parameters in call_group

Godot version:
3.2.1 stable official
OS/device including version:
MacOS Catalina 10.15.5 (19F101)
Issue description:
When calling a group with get_tree().call_group("...") with 5 parameters, it works fine. With 6 parameters it does not throw an error and also the function is not executed.
Steps to reproduce:

run attached project OR follow steps:
Create two nodes: Level and Unit and attach a script to each of them
Create a function in Level script and create a function with 6 parameters
Call function with call_group("Level", "myFunction", 1,2,3,4,5,6)

Minimal reproduction project:
testCallGroupParams.zip

Just tried to figure out why that is and found out that the call_group method uses VARIANT_ARG_LIST defined in objects.h, which indeed supports exactly five arguments, so you cannot pass a dynamic number of arguments.


CBL-2548 : Retain database in ListenerToken of CBLDocumentChangeListener

Retain database in the ListenerToken to allow to remove / release the token after closing and releasing the database (using CBLDatabase_Release). On the binding platform that uses GC, the order of releasing the object is not guaranteed so the database might be released before the token.

Closed as wrong branch.


Transfer image composition from PIL to Canvas

From #45  we are using Canvas to display an image. Let's use the power of it!

Note: this will break save image

Note: this will break save image


Split bundles when using require with context

Bug Report or Feature Request (mark with an x)
- [ ] bug report -> please search issues before submitting
- [x] feature request

Versions.
@angular/cli: 1.0.1
node: 7.8.0
os: win32 x64
@angular/animations: 4.1.0
@angular/common: 4.1.0
@angular/compiler: 4.1.0
@angular/core: 4.1.0
@angular/forms: 4.1.0
@angular/http: 4.1.0
@angular/platform-browser: 4.1.0
@angular/platform-browser-dynamic: 4.1.0
@angular/router: 4.1.0
@angular/cli: 1.0.1
@angular/compiler-cli: 4.1.0
Repro steps.
Put a number of locale files (js files named as different locales) in a folder names locales and in app.component constructor do:
let myLocaleInfo = require("./locales/"+navigator.language +".js");
ng build
You will get all locale files bundled with the main bundle (in our case we have the complete cldr-data in the locales folder, as we need to support all available locales, that means 236MB! in the main bundle, when we in practice only need to add one 600kB file (which one, we know first at runtime))
Desired functionality.
We would like each locale to become its own bundle, so that we do not get a gigant main bundle, but only load the locale actually used at runtime! This is from what I have read possible in webpack with the following syntax:
let myLocaleInfo = require("bundle-loader?lazy!./locales/"+navigator.language +".js");
However bundle-loader does not seem to exist in angular-cli
Mention any other details that might be useful.
What we are actually doing is loading locales for Globalize.js and kendo.ui, the application we are building supports 25 languages but basically all locales available in the world.

For information on code splitting, please refer to this guide: https://webpack.js.org/guides/code-splitting-async/
Please note that while this works, it is not considered a fully supported feature of the CLI.

Closing as above.

Would just like to add that we do test for this, when using System.import only: https://github.com/angular/angular-cli/blob/master/tests/e2e/tests/misc/lazy-module.ts#L30-L33

Thanks, I will try this out when I have time, although from what I can see when reading this documentation, it actually does not do what I need.
In my case it will put all the locales into the same lazy loaded bundle instead of the main bundle, this will not solve my problem where I need each locale file to be its own bundle. So I will still end up with a 250mb locales bundle instead of like 400 600k bundles which is what I need.

And for anyone reading this later on, this actually works as I need it to, I get one chunk per file!


Fix characteristic group filter on import tab

The Characteristic Group filter on the data import tab should allow for multiple selections (see WQP example below). It currently only allows the user to select one.

This is done on my computer.
Added multiple = TRUE where widget UI is created, then changed test where input is prepared for submission
Changed test from length(input$chargroup) == 0 to this is.null(input$chargroup)

Testing
Date range 2018-05-01 to 2018-05-31
Set Characteristic Group 'Biological'
Your dataset contains 444 unique results from 89 monitoring location(s) and 7 unique organization(s).
Set Characteristic Group 'Biological' and 'Physical'
... runs forever, but does not crash
... eventually I closed the browser rather than wait for a huge dataset to be loaded.
Date range 2018-05-01 to 2018-05-02
Set Characteristic Group 'Biological', 'Sediment'
Your dataset contains 125 unique results from 59 monitoring location(s) and 14 unique organization(s).
Date range 2018-05-01 to 2018-05-02
Set Characteristic Group 'Biological'
Your dataset contains 4 unique results from 4 monitoring location(s) and 1 unique organization(s).
Date range 2018-05-01 to 2018-05-02
Set Characteristic Group 'Sediment'
Your dataset contains 121 unique results from 55 monitoring location(s) and 14 unique organization(s).
Date range 2018-05-01 to 2018-05-02
Set Characteristic Group  (leave blank)
... runs a long time, but does not crash when no Characteristic Group filter is applied.
Your dataset contains 115,971 unique results from 4,170 monitoring location(s) and 203 unique organization(s).


[ENH] AutoETS implementation

Describe the feature or idea you want to propose
Our new experimental forecasting module starts with a really fast ETS implementation. The next stage is AutoETS. But how to search the parameter space? There are many alternatives, grid search, nelder mead, stochastic gradient descent etc. It would be really good to implement this in a configurable way. Feel free to come up with alternative heuristic search algorithms on this thread
Describe your proposed solution
we need to think about how to design this efficiently, perhaps taking inspiration from scikit-learn?
Describe alternatives you've considered, if relevant
No response
Additional context
No response

@aeon-actions-bot assign @alexbanwell1

Bayesian optimization using https://optuna.readthedocs.io/en/stable/?


Coordinating with other UTxORPC stakeholders on implementation

This has been implemented in the utxorpc/spec repository, which generates code for multiple languages.

Contributors: https://github.com/utxorpc/spec/graphs/contributors


Chore/add prettier

chore(prettier): Add prettier configuration file.
style(project): Apply .prettierrc configuration to al .js files.

Closed due to conflicts between prettier configuration and Eslint standard.


deleteManyX mutations error when deleting a large number of records

Describe the bug
When running a "deleteManyX" mutation against a table with a large number of records, an error is returned with a message of

Whoops. Looks like an internal server error. Search your server logs for request ID: local:api:cjkcx8x7rvcxy0871suxurkfr

Looking at the prisma logs, I found the following:
[Bugsnag - local / testing] Error report: com.bugsnag.Report@54935f02
org.postgresql.util.PSQLException: An I/O error occurred while sending to the backend.
 	at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:333)
 	at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:441)
 	at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:365)
 	at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:155)
 	at org.postgresql.jdbc.PgPreparedStatement.execute(PgPreparedStatement.java:144)
 	at com.zaxxer.hikari.pool.ProxyPreparedStatement.execute(ProxyPreparedStatement.java:44)
 	at com.zaxxer.hikari.pool.HikariProxyPreparedStatement.execute(HikariProxyPreparedStatement.java)
 	at com.prisma.api.connector.jdbc.database.BuilderBase.$anonfun$deleteToDBIO$1(BuilderBase.scala:70)
 	at com.prisma.api.connector.jdbc.database.BuilderBase.$anonfun$deleteToDBIO$1$adapted(BuilderBase.scala:70)
 	at com.prisma.api.connector.jdbc.database.BuilderBase.$anonfun$jooqToDBIO$1(BuilderBase.scala:87)
 	at slick.jdbc.SimpleJdbcAction.run(StreamingInvokerAction.scala:70)
 	at slick.jdbc.SimpleJdbcAction.run(StreamingInvokerAction.scala:69)
 	at slick.dbio.DBIOAction$$anon$4.$anonfun$run$3(DBIOAction.scala:239)
 	at scala.collection.Iterator.foreach(Iterator.scala:929)
 	at scala.collection.Iterator.foreach$(Iterator.scala:929)
 	at scala.collection.AbstractIterator.foreach(Iterator.scala:1417)
 	at scala.collection.IterableLike.foreach(IterableLike.scala:71)
 	at scala.collection.IterableLike.foreach$(IterableLike.scala:70)
 	at scala.collection.AbstractIterable.foreach(Iterable.scala:54)
 	at slick.dbio.DBIOAction$$anon$4.run(DBIOAction.scala:239)
 	at slick.dbio.DBIOAction$$anon$4.run(DBIOAction.scala:237)
 	at slick.basic.BasicBackend$DatabaseDef$$anon$2.liftedTree1$1(BasicBackend.scala:275)
 	at slick.basic.BasicBackend$DatabaseDef$$anon$2.run(BasicBackend.scala:275)
 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
 	at java.lang.Thread.run(Thread.java:748)
 Caused by: java.io.IOException: Tried to send an out-of-range integer as a 2-byte value: 44446
 	at org.postgresql.core.PGStream.sendInteger2(PGStream.java:224)
 	at org.postgresql.core.v3.QueryExecutorImpl.sendParse(QueryExecutorImpl.java:1440)
 	at org.postgresql.core.v3.QueryExecutorImpl.sendOneQuery(QueryExecutorImpl.java:1762)
 	at org.postgresql.core.v3.QueryExecutorImpl.sendQuery(QueryExecutorImpl.java:1326)
 	at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:298)
 	... 25 more

To Reproduce

Initialize & deploy a new prisma project
Create at least 32768 users
Issue a query of the form:
mutation { deleteManyUsers { count } }
This will produce this error and not delete the records.

Expected behavior
I expect this to not produce errors and delete all the records.
Versions (please complete the following information):

OS: OS X High Sierra
prisma CLI: prisma/1.13.4 (darwin-x64) node-v10.8.0
Prisma Server: 1.13.4

I can confirm this bug using the Postgres connector.
Additional reproduction setup:
type User {
  id: ID! @unique
  name: String!
}

prisma import -d nodes.zip
nodes.zip

This might be related to the maximum number of parameters the respective DBs accept in a query.

To be clear, this worked on the previous version that my team was using (1.11.1). If there is anything I can do to help track this down further, please let me know.

Thanks for the offer, but I'm pretty sure it's related to this. https://github.com/jOOQ/jOOQ/issues/5701 We started using jOOQ in 1.12. I just need to find out how to fix it since from the issue it sounds like it should already be handled by jOOQ.

Gotcha, thanks for the information! The support from everyone on the prisma team on bug reports like this has really impressed me.

We just released a fix for this in 1.13.6

@do4gr Thanks for your quick action on this.


Mixing C# and and F# reverts back to C#

Describe the bug
Please provide as much information as you can.
In the lower right cell corner, the selection to change between C#/F# does not seem to stay after execution of cell. Going back to cell reverts back to C#.  I can force it with the magic command. But it still shows as C# in the lower right.
Please complete the following:
Which version of .NET Interactive are you using? There are a few ways to find this out:

In a notebook, run the #!about magic command.
At the command line, run dotnet interactive --version.
1.0.217604

OS

[X] Windows 10
[ ] macOS
[ ] Linux (Please specify distro)
[ ] iOS
[ ] Android

Browser

[ ] Chrome
[ ] Edge
[ ] Firefox
[ ] Safari

Frontend

[ ] Jupyter Notebook
[ ] Jupyter Lab
[ ] nteract
[ ] Visual Studio Code
[X ] Visual Studio Code Insiders
[ ] Other (please specify)

Screenshots
If applicable, add screenshots to help explain your problem.

I can preproduce this too.

.NET Interactive: 1.0.217604+a3dea7ced5d5f206116fcaec5d3f2ff5c2542e77
VSCode Insider: 1.55.0-insider (Commit 26a60d)
Jupyter Extension: v2021.5.697286501

I'm closing this as a duplicate of #1175.


Regressions caused by lexical scope refactor

A number of regressions have occurred due to 93f5f225772c398be6e409da3d3ef0f07ffbe1cf.
Test cases from the following issues now produce crashes again:

#3507
#3512
#3518
#3521
#3715

I am awfully sorry, I mistakenly pushed half-baked changes. I will fix them soon.


No check for length of nested columns data arrays

In version 1.1.54343 Clickhouse checks lengths of nested column data arrays, but in 1.1.54362 this check disappeared. I didn't check older versions for fixes, but i think there is the same broken behaviour.
create table learners (
	fakePartition Date,
	learnerId UInt64,
	courseId UInt64,
	actorId UInt64,
	progress Float32,
	result Float32,
	passedDate DateTime,
	passed UInt8,
	startedDate DateTime,
	lastActivity DateTime,
	rate Float64,
	rating Float64,
	ratingTemporary UInt8,
	commentsCount UInt16,
	lastCommentDate DateTime,
	activity Nested(
		day Date,
		durationSessionsTotal UInt64,
		durationSessionsLearning UInt64,
		durationSessionsRepeating UInt64,
		durationEntitiesTotal UInt64,
		durationEntitiesLearning UInt64,
		durationEntitiesRepeating UInt64,
		durationEntitiesBeforePassed UInt64,
		durationEntitiesAfterPassed UInt64
	),
	progressHistory Nested(
		progress Float64,
		progressedAt DateTime,
		passed UInt8
	),
	resultHistory Nested(
        result Float64,
        scoredAt DateTime,
        passed UInt8
    ),
	sessions Nested(
		startedAt DateTime,
		endedAt DateTime,
		learning UInt8,
		repeating UInt8,
		durationTotal UInt32,
		durationLearning UInt32,
		durationRepeating UInt32
	),
	entitiesResults Nested(
		entityIri String,
		result Float64,
		progress Float64,
		startedDate DateTime,
		passedDate DateTime
	),
	entitiesAttempts Nested(
		entityIri String,
		startedAt DateTime,
		attemptNumber UInt16,
	    attemptLearningNumber UInt16,
	    attemptRepeatingNumber UInt16,
	    attemptBeforePassedNumber UInt16,
	    attemptAfterPassedNumber UInt16,
		endedAt DateTime,
		passed UInt8,
		success UInt8,
		learning UInt8,
		repeating UInt8,
		beforePassed UInt8,
		afterPassed UInt8,
		result Float32,
		durationTotal UInt32,
		durationLearning UInt32,
		durationRepeating UInt32,
		durationBeforePassed UInt32,
		durationAfterPassed UInt32,
		reject UInt8
	),
	entitiesAnswerAttempts Nested(
        entityIri String,
        answeredAt DateTime,
        questionId UInt64,
        correct UInt8,
        duration UInt32,
        attemptNumber UInt16,
        attemptLearningNumber UInt16,
        attemptRepeatingNumber UInt16,
        attemptBeforePassedNumber UInt16,
        attemptAfterPassedNumber UInt16
	),
	entitiesAnswers Nested(
        answeredAt DateTime,
        questionId UInt64,
        answerId UInt64,
        correct UInt8,
        attemptNumber UInt16,
        attemptLearningNumber UInt16,
        attemptRepeatingNumber UInt16,
        attemptBeforePassedNumber UInt16,
        attemptAfterPassedNumber UInt16
	),
	entitiesProgressHistory Nested(
	    entityIri String,
	    progress Float64,
	    progressedAt DateTime
	),
	entitiesResultHistory Nested(
        entityIri String,
        result Float64,
        scoredAt DateTime
    ),
  commentsHistory Nested(
        commentedAt DateTime
  ),
  entitiesCommentsHistory Nested(
        entityIri String,
        commentedAt DateTime
  ),
  rateHistory Nested(
        ratedAt DateTime,
        rate Float64
  ),
  entitiesRateHistory Nested(
        entityIri String,
        ratedAt DateTime,
        rate Float64
  ),
  ratingHistory Nested(
        ratedAt DateTime,
        rating Float64
  ),
	version DateTime
) engine = ReplacingMergeTree(fakePartition, (courseId, learnerId), 8192, version)

Then run select * from learners and you will recieve Cannot read all array values: read just 235 of 236: (while reading column entitiesAttempts.durationAfterPassed): (while reading from part ...(partition path))

There is data sample in CSV format: https://yadi.sk/d/FvSTeuE53UVHTw

I just wanted to note that we ran into this issue too. It's not hard to handle on the writer-side but maybe if it's not going to be checked in ClickHouse this documentation should be changed:
https://clickhouse.yandex/docs/en/data_types/nested_data_structures/nested/

During insertion, the system checks that they have the same length.

This bug is acknowledged. We should add missing checks.

Can reproduce on 18.6.0. Any news on this?

Fixed in #3118

Released in version 18.12.


Improve clang-tidy script output to not be noisy

Problem
Clang-tidy warns of all system header warnings, drowning real failures in massive output amount.
Change overview
Filter out 'expected' noisy output, to keep only relevant info (failures)
Testing
Manually ran locally. CI should show nicer output as well.

/rebase


Fixes warnings for capturing the given block using Kernel#proc

Fixes #157 and #155. Tested and confirmed.

Fixes #157 and #155. Tested and confirmed.

Thank you!


Fix ORT atstccfg to allow using new features in the latest Traffic Ops

What does this Pull Request (PR) do?
Adds a client of the latest Traffic Ops version, and refactors the
existing vendored client, so both can be used at once.
Includes an idiom of using the latest and falling back to vendored.
Also includes an example of the latest client getting Delivery
Services, and falling back to the vendored if the TO isn't the latest.
This isn't actually necessary right now, but it's likely to be very
shortly, and it serves as an example of the idiom for future dev.
Includes unit tests. ORT doesn't have an integration test framework yet, so the larger part of this that requires TO can't be tested yet, unfortunately.
No docs, no changelog, no interface change.

[x] This PR is not related to any other Issue

Which Traffic Control components are affected by this PR?

Traffic Ops ORT

What is the best way to verify this PR?
Run ORT/atstccfg against a TO of the previous release version with warning logs enabled, verify the message "Traffic Ops newer than ORT, falling back to previous API Delivery Services". Run against a TO of the latest version, verify no message.
There aren't any new features that ORT uses yet, so that can't be verified yet. But there probably will be shortly.
If this is a bug fix, what versions of Traffic Control are affected?
Not a bug fix.
The following criteria are ALL met by this PR

[x] This PR includes tests OR I have explained why tests are unnecessary
[x] This PR includes documentation OR I have explained why documentation is unnecessary
[x] This PR includes an update to CHANGELOG.md OR such an update is not necessary
[x] This PR includes any and all required license headers
[x] This PR ensures that database migration sequence is correct OR this PR does not include a database migration
[x] This PR DOES NOT FIX A SERIOUS SECURITY VULNERABILITY (see the Apache Software Foundation's security guidelines for details)

Additional Information

I'm confused as to why atstccfg needs to vendor an old client -- why can't we always stay up to date with master? If we upgrade TO first like we usually do, won't the latest atstccfg always be able to use the latest Go client version?

If we upgrade TO first like we usually do

TC has always supported running any component with any other component one version back, ORT breaking that was a regression, and IMO we should continue to support that.
TC components should be loosely-coupled. There are innumerable disadvantages to tightly-coupled components.
In fact, at our organization, we didn't used to have a strict order, and IMO we should never have adopted that deployment procedure. Requiring a strict upgrade order makes TC brittle and dangerous. It's much safer, robust, and resilient to require all components to support one version back of all the other components they talk to, so they can be upgraded or rolled back in any order.
Sometimes there are operational reasons one component needs updated first, and mandating an order makes that impossible.
In the event a component unexpectedly needs to be rolled back, supporting one version back also allows that to be done quickly and safely. Without it, it would mean every component after it the "deployment order" has to be rolled back in sequence. Making an already tricky situation much more dangerous.
It also tightly couples our development, and makes it more difficult to develop each individual component. It means one person or team can't develop on one product, and implement a feature one component at a time with a clean interface. They have to be aware of all the ramifications of all the other components and their deployment order.

Ok, I agree that tight coupling is bad, but this seems like something that should be well-communicated with the entire project for everyone to get on board with if our goal is to follow this pattern for every component. This seems more like a backwards-compatibility issue than a coupling issue. API clients will always be coupled to the API, and if a client is coupled to two versions of the same API, doesn't that make it even more tightly coupled to that API? It seems like the trade-off being made is really getting better backwards compatibility with TO at the cost of tighter coupling and increased complexity of components.
Maybe we're ok with that, but maybe we're ok with always upgrading TO first? The order doesn't necessarily need to be TO -> TM -> TR -> ORT for example, it could just be "TO first". If we need to fully roll back TO after we've already upgraded most of the other components in the chain, wouldn't we be risking more serious data loss if we rolled back TO at that point rather than hotfixing it and rolling forwards?

This seems more like a backwards-compatibility issue than a coupling issue.

I think it's both.

if a client is coupled to two versions of the same API, doesn't that make it even more tightly coupled to that API?

I guess everyone's definition is different, but that's not what I mean when I say "tightly-coupled." One of the benefits of an API is that you're "coupled" to the interface rather than the app itself. It seems inevitable that you have to communicate with some interface.

better backwards compatibility with TO at the cost of tighter coupling and increased complexity of components.

The point of TC components supporting a version back isn't backward compatibility per-se, but rather the ability to deploy and roll back in any order, which gives us safety around deployment. It allows deployments of production components to be isolated around a single component of the system, rather than the full system all-or-nothing.
Getting 100,000 lines of code to work as a single, perfect, cohesive unit is way more difficult and error-prone, than getting ten 10,000-line apps to each independently work.

If we need to fully roll back TO after we've already upgraded most of the other components in the chain, wouldn't we be risking more serious data loss if we rolled back TO at that point rather than hotfixing it and rolling forwards?

It depends on the situation. It's possible. It's also possible that a hotfix will be more dangerous, or take longer, or disrupt other systems, where a quick rollback of say ORT, or TM, would be faster and safer, and fix a broken production system in minutes instead of hours or days.
Or suppose it's a bug in TR, which requests TM, which requests TO. What if there's a bug in TM? Now you have to roll back TR, then TM, then TO. And maybe it's possible to hotpach TM. But maybe it's not, maybe it's a large, complex feature or code refactor and the only quick solution is to roll back. Now TR, TM, and TO all have to be rolled back, in order, and re-deployed, in order.
Where if TM and TR support the prior version, TM can safely and quickly be rolled back.
That's why our components need to be decoupled. Not from the TO API, but from each-other, and from specific binaries. You're right, there are scenarios where it doesn't matter. But there are also a great many failure scenarios where it does, and it means the difference in minutes versus hours of outage time.
Letting TC users upgrade in any order can also be safer. In theory, TC shouldn't have bugs. But in the past, it often has, and upgrading certain components first can be safer and less likely to bring the CDN down.

this seems like something that should be well-communicated with the entire project for everyone to get on board with

We did, but I guess that was before you came on to the project. We didn't used to do extensive documentation for these things, we just kind of agreed and then did it.

@ezelkow1 fyi I added a script to automate upgrading the vendored client and changing the TOClientNew usages to regular TOClient on a new release. I don't know if you feel the need to re-review.
It doesn't touch the existing code, and it's never run on config gen. It's just a helper script, if we find it useful.

We did, but I guess that was before you came on to the project. We didn't used to do extensive documentation for these things, we just kind of agreed and then did it.

Links to the mailing list discussions where decisions have supposedly been made are greatly appreciated if they're going to be used as an excuse for not wanting to open up the discussion to a wider audience. Even if the decision was made 3 years ago, that's a really long time, and a lot of developers who were here 3 years ago are no longer active on the project. We've got a lot of new developers who have no prior knowledge of these discussions, and changing the "TO client paradigm" today (after discussing it 3+ years ago) would be something that would be a great discussion to have now, not only as a refresher for devs who were on the project 3+ years ago but also for teaching newer devs. Since decisions like these have ramifications for the entire project, it's important that we not only get it right but also get everyone on board.

@rawlinp Rob said:

We can certainly bring it up again. I don't agree with removing the support in each component for the previous version of the components it talks to, but I do agree that things shouldn't be set in stone. If you feel strongly that we should, you can bring it up on the list and we can discuss it as a community again.

That sounds to me like he's game for revisiting the conversation on the list. I know especially back then, a lot of decisions were made in github tickets, conference rooms, and sometimes private spaces. The team was still getting the hang of the "Open" part of open source. (And honestly, could probably still use some improvement in that space still.)
You've got a really good point about the team members being very different now, as well as the project. It really sounds like this is a conversation ripe for the list.

Yeah, that was not in the unedited version of his comment that I read in my email, and it came off very differently, though I doubt it was intended. All I'm asking is that the community be made aware of paradigm-shifting ideas like this so that other people can be involved before paradigm-shifting PRs get drive-by merged and end up setting the paradigm little input from other project members. Is this not a paradigm shift?

@rawlinp Can you please clarify: would you like to have a discussion on the list before considering this for merging?
We have a need for this at Comcast, and it's blocking further work. But I certainly don't want to ask someone to merge if you object. Thanks.

We should absolutely avoid a deployment order at all costs.  I agree that this is not the most elegant solution, but it is the best we could come up with to allow us to be backwards compatible given the breaking changes made with the 2.0 API.  Hopefully this is just temporary and we can avoid this in future major API version changes.  I don't believe that this is a pattern that we want to or should adopt unless absolutely necessary.
As for the decision to not be tightly coupled and not have a deployment order, I don't think any discussion is required; this is a founding tenant of our project.  It's not about tenure on the project and how decisions are made, it is a core tenant that frankly we could be better at following.

Maybe I overreacted when I saw this in the PR description:

it serves as an example of the idiom for future dev.

To me that came across as "all of our Go components should follow this example in the future". Those kinds of wide-spread decisions that affect all developers in the project need to be communicated so that everyone can get on board. However, based on Neuman's comment, it sounds like this is not supposed to be a decision like that since it's supposed to be a temporary solution just to get ORT to bridge the gap with the 2.0 API. Is that correct @rob05c?
Thinking about this more, this seems like an issue that would be permanent -- rather than just bridging the gap from 1.4 to 2.0, we will likely need a solution to bridge the gap from 2.0 to 2.1, 2.1 to 2.2, and so on, indefinitely.
For example, let's say ORT is using an unvendored TO Go client that's currently at 2.0. Traffic Ops is currently running 2.0 in Prod. A dev adds a new field for deliveryservices and bumps the version on master to 2.1. The TO Go client on master is then updated to request 2.1. A new release is cut from master, so now the new build of ORT requests 2.1 as well. However, Prod TO is still only running 2.0, and it will 501 any request for 2.1 -- therefore, ORT will not function if it's upgraded before TO is.
Using both a vendored and un-vendored version of the Go client kind of solves this problem, but the problem with that is that ORT is not vendoring the corresponding Go structs. So ORT is making 2.0 requests but unmarshalling them into 2.1 structs. Unless ORT also "sanitizes" the 2.1 fields to their default values before using them, this approach will lead to some odd bugs where ORT assumes the wrong default value. If this is going to be the solution going forward, indefinitely, then I think we might have to put some more thought into this approach.
If the correct 2.1 defaults are set on the resulting 2.1 struct when a request is made to 2.0 but unmarshalled into a 2.1 struct, I think that would be fine, but sanitizing defaults seems like something that the client itself should handle. In fact, maybe the TO Go client should optionally downgrade the request one minor version if it gets back a 501. For instance GET /api/2.1/foos returned a 501, so optionally retry one time with GET /api/2.0/foos. If the retry was successful, set the proper 2.1 defaults and return the result. However, it wouldn't try to downgrade across major versions from e.g. 2.0 to 1.4, since we can't always assume that would be safe.
Would that work going forward from minor version to minor version, instead of vendoring the TO Go client indefinitely?

it serves as an example of the idiom for future dev.
To me that came across as "all of our Go components should follow this example in the future".

That wasn't the intention.

Also includes an example of the latest client getting Delivery
Services, and falling back to the vendored if the TO isn't the latest.
This isn't actually necessary right now, but it's likely to be very
shortly, and it serves as an example of the idiom for future dev.

When I said "it serves as an example of the idiom for future dev" I was referring to the phrase "example of the latest client getting Delivery Services, and falling back to the vendored if the TO isn't the latest," specifically these lines:

            dses, unsupported, err := cfg.TOClientNew.GetCDNDeliveryServices(server.CDNID)
            if err == nil && unsupported {
                log.Warnln("Traffic Ops newer than ORT, falling back to previous API Delivery Services!")
                dses, err = cfg.TOClient.GetCDNDeliveryServices(server.CDNID)
            }

The sentence "it serves as an example of the idiom for future dev" wasn't intended as a broad sweeping declaration, but in context, for this very particular code pattern in ORT, as long as it exists. Or in other words, "I wrote something to show people how to do it, even though it isn't actually necessary yet."

the problem with that is that ORT is not vendoring the corresponding Go structs

You are correct: if a developer uses a new feature in the latest version of Traffic Ops in ORT with a TOClient call and not a TOClientNew call, it will be a runtime error, not a compile-time error.
I agree, that isn't desirable. This solution isn't perfect.
You are also correct that the cause of this is ORT/atstccfg not vendoring the client structs.
The problem is, if we vendor the client structs, they become different symbols than used by lib/go-atscfg. Further, it's not possible to write conversion functions (e.g. VendoredDSToDS()) because Go doesn't allow naming vendored symbols. We would have to either convert every object in-place, with a huge amount of duplicate and illegible code, or else not use libraries for anything that uses lib/go-tc.
Again, this solution isn't perfect. There are a number of alternatives, each with their own disadvantages. If there's a perfect solution, I haven't seen it.

maybe the TO Go client should optionally downgrade the request one minor version if it gets back a 501. For instance GET /api/2.1/foos returned a 501, so optionally retry one time with GET /api/2.0/foos. If the retry was successful, set the proper 2.1 defaults and return the result.

There are several disadvantages with that. It hides the behavior from apps using the client, and makes it impossible for them to discern between the latest and a client-assumed default. In cases where the client (ORT/TM/etc) needs to discern and act differently than the presumed-default, it can lead to the app doing the wrong thing, without even realizing it. And because the TO client hides it, it becomes impossible to do the right thing. It's also considerably more code in the client; likely more than it would take in actual apps using the client (e.g. ORT only uses a few functions/endpoints). I'm guessing most apps will also need to do their own handling for previous versions, in which case it hasn't saved any code for apps using the TO Client.
I'm not saying that solution is bad, just that there are disadvantages, as with this solution.
I think both this PR and your suggestion both have potential run-time errors. But this solution seems pretty easy for ORT developers to maintain. It seems unlikely that someone working on ORT won't be aware that the new feature they're adding is new, or if they don't, that they won't test and immediately discover it doesn't work. And this seems relatively easy for ORT developers to work with - it's a few lines to add new features, the extra code goes away as soon as the next release is made, and it's equally easy to refresh the vendored client (even without the helper script I added).
For the time being, would this solution be ok, just to make ORT work? And maybe we can rethink the client later?

maybe the TO Go client should optionally downgrade the request

I'd also like to add, as someone who is frequently forced to use the TO client, a frequent pain point is the opacity and hiding of information from the user, trying to do the "right thing," which ends up making it difficult or impossible for the client's user to do what needs done. This isn't a new pain point, and it isn't exclusive to version things. It's bad enough, I've frequently seriously considered making my apps just use http.Client instead, because it would be easier. But the biggest example of this is the API version. You can't tell the client to request a different API version, or even find out the API version it's using. In theory, this is the "right" solution, but in practice, it often makes it extremely painful to work with.
If we go with something along the lines of your suggestion, I think it would make it a lot easier to use if instead of automatically requesting different versions, we let the user decide. For example, we could have two clients, client and "traffic_ops/clientprev" which actually share all the logic code except the request functions. Or maybe the same client with e.g. GetDeliveryServices() and GetDeliveryServicesV14(), where the latter either actually returns a DeliveryServiceV14, or else a DeliveryService with any fields newer than V14 nil (the advantage of that is the symbol doesn't change, doesn't break compiles, and doesn't require updating client apps when the real symbol changes; the disadvantage is that users would have to be aware of it). Along with some kind of GetSupportedVersion(). Something along those lines. Speaking from experience, giving users control like that would be a lot easier to use, and help with a lot of the pain points of the client.

It does. Sorry, I guess I wasn't clear, when I said it includes an example, I meant it actually does it, as an example:
https://github.com/apache/trafficcontrol/pull/4534/files#diff-e51ad5f29db169bda046e91786532d5fR82

oh - I build the binary and deployed in my local environment and not seeing that behavior.
Getting this in the access logs of TO
{{ip}} - admin [27/Mar/2020:22:11:27 +0000] "GET /api/1.4/deliveryservices?cdn=2 HTTP/1.1" 200 2696 13 "atstccfg/0.2"

Hm, it's supposed to, maybe there's a bug. I tested locally too, but maybe I missed something. I'll try again, and specifically try to test this new feature.
If you run with warning logs (ORT does by default), do you see this message:
log.Warnln("Traffic Ops newer than ORT, falling back to previous API Delivery Services!") ?

@rob05c You bring up a good point about the client hiding things from the user -- things it already does today like attempting to re-login once when a 401 is received using request(). My idea is similar to that, except it wouldn't have to be a hidden behavior -- it could be optionally enabled when creating a new client instance but disabled by default. We should probably make re-login attempts optional as well. Regardless, I don't think that needs to be done in this PR.
Unmarshalling 1.4 requests into a 1.5 struct without sanitizing to 1.5 defaults does still kind of worry me, but that depends on whether or not the fields actually have defaults to sanitize to. For DSes going from 1.4 to 2.0, they probably don't need sanitized.
Anyways, might this be the problem that @mhoppa found? https://github.com/apache/trafficcontrol/pull/4534/files#diff-f0dfb4074818384cd25f1aeb52e7f0f4R42 That looks like it would make the "new" client still use the "old" (vendored) client, right?

I do not see the log message:
Traffic Ops newer than ORT, falling back to previous API Delivery Services!

It seems like we would have to  ~vendor~ copy the old TO client to a new package name in order to differentiate between the vendored and non-vendored client, right? Otherwise the imports will be exactly the same in toreq and toreqnew, and I guess the vendored client always wins?

/toreq vendors the client itself, and /toreqnew doesn't. So /toreqnew shouldn't be using the vendored client.
Each package uses its own set of libraries, including vendoring. And the vendored library is treated as different, so they aren't compatible. I.e. if you tried to cfg.TOClient.C = cfg.TOClientNew.C it wouldn't compile, because their traffic_ops/client.Session symbols are different types.

@mhoppa Ok, I just ran it with a master TO, and my TO logs have:
<IP_ADDRESS>:55408 - rbutts201 [27/Mar/2020:23:12:43 +0000] "GET /api/1.4/deliveryservices_required_capabilities? HTTP/1.1" 200 40 10 "atstccfg/0.2"
<IP_ADDRESS>:55480 - rbutts201 [27/Mar/2020:23:12:43 +0000] "GET /api/2.0/deliveryservices?cdn=2 HTTP/1.1" 200 52384 66 "atstccfg/0.2"
<IP_ADDRESS>:55446 - rbutts201 [27/Mar/2020:23:12:44 +0000] "GET /api/1.4/deliveryservices_regexes.json? HTTP/1.1" 200 9558 974 "atstccfg/0.2"
<IP_ADDRESS>:55434 - rbutts201 [27/Mar/2020:23:12:45 +0000] "GET /api/1.4/deliveryserviceserver?limit=999999 HTTP/1.1"<PHONE_NUMBER> 1907 "atstccfg/0.2"

Which is exactly what I'd expect, requesting 2.0 for the toreqnew call, and 1.4 for all the other toreq funcs.
Just to be sure, I also added a debug print in the master not-vendored traffic_ops/client, and saw it get printed:
ERROR: deliveryservice.go:164: 2020-03-27T17:12:43.522066-06:00: DEBUG master GetDeliveryServicesByCDNID path '/api/2.0/deliveryservices?cdn=2' apiBase '/api/2.0'

Is it possible the client in your master traffic_ops/client dir is still 1.4 somehow?
Alternatively, is it possible you have a vendored directory somewhere? Go will check for one all the way up, e.g. if there's one in / or /traffic_ops or /traffic_ops/ort or /traffic_ops/ort/atstccfg it'll use that.
In particular, this PR moves the vendor dir from /traffic_ops/ort to toreq - which, git moves are actually dones as delete and create - did the delete not work, is /traffic_ops/ort/vendor still there?

things it already does today like attempting to re-login once when a 401 is received using request().

Yep, that's one of the pain points I've hit. And I'm certainly not blaming anyone--pretty sure I wrote that. And it's mostly what you need as a user. Until you don't.

My idea is similar to that, except it wouldn't have to be a hidden behavior -- it could be optionally enabled when creating a new client instance but disabled by default.

+1. In fact, if you have to have the funcs anyway, e.g. GetDSPrev() DSV14, GetDSLatest() DS, GetDS() { if !GetDSPrev && cl.FallbackToPrev { GetDSLatest }, if it's not any more code, I'd vote exposing those. Give users the option of always using the prev, if they don't need new features and feel it's safer. Even more client control, for people who want/need it.

We should probably make re-login attempts optional as well.

+1

Regardless, I don't think that needs to be done in this PR.  Again, as someone who frequently uses the client, I've put a lot of thought into it. And to be honest, I'm still not certain what the ideal, least-painful client looks like. But I agree it's worth trying to make it better.

Unmarshalling 1.4 requests into a 1.5 struct without sanitizing to 1.5 defaults does still kind of worry me, but that depends on whether or not the fields actually have defaults to sanitize to. For DSes going from 1.4 to 2.0, they probably don't need sanitized.

I'd vote we make all new fields default nil, and require that all TC apps handle that. That seems safest anyway. Doing otherwise would require hackery to make upgrading work at all anyway.

Each package uses its own set of libraries, including vendoring.

Oh I see, you moved the vendor dir down into the toreqnew. That makes sense. FWIW I just built and tried this locally too, and I see atstccfg requesting 2.0 for /deliveryservices?cdn= but 1.4 for everything else. So seems to be working as expected for me at least.

btw the issues I was running into was using the incorrect URL for TO_URL it just needs to be the base url and I was using the old format causing issues. Thanks to @rob05c for helping me through it


Fix issue with global var for Vue 2

Thanks for your work on this component! I'm still using Vue 2 and have trouble getting it to run with VuePress, presumably because of this issue with the global var that has been fixed for v2.0.0.  Can we backport this for v1? That would be amazing!

Hey @tillsanders, thanks for the PR. Tomorrow evening i will merge this and release a new version. Ok?

Amazing! Thank you so much, that was fast! I've already integrated it in my project, the OpenElectionCompass ;)

Just checked OpenElectionsCompass and it's a great work! Maybe i should add a section to the readme to show cool projects like yours :) anyway cheers 🍻


Code signing with corporate code signing certificate

I assume this build process support pfx files that are secured to specific users? Is it possible to safely sign with company code sign certificate ?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: be2ace35-a6ef-349a-e009-ca55e3778602
Version Independent ID: 85a92e95-828a-54f8-b7e7-4f86b8e76abc
Content: Configure a C# UWP app in App Center - Visual Studio App Center
Content Source: docs/build/windows/uwp/first-build.md
Service: vs-appcenter
Product: unspecified
GitHub Login: @siminapasat
Microsoft Alias: siminap

@arfurdo The comments feature of our documentation is intended to enable customers to suggest changes to the docs or ask clarifying questions about the docs.
App Center support is provided directly from within the App Center portal. Any time you need help, just click the blue chat button in the lower-right corner of any page and our dedicated support team will respond. For additional information, see the [App Center Help Center] (https://intercom.help/appcenter/getting-started/welcome-to-app-center-support).


Get local value with 'let' in switch-case

switch-case formatting with general with TCA code convention.

@stephencelis Ah, you guys use Apple's swift-format. I know this would've been formatted using Nick Lockwood's swift-format, but I imagine you all prefer a 1st party solution, even if it's not as powerful


Patch-release process should handle non-main branches.

In this CI job, I manually triggered the bump-version job on the release-0.32.x branch in order to do a 0.32.1 patch release (#3620). It seems that the CI-job yaml refers to main in at least two places: when pushing from a local refspec to the repository, and when creating a PR. The former can be HEAD and the latter has to be the actual name of the branch we're running on, which can likely be found from the script's environment.

Fixed now!


Upgrade the installer from Netbeans 14

https://issues.apache.org/jira/browse/NETBEANS-3342 being officially resolved some time ago... Upgrade these libraries from Netbeans 14 as per the instructions.

Yeah, I have the impression that java is needed to install SDK. And the shipped JDK is not used at this stage..


How to avoid implicit timeout with WebDriver::findElements()

What are you trying to achieve? (Expected behavior)
Trying to avoid the implicit timeout with WebDriver::findElements()
What do you get instead? (Actual behavior)
Even if I set the implicit timeout to zero (WebDriver::manage()->timeouts()->implicitlyWait(0)), calling WebDriver::findElements() keeps waiting instead of exiting directly as it does with WebDriver::findElement().
How could the issue be reproduced? (Steps to reproduce)
$webdriver->manage()->timeouts()->implicitlyWait(0);
$webdriver->findElements(WebDriverBy::xxxx());

Using implicitlyWait(0) before findElement(), it exits directly throwing NoSuchElementException.
I would like to do the same with findElements().
Details

Php-webdriver version: facebook/webdriver, 1.5.0
PHP version: PHP 7.0.27-0+deb9u1 (cli) (built: Jan  5 2018 13:51:52) ( NTS )
Selenium server version: elgalu/docker-selenium latest (3.11.0-p3)
Operating system: Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64 GNU/Linux
Browser used + version: Chrome stable: 65.0.3325.162, Chromedriver: 2.37.543619 (a237acd3116cac3b3f0da42a000502ce3fafcb23)
https://github.com/elgalu/docker-selenium/releases/tag/3.11.0-p3

This is proper behavior of findElemens. Unlike findElement, it does not throw an exception if none element is found (and returns empty array instead).
If you for some reason need to exit if findElemens does not find any element, you can throw the exception by yourselves:
$elements = $webdriver->findElements(WebDriverBy::xxxx());
if (count($elements) === 0) {
    throw new \Exception(...);
}


Fix #16: now onTapping logo button you can redirect to college website

Pull Request: Adding onTap functionality with InkWell and integrating url_launcher
Description
This Pull Request introduces the onTap feature to the existing widget using InkWell and integrates the url_launcher package for opening a website when the widget is tapped.
Changes Made

Added InkWell to enable the onTap functionality.
Integrated the url_launcher package for opening a website.
Updated the pubspec.yaml file with the url_launcher dependency.

Hello @Abhigyan103 , I have just added onTap functionality to the widget using InkWell. Also updated the pubspec.yaml file with the url_launcher dependency. Take a look!


feat: Add wasm-bindings and integrate oracle module in app

1. Overview

Integrated the Oracle module in app.go.

Added the custom CosmWasm bindings get_exchange_rate and get_all_exchange_rates for the contract to fetch the exchange rate.

2. Implementation details

Registered cosmWasm custom querier in the wasm keeper.

Added persistenceCore as a supported features in wasm keeper which will work as the binding between smart contract and the wasm keeper

CosmWasm contract will be able to query the keeper using was cosmWasm bindings and custom querier

3. Checklist

[x] Does the Readme need to be updated?

awesome while you are at it, could you also put a sample readme.md or guidelines to add a custom message?
Example I want to add liquid-stake txn, liquid-unstake, be able to query exchange rate.....

meant to request changes.
Also, I agree with @puneet2019 , let's use Osmosis approach with proto-encoded stuff.

I think we should make a separate PR for this.

I rebased the development branch with the latest main.
The Main branch had major changes so again had to add the changes to this PR.
@xlab Check once and let me know if everything looks fine.

Closes<PHONE_NUMBER>


Support loading of opencv flann and viz

Systems: OSX 10.12.3 and Linux
Julia: 0.6.0-pre.alpha.49, master/eca966c
Description:

Attempting to load libopencv_flann headers from  /usr/local/include/opencv2/opencv.hpp results in error: cannot use typeid with -fno-rtti.
This indicates that rtti is required to support flann.
Trying to load libopencv_viz on Linux (but not OSX) appears to cause errors. This needs to be confirmed and debugged.

julia> using OpenCV
In file included from :1:
In file included from /usr/local/include/opencv2/opencv.hpp:62:
In file included from /usr/local/include/opencv2/flann.hpp:48:
In file included from /usr/local/include/opencv2/flann/flann_base.hpp:40:
In file included from /usr/local/include/opencv2/flann/params.h:33:
/usr/local/include/opencv2/flann/any.h:58:51: error: cannot use typeid with -fno-rtti
    virtual const std::type_info& type() { return typeid(T); }
                                                  ^
/usr/local/include/opencv2/flann/any.h:268:31: error: cannot use typeid with -fno-rtti
        if (policy->type() != typeid(T)) throw anyimpl::bad_any_cast();
                              ^
/usr/local/include/opencv2/flann/any.h:277:31: error: cannot use typeid with -fno-rtti
        if (policy->type() != typeid(T)) throw anyimpl::bad_any_cast();
                              ^
/usr/local/include/opencv2/flann/any.h:285:34: error: cannot use typeid with -fno-rtti
        return policy->type() == typeid(anyimpl::empty_any);
                                 ^
/usr/local/include/opencv2/flann/any.h:305:34: error: cannot use typeid with -fno-rtti
        return policy->type() == typeid(T);
                                 ^
WARNING: requiring "OpenCV" in module "Main" did not define a corresponding module.

Just a few more pointers, I am experiencing same issue. Although (OSX Sierra) I am successfully able to load dylib libraries using Libdl.dlopen.
               _
   _       _ _(_)_     |  A fresh approach to technical computing
  (_)     | (_) (_)    |  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.6.0-pre.alpha.229 (2017-03-22 21:53 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit cc917b5 (0 days old master)
|__/                   |  x86_64-apple-darwin16.4.0

julia> Libdl.dlopen("/Users/abisen/opt/opencv3/lib/libopencv_flann.dylib", Libdl.RTLD_GLOBAL)
Ptr{Void} @0x00007f9030449230

julia> Libdl.dlopen("/Users/abisen/opt/opencv3/lib/libopencv_viz", Libdl.RTLD_GLOBAL)
Ptr{Void} @0x00007f90353714b0

julia> using OpenCV
In file included from :1:
In file included from /Users/abisen/opt/opencv3/include/opencv2/opencv.hpp:62:
In file included from /Users/abisen/opt/opencv3/include/opencv2/flann.hpp:48:
In file included from /Users/abisen/opt/opencv3/include/opencv2/flann/flann_base.hpp:40:
In file included from /Users/abisen/opt/opencv3/include/opencv2/flann/params.h:33:
/Users/abisen/opt/opencv3/include/opencv2/flann/any.h:58:51: error: cannot use typeid with -fno-rtti
    virtual const std::type_info& type() { return typeid(T); }
                                                  ^
/Users/abisen/opt/opencv3/include/opencv2/flann/any.h:268:31: error: cannot use typeid with -fno-rtti
        if (policy->type() != typeid(T)) throw anyimpl::bad_any_cast();
                              ^
/Users/abisen/opt/opencv3/include/opencv2/flann/any.h:277:31: error: cannot use typeid with -fno-rtti
        if (policy->type() != typeid(T)) throw anyimpl::bad_any_cast();
                              ^
/Users/abisen/opt/opencv3/include/opencv2/flann/any.h:285:34: error: cannot use typeid with -fno-rtti
        return policy->type() == typeid(anyimpl::empty_any);
                                 ^
/Users/abisen/opt/opencv3/include/opencv2/flann/any.h:305:34: error: cannot use typeid with -fno-rtti
        return policy->type() == typeid(T);
                                 ^
WARNING: requiring "OpenCV" in module "Main" did not define a corresponding module.

My vtk was installed using Homebrew with the following parameters brew install vtk --c++11 --verbose

I have identified the culprit that is causing the error. Although OpenCV_libs.jl#27 comments out the library. Corresponding #include in include/opencv2/opencv.hpp#61-63 also needs to be commented out.
That would at least allow the module to load without errors.

Corresponding #include in include/opencv2/opencv.hpp#61-63 also needs to be commented out.

Thanks for your feedback.  Indeed, this is what I currently recommend as a temporary solution.  However, this is not a permanent solution and therefore the issue here has been filed to enable typeid with -fno-rtti


[go_router] Using ref.watch from riverpod  inside the build context  navigation does not work

In my build context i have used  ref.watch(settingControllerProvider).languageCode to rebuild the MaterialApp  when language change . The problem is when the event is fired to navigate to next page it does not do any thing
using context.pushNamed(homeNameRoute); so when i remove ref.watch navigation works properly but the MaterialApp does not rebuild
@override
  Widget build(BuildContext context) {
    languageCode = ref.watch(settingControllerProvider).languageCode;
    themeMode = ref.watch(settingControllerProvider).themeMode;
    Analytics.logCurrentScreen(screenName: 'main');
    return MaterialApp.router(
      debugShowCheckedModeBanner: false,
      restorationScopeId: 'main',
      routeInformationParser: AppRouter.router().routeInformationParser,
      routerDelegate: AppRouter.router().routerDelegate,
      title: 'Swap Recycling',
      themeMode: ThemeMode.system,
      darkTheme: AppTheme.darkTheme,
      theme: getThemeData(themeMode,languageCode),
      localizationsDelegates: const [
        AppLocalizations.delegate,
        GlobalMaterialLocalizations.delegate,
        GlobalWidgetsLocalizations.delegate,
        GlobalCupertinoLocalizations.delegate,
      ],
      locale: languageCode == LanguageCode.en.name ? AppLocales.en.locale : AppLocales.th.locale,
      supportedLocales: AppLocales.supportedLocales,
    );
  }

Hi @rddewan,
Can you please provide your flutter doctor -v  and a minimal complete reproducible code sample?
Please also specify the version of go_router, you're using.
Thank you

@danagbemava-nc  sure let me create a clean project on it

@danagbemava-nc  here is the project link . Please use the riverpod branch
https://github.com/rddewan/flutter-go-router-demo/tree/riverpod

Hi @rddewan, I only see a loading indicator when I open the app. Is that supposed to be happening? See screenshot below
Also, it would be best if you could reduce the sample to only the relevant parts that reproduce the issue.

@danagbemava-nc  yes it's correct. This is the problem it get stuck at splash screen in loading state and never navigates to login page
class SplashScreen extends ConsumerStatefulWidget {
  const SplashScreen({Key? key}) : super(key: key);

  @override
  _SplashScreen createState() => _SplashScreen();
}

class _SplashScreen extends BaseConsumerState<SplashScreen> {
  @override
  Widget build(BuildContext context) {
    ref.listen<AppState>(appControllerProvider, (previous, next) {
      next.themeMode?.when(
        data: (data) {
          context.goNamed(loginNameRoute);
        },
        error: (e,s) => Center(child: Text(e.toString())),
        loading: () => null,
      );
    });
    return const Center(
      child: CircularProgressIndicator(color: Colors.white,),
    );
    }

}

Hi @rddewan, I'm not certain this is an issue with go_router. I changed the call to context.goNamed() to show a dialog when the data is received and the dialog wasn't shown either unless I removed the ref.watch from the main build method.
Can you also check to see if the same thing happens for you?

@danagbemava-nc  Yes it's correct go_router does not work if we use ref.watch in the mail build method . That is the problem i am facing. According to riverpod ref.watch should be only used inside build method

@rddewan what I meant is, I modified your SplashScreen file to see if a dialog would show when it was supposed to navigate and the dialog wasn't shown either. The issue may lie somewhere else and not with go_router. Kindly check with the code sample below to see if the same thing happens.

updated SplashScreen
import 'package:flutter/material.dart';
import 'package:flutter_goroute_demo/base/base_consumer_state.dart';
import 'package:flutter_goroute_demo/feature/splash/presentation/controller/app_controller.dart';
import 'package:flutter_goroute_demo/feature/splash/presentation/state/app_state.dart';
import 'package:flutter_goroute_demo/route/name_route.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:go_router/go_router.dart';

class SplashScreen extends ConsumerStatefulWidget {
  const SplashScreen({Key? key}) : super(key: key);

  @override
  _SplashScreen createState() => _SplashScreen();
}

class _SplashScreen extends BaseConsumerState<SplashScreen> {
  @override
  Widget build(BuildContext context) {
    ref.listen<AppState>(appControllerProvider, (previous, next) {
      next.themeMode?.when(
        data: (data) {
          print("data: $data");

          showDialog(
              context: context,
              builder: (BuildContext context) {
                return AlertDialog(
                  content: Center(
                    child: Text('Show this dialog'),
                  ),
                );
              });
        },
        error: (e, s) {
          print('error: $e, stack: $s');
          return Center(child: Text(e.toString()));
        },
        loading: () => Center(
          child: LinearProgressIndicator(),
        ),
      );
    });
    return const Center(
      child: CircularProgressIndicator(
        color: Colors.white,
      ),
    );
  }
}

@danagbemava-nc  I guess it's a go_router issue as i have tested withe material router the same code works perfectly it can navigate to another page or show dialog

Hi @rddewan, if you implement the MaterialApp.router without using the go_router package, does it work as expected?

@danagbemava-nc  with MaterialApp.router routeInformationParser and routerDelegate is required  which i am passing it from go_router if just use MaterialRoute it is not required

Hi @rddewan, for the record, you can implement the MaterialApp.router without using go_router, go_router just makes it easier for you to do that.
That aside, I can reproduce your issue, however, in the current state of the project, there are too many files to skim through and that might make getting to the root cause a little bit difficult. Can you reduce your sample to only the relevant classes required to reproduce the issue? Maybe only the main, splash, and signup screens, along with their relevant states?
Thank you

@danagbemava-nc  sure i will try to remove files that are not required

@rddewan
The behavior is strange when you rebuild MaterialApp.router() with another instant of routerDelegate. In this case, the router will think that you replace the old routerDelegate with a new one.
Your code is fixed by using final router;
class _MyAppState extends ConsumerState<MyApp> {
  String? themeMode;

  final router = AppRouter.router(); // here

  @override
  Widget build(BuildContext context) {
    themeMode = ref.watch(settingControllerProvider).themeMode;
    return MaterialApp.router(
      restorationScopeId: 'main',
      debugShowCheckedModeBanner: false,
      routeInformationParser: router.routeInformationParser,
      routerDelegate: router.routerDelegate,
      title: 'Flutter Demo',
      theme: setThemeData(themeMode),
      //builder: (_,child) => HideUIWidget(child: child),
      //home: const LoginScreen(),
    );
  }

  ThemeData setThemeData(String? code){
    if (code == ThemeMode.light.name) {
      return ThemeData(
        primarySwatch: Colors.blue,
      );
    }

    return ThemeData(
        primarySwatch: Colors.blueGrey,
      );

  }
}

thank you let me try this out

Related to #102952


The Swiper-way to use breakpoints

I have studied the market for image sliders and carousels for many years and I have to say that nothing comes close to Swiper. It really is a revolutionary piece of software. I am trying to make it the go-to software for every e-commerce website I build as I really think Swiper can be adapted to most scenarios. However, it is true that today, many websites require a nice slider for tablets and desktop but just need images stacked on top of one another on mobile devices, without a slider. Users are used to scroll up and down on small screens and this is a trend that seems to grow stronger and stronger. I have done a lot of research and all the solutions for implementing this functionality with Swiper point to convoluted workarounds which result in buggy and inconsistent behavior across devices. One of the most common solutions suggests destroying Swiper when resizing the browser window to a narrower state but Swiper does not recreate itself properly if the browser window is increased again.
What is the current true “Swiper-way” to display staked images (without swiper) on mobile devices and to have Swiper take over when the browser window is increased to 768 or above?

One of the solutions is to destroy/init Swiper. Another way is breakpoints (see docs), you can also just disable swiping on large screens using appropriate methods


application_status table records a history of application_status_type changes

The application_status table should contain the history of application_status_type changes. An application_status should not be updated.
The application table should have an application_status computed column, returning the latest status
Given that I am logged in as an applicant
When I start an application
Then an application_status record with the Draft status is inserted in the application_status table
Given that I am logged in as an applicant
When I submit an application
Then an application_status record with the Submitted status is inserted in the application_status table
Row-level security should be aligned with the application table (i.e. users can only update their application)

Hey team! Please add your planning poker estimate with Zenhub @AntBush @marcellmueller @matthieu-foucault @wenzowski