feat(amplify-provider-awscloudformation):  add --iterative-rollback

Description of changes

added updates to Deployment State Types in cli core
Updated push at the root cli level to validate --iterative-rollback
add iterative rollback before pushing resources
changed the error stack for deployment errors to include messages as stack gets cut off
add unit test for updated rollback state machine
e2e tests on iterative rollback (each test is between 30-45min)
implemented a trail of prev deployments when running iterative deployment (to be used by iterative rollback in case client loses connection) this deployment meta is then deleted if the cloud deployment is successful.
State Dir is intended to be ephemeral CLI will also delete the s3 state dir in cloud on iterative deployment and rollback.

Issue #, if available

Description of how you validated changes
Checklist

[x] PR description included
[x] yarn test passes
[x] Tests are changed or added
[ ] Relevant documentation is changed or added (and PR referenced)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Can we merge this in, i'd like to test it live

How this can be use? how the command look like? Cause I wanna try to solve this issue https://github.com/aws-amplify/amplify-adminui/issues/172 by using this, is it possible?


How to do Duratble Function with Visual Studio not VSCode?

We need example how to do with VS not VSCode because the experience is terrible

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

ID: 4885c7aa-95fd-b501-37c8-deaeaf5ec54b
Version Independent ID: 92dcd574-ffef-25f6-0a52-30dbce334b79
Content: Create your first durable function in Azure using C#
Content Source: articles/azure-functions/durable/durable-functions-create-first-csharp.md
Service: azure-functions
GitHub Login: @jeffhollan
Microsoft Alias: azfuncdf

Hello @MhAllan, Thank you for reaching out! here is the quick start document using Visual Studio.
Can you also elaborate more on what blockers you faced while following the documentation for VS Code? This is help us in improving the document.

That is, thank you, I struggled to find it by google all the time getting VSCode examples


Add display property to BoxProps

The often need is to make some inline-* component to be block (tooltips around form controls, sketelons, etc).
(There are more than dozen places with style={{ display: 'block' }} properties throughout my project.)
BoxProps interface has inline prop, which can only be set to true.
I'd like to request to add a display prop to BoxProps, just like position.

We added this prop in #810


Semi Unexpected Behaviour with Connect

Was debugging a component for a long time trying to figure out why this.props.dispatch wasn't available.
Turns out I had an empty object in my connect decorator;
@connect(mapStateToProps, {})

Once I removed the empty object, this.props.dispatch was available.
Was hoping somebody could explain why and if this should be the case.

This is not the relevant repository. You are probably asking about React Redux.
The reason is that second argument to connect() can be either a function or an object, per its documentation. If it is a function, it is expected to return the props to inject into the component. If it is an object, it will assume the values in that object are action creators, and inject bound action creators. The only case where you get just { dispatch } is when you don’t specify mapDispatchToProps at all.


chore: rename fields of Subarray to follow Lean conventions

OK, Mathlib builds against https://github.com/leanprover/std4/pull/733 and https://github.com/leanprover-community/aesop/pull/122 locally for me.

Closes #2164


chore: support Go 1.20+

Description:
Update go.mod to support Go 1.20+
Related Issues:
Fixes #21
Checklist:

[x] Review the CONTRIBUTING.md documentation.
[x] Add a reference to a related issue in the repository.
[x] Add a description of the changes proposed in the pull request.
[x] Add unit tests if applicable.
[x] Update documentation if applicable.
[x] Add a note in the CHANGELOG.md if applicable.
[x] Sign the Google CLA.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 33.00%. Comparing base (899e68f) to head (1513f9a).

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #30      +/-   ##
==========================================
- Coverage   38.31%   33.00%   -5.31%
==========================================
  Files           8        8
  Lines         924      924
==========================================
- Hits          354      305      -49
- Misses        514      560      +46
- Partials       56       59       +3

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Assert (with debug build) in NumberOfTrailingZeros()

Running reader code in debug mode, I got an assert assert(v != 0) with the stack below:
ZXing::BitHacks::NumberOfTrailingZeros<unsigned int,void>(unsigned int v) Line 85	C++
ZXing::BitHacks::NumberOfTrailingZeros<unsigned __int64,void>(unsigned __int64 v) Line 85	C++
ZXing::GetPatternRow<unsigned char const *>(ZXing::Range<unsigned char const *> b_row, std::vector<unsigned short,std::allocator<unsigned short>> & p_row) Line 385	C++
ZXing::GetPatternRow(const ZXing::BitMatrix & matrix, int r, std::vector<unsigned short,std::allocator<unsigned short>> & pr, bool transpose) Line 130	C++
ZXing::QRCode::FindFinderPatterns(const ZXing::BitMatrix & image, bool tryHarder) Line 72	C++
ZXing::QRCode::Reader::decode(const ZXing::BinaryBitmap & image, int maxSymbols) Line 80	C++
ZXing::MultiFormatReader::readMultiple(const ZXing::BinaryBitmap & image, int maxSymbols) Line 67	C++
ZXing::ReadBarcodes(const ZXing::ImageView & _iv, const ZXing::ReaderOptions & opts) Line 185	C++
ZXing::ReadBarcode(const ZXing::ImageView & _iv, const ZXing::ReaderOptions & opts) Line 144	C++

The initial value of v is 64bit 0xff00000000000000. Then arrive this line, it will become 0.
I would remove that assert. The following code seems to handle correctly 0 case, but I'm not sure, hence this issue.
Thanks!
P.S. Attached is input image that can reproduces the assert with ZXingReader example.

Nice to hear from you again after all this time :). Thanks for reporting this.


cloudflared issue

⚠ Please verify that this bug has NOT been raised before.

[X] I checked and didn't find similar issue

🛡 Security Policy

[X] I agree to have read this project Security Policy

Description
Stop cloudflared
Trace: TypeError: Cannot read properties of undefined (reading 'kill')
at CloudflaredTunnel.stop (/root/uptime-kuma/node_modules/node-cloudflared-t                       unnel/cloudflared-tunnel.js:115:27)
at module.exports.stop (/root/uptime-kuma/server/socket-handlers/cloudflared                       -socket-handler.js:112:21)
at shutdownFunction (/root/uptime-kuma/server/server.js:1709:11)
at async Server. (/root/uptime-kuma/server/server.js:1475:9)
at process. (/root/uptime-kuma/server/server.js:1728:13)
at process.emit (node:events:513:28)
at emit (node:internal/process/promises:149:20)
at processPromiseRejections (node:internal/process/promises:283:27)
at process.processTicksAndRejections (node:internal/process/task_queues:96:3                       2)
👟 Reproduction steps
node server/server.js
👀 Expected behavior
Starting
😓 Actual Behavior
Stop cloudflared
Trace: TypeError: Cannot read properties of undefined (reading 'kill')
at CloudflaredTunnel.stop (/root/uptime-kuma/node_modules/node-cloudflared-t                       unnel/cloudflared-tunnel.js:115:27)
at module.exports.stop (/root/uptime-kuma/server/socket-handlers/cloudflared                       -socket-handler.js:112:21)
at shutdownFunction (/root/uptime-kuma/server/server.js:1709:11)
at async Server. (/root/uptime-kuma/server/server.js:1475:9)
at process. (/root/uptime-kuma/server/server.js:1728:13)
at process.emit (node:events:513:28)
at emit (node:internal/process/promises:149:20)
at processPromiseRejections (node:internal/process/promises:283:27)
at process.processTicksAndRejections (node:internal/process/task_queues:96:3                       2)
🐻 Uptime-Kuma Version
last
💻 Operating System and Arch
ubuntu 20
🌐 Browser
/
🐋 Docker Version
/
🟩 NodeJS Version
v10.19.0
📝 Relevant log output
Stop cloudflared
Trace: TypeError: Cannot read properties of undefined (reading 'kill')
    at CloudflaredTunnel.stop (/root/uptime-kuma/node_modules/node-cloudflared-t                       unnel/cloudflared-tunnel.js:115:27)
    at module.exports.stop (/root/uptime-kuma/server/socket-handlers/cloudflared                       -socket-handler.js:112:21)
    at shutdownFunction (/root/uptime-kuma/server/server.js:1709:11)
    at async Server.<anonymous> (/root/uptime-kuma/server/server.js:1475:9)
    at process.<anonymous> (/root/uptime-kuma/server/server.js:1728:13)
    at process.emit (node:events:513:28)
    at emit (node:internal/process/promises:149:20)
    at processPromiseRejections (node:internal/process/promises:283:27)
    at process.processTicksAndRejections (node:internal/process/task_queues:96:3                       2)

👟 Reproduction steps

node server/server.js
Need detailed reproduction steps

👟 Reproduction steps
node server/server.js

Need detailed reproduction steps

Did my explain my self:
``Dear,
I am simply starting it from
cd dir and then node server/server.js but any starting command doesn’t work``

🟩 NodeJS Version  v10.19.0

It is not a supported version, please check the minimum requirements in the README.md.


Licences: Add Sustainable Use License

Used by:

networking/n8n
PR: fallout-ce
PR: fallout2-ce

Shouldn't n8n be updated to use this license definition?

Absolutely, I assumed it would be better done in a separate commit but I'll update this PR.


Requiring approvals on PRs

IMHO it would be a good idea to add branch protection for the master branch, requiring changes going through pull requests and requiring approval, or at least requiring approval on pull request (since commits on master to add AU or PUSH commands can be quite hepful).
@chocolatey/chocolateycommunitypackages Opinions about this?

I agree it would make sense to require at least one approval on pull requests, but I don't think it would make sense in a few scenarios to not allow it on the master branch since this would disallow all of the following to be pushed directly: quick bugfixes, minor metadata updates, using AU and PUSH commands and updating the files during appveyor build run.
I since there there isn't anyway to require at least one approval on PR without denying directly pushing against the master branch (as far as I know), I'm kinda against it.

Ah right, there's only the option for admins to bypass approval but not to bypass the branch protection.

I do think you can add individual members/teams that can bypass it as well.
But again, not entirely sure about that.

I think at least sec branch protection on master is a good idea (no force push, no delete).
As for the merge, I'm sorry. I'm not normally a clown merging random things. In the beginning there was barely any staff here and I had a lot of packages to push or fix. Tried to do as much as possible without taking up other people's time.

(Click to play)
But things have changed since then. Lesson learned! :+1:

@Redsandro There's actually a use case here where directly commiting to master makes sense, where you can use AU or PUSH keyword in commit message to force actions (See eg. here), which would no longer work if master requires a PR. Also the AppVeyor build commits changes back directly to master after a package was updated. So I think best solutions would be to give a limited user-set the possibility to directly commit to master (idealy just the AppVeyor build service user) and requiring PRs with approvals for everybody else.

Will only slow down things without any other benefit. Strongly against it.
Programmers should fix problems, not introduce new ones without any justification or simply due to theoretical ideas.
The core team is already selected among worthy contributes which proved their competence. Even few occasional errors in this regard do not justify this action IMO.

And it will strongly demote AU command usage [PUSH] and [AU] making them basically unusable.

I will withhold my opinion until I understand how it plays for forward movement. I think @majkinetor  presents a strong case against it and @AdmiringWorm presents a good case for it on just Pull Requests.
Can it be locked down to just PRs? I think last time I visited branch protection there was some good stuff but it was too limiting to move forward with. So I'm curious what has changed since.

@Redsandro said:

I think at least sec branch protection on master is a good idea (no force push, no delete).

I believe the master branch is already a protected branch which disables force push and deletion.
@ferventcoder said:

Can it be locked down to just PRs?

Not as far as I know, the information where you enable Require pull request reviews before merging also states as such:

When enabled, all commits must be made to a non-protected branch and submitted via a pull request with at least one approved review and no changes requested before it can be merged into master.

@ferventcoder these are the options:

So no. I'm pretty against this if it is not able to be locked down to just PRs.

I'm closing this issue since it unfortunately is not possible to just require approvers and still allow certain commits on master.

A bit late to the party, but I'll just say I agree with the decision. I'm normally a fan of requiring PRs for master (we have it enabled in most repos at work), but here the disadvantages, namely 1) preventing AU command usage and 2) making quick fixes impossible, IMO outweigh the advantages. As long as force push is disabled the branch is protected enough.


Update version to 4.2.2

This used to cause an issue when users were migrating from defaults to conda-forge, and the version on our system was too old
https://github.com/conda-forge/opencv-feedstock/issues/230#issuecomment-626341832
Checklist

[ ] Used a fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe:

License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

@conda-forge/ffmpeg kind bump.
@conda-forge-admin please rerender


fix: Fix index out of bounds error in nomos status command

This PR fixes nomos status to prevent it from panicing by ensuring the slice it references is of the right length.

/unhold


Return warnings in the filtered response

Warnings generated are only logged to the console. This is useful for local developlement of schemas but not when the library is used as part of other code. So modify the behaviour ot return the warnings along with the filtered schema.

@n1ru4l Please check this. I'm also unsure of the versioning, though I'd think it's okay to publish it as a minor version upgrade because the lib is still in alpha in npm.

@n1ru4l any feedback is welcome. Thanks.

Hey @joseph-neeraj, thank you for your contribution!
After thinking about this a bit, it might be a better solution to instead allow providing your own onWarning function, that allows generating the warning error array in userland.
https://github.com/n1ru4l/graphql-public-schema-filter/blob/c2be0c56208f516e3d5833689a1781ed159145e4/src/public-schema-filter.ts#L70-L72
const warnings = []
const onWarning = (warning) => warning.push(warning)
buildPublicSchema({ schema, onWarning })

will do @n1ru4l , been busy, I'll update it as soon as I get a chance, thanks :)

Superseded by this alternative MR.


Update ember-cli-aptible-shared to 0.0.25.

Changes included between v0.0.21 and v0.0.25

Fixes https://github.com/aptible/dashboard.aptible.com/issues/358.

Updated to fix hanging test issue (caused by upstream changes to provisioning resource polling).


Remove unused components/config

This PR removes

opscode-expander-reindexer
rabbitmq job's queue

neither of which are used in Chef Server

:+1: :boom: cruft.

cc @chef/chef-server-maintainers

+1


No source map is available. Ember-cli asks for it

Something like:
Warning: ignoring input sourcemap for bower_components/route-recognizer/dist/route-recognizer.js
because ENOENT

+1 Having the same issue.

+1 same for me since upgrading to ember-cli 0.1.12

Same issue here with ember cli pretender.
Warning: ignoring input sourcemap for bower_components/route-recognizer/dist/route-recognizer.js because ENOENT, no such file or directory '/Users/.../.../.../blog/ember/tmp/tree_merger-tmp_dest_dir-Ow3MPxou.tmp/bower_components/route-recognizer/dist/route-recognizer.js.map'

Same Here:
Warning: ignoring input sourcemap for bower_components/route-recognizer/dist/route-recognizer.js because ENOENT, no such file or directory '/home/../../../ember/tmp/tree_merger-tmp_dest_dir-nNouO1of.tmp/bower_components/route-recognizer/dist/route-recognizer.js.map'

I think it’s safe to say many people are having this problem and further “same”-type comments are unnecessary. Hopefully we’ll hear back soon!

+1

+1

Locking because this is an identified issue and :+1:ing it just spams every collaborator

Should be fixed.

Actually it's not, but will be in a moment

OK fixed in 0.1.9.


Crash if URL string contains cyrillic characters.

I was able to fix this in my own app by encoding the string provided to NSURL.
NSURL(string: "http://example.com/мама".stringByAddingPercentEscapesUsingEncoding(NSUTF8StringEncoding)!)

Thanks for chiming in @polysyn, it is much appreciated.
@njuri, please feel free to comment on this issue if that doesn't solve your problem. If there proves to be an issue with Alamofire, I'll be happy to re-open, but for now I'm going to close this out.
Cheers.


[Bug]: Unknown Error in: E-next v2.0

What happened?
I get an error after loggin in (auto). It seems that all is green except IDownloadCoupon who is empty.
I attached the error log:
Enroller
GUI
OS
Windows
Relevant log output
Traceback (most recent call last):
  File "base.py", line 299, in en
    link = item["site"]
KeyError: 'site'

Terms

[X] I am using the latest version available.
[X] I agree to follow this project's Code of Conduct

same here:
Traceback (most recent call last):
File "base.py", line 299, in en
link = item["site"]
KeyError: 'site'


Refactor SSLOptions API (JAVA-841, JAVA-948).

Make SSLOptions more generic to allow use of Netty implementation, or SSLEngine customization when default JDK implementation is used.
By default, don't restrict the ciphers presented by the client.
Add tests with Netty implementation backed by OpenSSL.
Upgraded Netty to 4.0.32 to use the new SslContextBuilder.

:+1: apart from very minor remarks (none of which being a blocker).

I think I've addressed all feedback so this should be ready to go. Let me know before merging so that I can squash the commits appropriately.

Force-pushed to clean up history and rebase on current 3.0.

class JdkSSLOptions method : newSSLEngine(SocketChannel channel)
this parameter : channel never used


Fix style when parent container is display:grid

A parent container with the style display: grid causes the captcha component to be rendered with 0 width and height

@Vengi717 Instructions to complete:

[ ] Replicate the issue. Load up one of the demos and create a div with display: grid. Load the Procaptcha component from within this div, and check to see if the above behaviour happens (captcha has 0 width and height)
[ ] Figure out what is causing this issue. Inspecting the css properties of the broken captcha in browser should give you a good idea as to what is causing this bug.
[ ] Fix the styling issue you find in the above step. This will be in either the web-components package or the procaptcha-react package (potentially both).
[ ] Check whether this bug also occurs with procaptcha-frictionless and procaptcha-pow. If so, fix these as well

Can't replicate

@forgetso can you clarify the bug please

Note: issue is for flex, not grid

Replicated issue with display: flex


Avoid HACS running twice in pull requests

HACS is running twice in pull requests, one for the push event and another one for the pull_request. This pull request adds a condition to run the push event only on master.

coverage: 99.901%. remained the same
when pulling 2e654b7dd6ebd2ef02534ebc8bc9b2a340cc343c on avoid_hacs_running_twice
into 403d420dc9c4ae8b69f21528e7827542c5daa25e on master.


Ignore the whole .idea folder

I don't know why, but only /.idea/workspace.xml and /.idea/libraries where in the .gitignore.
Because of that I got many files in .idea folder that git proposed me to commit. Usually IDE configuration should not be committed in the repository, and the whole .idea folder should be ignored.

There isn't any good reason, I just went with default gitignore generated by my IDEA.


3 reload modes: hard, soft, css-only. Reload on error pages.

This PR introduce 2 major changes:

3 different reload modes (css, soft, hard)
Auto-reload on error pages.

Reload modes:
Depending on what changed we can do different reload types.

When css files are changed we can inject new CSS into current page. This is especially cool when you do some actions on page (open dropdown, collapses, some ajax request etc), which will be reset after a page reload. This requires external css build tools like dart-sass, which will automatically rebuild css files.
When non-js files are changed we can do fast reload using Turbo.visit()
When js files are changed we must do a full page reload. If we do Turbolinks.visit(), it will detect that js files are changed and do a full reload anyway, but this will result in double page load.

Auto-reload on error pages: I have added a middleware which injects livereload code into error pages.
To be honest, i did this couple of month ago and did not have time to submit a PR, and now looking at the code it looks like an alien wrote it. But if you think i need to improve something in this PR, i'll try to do this.

@elik-ru thanks for the PR 🙌 I will review and test on the weekend

Nice PR. Tested at my end, the only thing that didnt work out was the default :css mode, my setup is jsbundling + cssbundling + talwindcss.
It fails silently here because my stylesheet tag do not contain a stylesheet data attribute, as your code is expecting. My link is:
<link rel="stylesheet" href="/assets/application-{{big-hash-here}}.css" data-turbo-track="reload">

I could fix it adding the data attribute manually, like this:
# application.html.erb
<%= stylesheet_link_tag "application", "data-turbo-track": "reload", "data-stylesheet": "application.css" %>

Is this expected?

@LEstradioto Thanks for your feedback!
Yes, this is kinda expected, because actual filename differs form digested url, and digested url changes when file changes, there is no easy way to match actual filename and corresponding

Hi @kirillplatonov! How is it going? Can i help you in somehow to make it easier to review?

@elik-ru could you please extract reloading on error pages into separate PR? It would be easier to review and merge this way

@kirillplatonov There 2 commits for 2 features, but seems some improvements leaked from one to the other.
Ok, i'll prepare 2 separate PRs

Continuation: https://github.com/kirillplatonov/hotwire-livereload/pull/46


Wrap the ncOpen calls to append the file name to the exception message.

Wrap the ncOpen calls to append the file name to the exception message.
Fixes #480

Really only does what it says in the title.

Pedantically, I could ask for the catch part to be put into a function to avoid code duplication, but realistically, that would probably require more code and just save two duplicated lines...

I had exactly that thought and came to the same conclusion. Possibly with a frisson more laziness.


RFC: DE<>GIS Dataset Review Process + Internal Publishing Versions

Problem Statement
When DE has finished a build, we've often encountered some combination of the following problems:

It's not clear to GIS (or Amanda) what build of a dataset should be reviewed.
The status of a dataset in the publication lifecycle (being built, awaiting review, in review, approved) isn't clear.
Files for datasets that have been reviewed are potentially (maybe even often) overwritten by subsequent builds.
There's not clear lineage backwards from the published / distributed datasests (e.g. on Socrata / Bytes) back to their raw files.
There's no review history for subsequent builds and reviews of a dataset.

e.g. say we're in our third QA cycle of PLUTO 24v1.1, where should we look to know why the second build failed QA?

Proposed Solution
For all of our products, we should add a subfolder under the version to indicate the draft publication version. The current state looks like this:

current:      edm-publishing / db-pluto / publish / 24v1.1 / dataset files
proposed:  edm-publishing / db-pluto / publish / 24v1.1 / draft publication version / dataset files

The draft publication version will be composed of an integer version, and a summary to describe the the build, similar to the summary line of a git commit. A list of builds versions could look like this:

1-initial-build
2-add-new-corrections
3-fix-zoning

I suggest an integer version instead of a timestamp because we don't really care when the draft was published, whereas the integer corresponds to something that we do care about. e.g. if we're in round three of PLUTO publishing, and you see that the last draft publication is 6-fix-the-issue then you immediately know something is wrong.
Draft Publication Github Issues
Our Publishing Github Action will create a Github Issue for every published build version. Decisions, discussions, etc should be documented on that issue. They should all be linked back to a parent Issue for a build of a dataset.
The Issue for the draft publication should use Github Labels to indicate the status. A list of statuses might be:

Ready
In QA
Passed
Failed

Perhaps we can auto-add all of GIS as an Assignee
Implementation Details (Technical)

in DO: Migrate everything in the publish folder to this new scheme.
in GHA: Modify our Publish action to accept a changes summary field, which will be used to generate the draft publication version. The integer part will be inferred from existing versions on DO.
in dcpy: The draft publication version concept needs to be added to the edm publish connector. Publish functionality should refuse to overwrite existing data.

Implementation Details (Nontechnical)

Within this new framework, everything under a products draft folder should be considered deletable.
Need to work with GIS to change procedures.

Other Considerations

I think it's nearly time (if not actually time) to do away with the latest folders. It's a convenient hack, but has the liability of being potentially out of sync with actual latest versions. As part of this, we could help GIS migrate off. We could either supply them python code to infer last build version, or add a REST endpoint to the QAQC app to redirect to the DO location.
We could certainly use some utilities around tidying up our edm publications bucket. e.g. CLI tooling to flag or move "misplaced" items, e.g. edm-publishing / db-pluto / 23v2 which should be (presumably) under the draft folder.
Regarding what we call the datasets in our publishing folders, is there a better term than draft publications? publication drafts? They really are just drafts of what we'll eventually publish.
What repo should Draft Publication Issues live in?

Example Workflow for GIS (Copied from @sf-dcp's comment)
Suppose we're building PLUTO v24.1.

DE creates parent issue for a dataset build manually, lets call it PLUTO v24.1. DE kicks off a build.
DE reviews internally, and publishes via the Github action (no changes to process so far)
GHA generates new Issue PLUTO v24.1 1-initial build (child issue), tagged as Ready and GIS team is added to the issue
GIS updates the child issue's tag In review:
Their QA review looks good. They put tag Passed for the child issue
Their QA review asks for changes --> They put tag Failed for the child issue --> They note required changes in the child issue --> we repeat the process for generating consecutive child issues.

Whiteboarding

Nice write-up! Thank you for doing it. Quick q: we can still use draft/ dir for DE internal testing, correct? And when we intend to build-build, we will be using publish/?

I'm also a bit unclear about GH issues... It sounds like the workflow will be as follows:

Create parent issue for a dataset build manually, lets call it PLUTO v24.1
Automatically generated issue PLUTO v24.1 1-initial build (child issue) --> We add tag Ready --> GIS added to the issue, they update tag as In review:

Their QA review looks good. They put tag Passed for the child issue
Their QA review asks for changes. They put tag Failed for the child issue. They note required changed in the parent issue --> we repeat the process for generating consecutive child issues.

Does that sound right?

I'm also a bit unclear about GH issues... It sounds like the workflow will be as follows:
...
Does that sound right?

@sf-dcp Yes - thank you, I was a little light on the details around the GIS workflow. Your distillation is very clear though - will copy that over to the main description above. That's exactly what I'd envisioned.

@sf-dcp Ah, the one difference I'd envisioned is that GIS would note required changes in the child issue, not the parent. Updated main text with your example flow.

I really have basically no notes on this write-up. This all sounds great, and makes complete sense for how we generally interact with these once they're in this review state. My main note is that GIS support in terms of data access is a bit of a footnote, and that it really needs to be a key part of this, we can't have a result be that they have to struggle manually with a new folder structure.
Counterpoint would be to just keep "latest" for now. But seems like while we're touching all this stuff will be the best time to get work on a longer-term solution

@alexrichey
This all sounds great!

Regarding what we call the datasets in our publishing folders, is there a better term than draft publications? publication drafts? They really are just drafts of what we'll eventually publish.

I guess if these don't live in the DE-only draft folder, I'm hesitant to call them any type of draft
revisions? builds is alo the term we seem to naturally use when we're talking too. so maybe draft builds, publication builds?

It seems like the verb "publish" here means "DE declares a certain build is ready for QA." So once a build passes QA, which verbs are next. I guess "package and "distribute"?
I'm still really like "stage" as a verb for "DE declares a certain build is ready for QA", but wouldn't mind "publish" if we're happy with it only meaning that.

Might also be good to distance from staging in that it has a very specific meaning for datasets in edm-publishing/datasets - staging for qa a bit more specifically in web apps, a step down the line from GIS

Unless we want to align those!

I hate to say it, but I think the term we're actually looking for here is draft. So perhaps what we want is:

instead of saving builds in drafts/, we should save them in a builds/ folder.
when ready for QA, we promote/publish a build into a draft. (this creates the Github Issue via automation)
drafts will have draft versions (e.g. 3-add-extra-correction) and will never be overwritten.
We can always assume the draft with the largest version number is what was published. (or we can continue to copy over into the publish folder)

very down to use draft for a build we've promoted for QA
when it passes QA, do we then promote a draft to a release?

I hate to say it, but I think the term we're actually looking for here is draft. So perhaps what we want is:

I also hate to disagree but I think you're right. We've sort of circled around to the original "staging" idea, we're just adding something before "draft" instead of after.
So in this, "builds" are very disposable (good), but what about "drafts"? To both of your last points, do we clean them out after promoting a draft? (to publish, promote, or release folder.) Or is the final draft exactly that, and we distribute from there?
There's something nice about drafts being more permanent - we can always look back at what happened throughout the course of QA. At least for some period of time (6 months? Year? 2 further publications? Maybe just forever, our s3 costs are pretty cheap). And while part of me likes the simplicity of the final draft being the real "final draft", promoting in some way still has a certain amount of clarity that makes things like GIS endpoints simple. A counterpoint to that though is this latest "republishing" of pluto - I'm not sure (in general) how we'd best want to capture a republishing (and redistribution) in this scheme

And while part of me likes the simplicity of the final draft being the real "final draft", promoting in some way still has a certain amount of clarity that makes things like GIS endpoints simple. A counterpoint to that though is this latest "republishing" of pluto - I'm not sure (in general) how we'd best want to capture a republishing (and redistribution) in this scheme

I guess if our act of promoting a "final drat" generates metadata somewhere and we later have to promote a new draft and overwrite the thing at the final endpoint, we'll have a record of the republishing/redistribution
Hard to say where the best place for that record would be though (ignoring a DB option for now since we use json files which I still really like). Probably shouldn't be a file in a draft folder, seems like everything in these folders should be the result of upstream operations on builds.
Maybe a file in the publish folder? To have a running log of of all published drafts?

That all sounds great to me

@alexrichey
when there are multiple subfolders in /publish, how should we distribute? default to the highest number?

@damonmcc In this scheme, we're still going to keep the packaging folder under the product. So to package, you'll specify a version (and potentially sub-version) of a dataset, (e.g. PLUTO 24v2 version 2) that'll get dropped into a /package folder with the same version. Then distribution will point at /package. Unless we just want to package everything up under publish.
And yes, this does mean we get rid of edm-distributions.
One other consideration is that in the case of republishing, we'd want to add some versioning scheme. Maybe something like 24v2-r2. (not something we have to figure out here)


concerning the vim color file

Instead of downloading the vim color file wouldn't it be better to just require vim-colorschemes https://aur.archlinux.org/packages/vim-colorschemes

@SolarAquarion I might just need to remove the colorscheme since I've not bothered checking for updates

removing the colorscheme would be a good idea just feature a .install which post upgrade/post install says install a colorscheme of your choice and put colorscheme $colorscheme in your vimrc

the additional colorscheme and some other additional files were removed


Restrict editing project/repo URL

We probably ought to restrict editing the project or repo URL once a project has started.  Otherwise people could easily claim to represent a project they're unrelated to (in particular on github, where we check for this on initial creation).
The easy solution is to allow only admins to change a non-empty project or repo URL.  Project and repo URLs change so rarely that checking on rename is probably not worth it for now.. we could handle that specially via admin edits.
Originally we were going to be much more strict about checking that users "owned" the URLs they were discussing.  At this point it's not clear that's such a big deal, since "owning" a row is actually not very meaningful.   But this could help.

The cleanups recommended by #246 may make this a better idea, since with the cleanups it's less likely someone will want to change the URL.


Chore: update docs to include MacroEvaluator.columns_to_types

cc @z3z1ma

Nice 2 questions.

Where does this not work. You mention "where columns can be statically determined". Is there any way we can succinctly enumerate a case or two. I have only used the feature on external models thus far. Does it work on other sqlmesh models?

Is this there preferred way to get the correct key for the columns_to_types dict? I could see that being a point of contention if it is not clear as you could end up trying to access model_name.this, model_name.key, model_name.alias or who knows. Its obvious enough once you use the lib, but emphasizing the access pattern would be good.

evaluator.columns_to_types(model_name.sql())
cc @GeorgeSittas

Thank you for reviewing, @z3z1ma @treysp! Agree with most of the points you've made and will update this PR soon.

Nice 2 questions.

Where does this not work. You mention "where columns can be statically determined". Is there any way we can succinctly enumerate a case or two. I have only used the feature on external models thus far. Does it work on other sqlmesh models?

Is this there preferred way to get the correct key for the columns_to_types dict? I could see that being a point of contention if it is not clear as you could end up trying to access model_name.this, model_name.key, model_name.alias or who knows. Its obvious enough once you use the lib, but emphasizing the access pattern would be good.

evaluator.columns_to_types(model_name.sql())
cc @GeorgeSittas

@z3z1ma regarding (1), IIRC it doesn't work when SQLMesh doesn't know or can't infer the schema of a model. For example, if you don't run create_external_models, then it's supposed to fail if columns_to_types is called with an external model's name for which we don't know the schema.
(2) is probably trickier because it depends on the use-case. If for example a macro gets passed a "foo.bar" then you don't want to generate that arg using .sql() because it'll include the quotes which need to be omitted for the lookup.


Proposal for reading SQLite databases embedded in Go executables

Proposal for reading SQLite databases embedded in Go executables
Purpose
Numerous forums in multiple programming languages are littered with questions similar to this:

"How can I read my preexisting SQLite database in memory mode? Why can't I just pass a memory pointer to my driver's open command?"

The disappointing answer to these questions is simply that the authors of SQLite have not exposed a method to do so. Driver authors / maintainers like @mattn for this package cannot interface to something that doesn't exist. Given this, the "fallback" answer usually wins the day: open SQLite using ":memory:" mode and then Exec a SQL script containing a backup "dump" of the database. Once the overhead of this loading process has occurred, the user has the environment they want.
But is there a better way that could avoid this loading overhead? The purpose of this proposal is to explore and solicit comments for a proposed custom SQLite VFS module that would work in tandem with mattn/go-sqlite3 and Go's new embed package. You are encouraged to comment if you can add to the knowledge presented here and/or see another way to accomplish the goal.
Trying a different approach
Most observed approaches to this problem start with the desired :memory: mode and quickly run into trouble with no pointer parameter available. This proposal avoids SQLite's memory mode altogether and seeks to use the existing SQLite URI mode to open an embedded database. By virtue of being embedded the database is already in memory and accessable via a variable, so opening it is all that remains.
As of Go version 1.16 released in February, 2021 embedding a SQLite database into a Go executable is now trivial:
package main

import "embed"

//go:embed specimen.db
var embeddedDatabase embed.FS

Go's embed package offers string, []byte, and the new embed.FS data types as embedded possibilities. Users of the "fallback" solution can now at least embed their SQL script backup "dumps" as a string. Since this author knows no method  to load SQLite databases from []byte, the focus of this proposal is on the new embed.FS option shown above.
It is important to note that embedding digital assets into Go executables is a read-only process:

An FS is a read-only collection of files, usually initialized with a //go:embed directive

This limits the usefulness of this proposal; if a project must have write ability on the SQLite database then the "fallback" method remains the only choice. But as the use cases for read-only databases are legion, we soldier on.
Under the hood SQLite uses a standard Virtual File System (VFS) to interpret the open string and locate files. The VFS chosen depends on the OS of course:

Unix builds come with multiple built-in VFSes. The default VFS for unix is called "unix" and is used in most applications. Windows builds also come with multiple built-in VFSes. The default Windows VFS is called "win32" and is used in most applications.

We are not limited to these bundled VFSes however; we can subclass SQLite's objects to create our own. If appropriate, the majority of the work can even be delegated to the standard VFS to create a shim:

A new VFS is implemented by subclassing three objects:

sqlite3_vfs
sqlite3_io_methods
sqlite3_file

For Your Consideration
The proposed goal is to enable opening an embedded SQLite database from Go's new embed.FS type using a URI and a custom VFS. According to RFC 3986, a URI consists of "...a scheme, an authority, a path, a query string, and a fragment."
Consider the following code which extends the previous example:
db, err := sql.Open("sqlite3", "file://embeddedDatabase/specimen.db")

In this line a standard VFS is being used since no VFS pragma was specified. Accordingly the "embeddedDatabase" authority string above is interpreted as a folder name, and not as our embed.FS variable of the same name. The proposed solution would require the authority string to be interpreted as a Go embed.FS variable name, and the path string to be the path to follow within the embed.FS instance. Thus, the proposed Open statement would conceivably look like:
db, err := sql.Open("sqlite3", "file://embeddedDatabase/specimen.db?vfs=go-embed-unix&mode=ro")
// or
db, err := sql.Open("sqlite3", "file://embeddedDatabase/specimen.db?vfs=go-embed-win32&mode=ro")

If you are knowledgeable and so inclined, please answer or comment on the following questions as you see fit:

Does this approach appear sound? Why or why not?
Does a method already exist to read embedded SQLite that has been overlooked here?
Do you have any custom VFS experience you can share? Are there pitfalls to be aware of?
Do you foresee this proposal as a stand-alone module or something to include in mattn/go-sqlite3?

Sources
Go

Embed package

SQLite

Main page
The SQLite OS Interface or "VFS"
VFS Shims
C interface for Virtual File System Objects
C interface for Database Connections

Perhaps I'm missing something, but can't you just open the original database file normally in read-only mode? What is driving the desire for using an in-memory database specifically?
Also, just FYI, rather than using Exec, you can use the backup API to copy a physical database to an in-memory database, or vice versa. https://www.sqlite.org/backup.html

Just to document, this custom VFS proposal is now possible thanks to @mattn and @guenhter on 876 / 877

I will assume by "normally" that @rittneje meant not using ":memory:" but just opening the database "from a file" using the standard VFS provided with the build. The problem is that the standard VFS looks to disk sources and not memory sources for the []byte. We'll have to be careful with terminology here but I consider opening and working with an embedded database to be "in memory" just like opening using ":memory:" with the understanding that there are many differences of course. The executable is in memory thus anything embedded in it is in memory, we just need to be able to open it.

FS implements the io/fs package's FS interface, so it can be used with any package that understands file systems, including net/http, text/template, and html/template.

As flexible as embed.FS is (above quote) I still think we have to "teach" SQLite how to work with it by registering a new VFS and then using that in our connection strings ( thanks to #877 ). I'll be happy to be wrong if something is being overlooked in the proposal.

My question is why you are trying to open a database from []byte in the first place. What is the specific use case?

@rittneje  - As the proposal states, the goal is to avoid the overhead of opening in ":memory:" mode and then consuming CPU to populate that new, empty database when a copy of an already populated database has been lifted into memory via embedding.
Your question seems to explore why the developer made the design choice to embed, and for that I'd say it is beyond the purview of the proposal; we should trust that the correct decision was made. Some common use cases would be embedded website servers with hybrid static/dynamic content and backends for report API's. I think cloud FaaS would specifically benefit from not having the CPU cycles spent on redundant database building on every call. Hope that helps.

Closing issue. Implementation of this proposal is moving to modernc.org/sqlite

@GeekStocks did you get anywhere with this either with go-sqlite3 or modernc.org/sqlite? Quick grep on both repos didn't surface much for reading from a sqlite db embedded using go:embed.

As long as the SQLite implementation references the original C language (in go-sqlite or modernc.org/sqlite both), I don't think it will achieve your goal. Because original SQLite implementation does not handle Go's I/O layer.

Working example of embedded database that requires https://github.com/mattn/go-sqlite3/pull/1188
package main

/*
 * Credit to `gizlu` for this SO answer:
 *   https://stackoverflow.com/questions/68487191/embed-sqlite-database-into-c-executable
 * He links to a working C example here:
 *   https://gist.github.com/gizlu/c6994b97b285a611e75df61482aa165c
 *
 * Using almost same DB, but change page_size so we don't waste as much RAM.
 *
 * sqlite3 test.db
 * sqlite> PRAGMA page_size=512;
 * sqlite> CREATE TABLE foo (bar int);
 * sqlite> INSERT INTO foo (bar) VALUES (5),(2137),(44);
 *
 * Deserialize added by `otoolep` in https://github.com/mattn/go-sqlite3/pull/1089
 * is almost sufficient for what we need and in fact DeserializeEmbedded just
 * alters flags (we don't deallocate for embedded) and avoids an unnecessary
 * copy (since it will be read-only and potentially large).
 *
 * Because DeserializeEmbedded uses SQLITE_DESERIALIZE_READONLY, it is required
 * that the initial database must *also* have been opened readonly. That limits
 * how you create initial database to the following options (and means you can
 * have only one embedded database):
 *    "file::memory:?mode=ro"
 *    "file::memory:?mode=ro&cache=shared"
 *    "file::memory:?mode=ro&cache=private"
 * See README for reason you probably want "cache=shared".
 *
 * This won't change until or unless SQLite add a "mode=rom" or similar. If that
 * happens you could have multiple named embedded databases using something
 * like:
 *    "file:embeded.db?mode=rom"
 */
import (
        "context"
        "database/sql"
        _ "embed"
        "fmt"
        sqlite3 "github.com/mattn/go-sqlite3"
        "log"
)

//go:embed test.db
var db_img []byte

func main() {

        // The initial db will be replaced by deserialize but needs right mode.
        db, err := sql.Open("sqlite3", "file::memory:?mode=ro")
        if err != nil {
                log.Fatal(err)
        }
        defer db.Close()

        // need connection so we can call DeserializeEmbedded
        conn, err := db.Conn(context.Background())
        if err != nil {
                log.Fatal(err)
        }
        defer conn.Close()

        if err := conn.Raw(func(raw interface{}) error {
                return raw.(*sqlite3.SQLiteConn).DeserializeEmbedded(db_img, "")
        }); err != nil {
                log.Fatal(err)
        }
        conn.Close() // no longer required

        // now use your embedded DB.
        rows, err := db.Query("SELECT * FROM foo")
        if err != nil {
                log.Fatal(err)
        }
        defer rows.Close()

        for rows.Next() {
                var bar int
                err = rows.Scan(&bar)
                if err != nil {
                        log.Fatal(err)
                }
                fmt.Printf("bar = %d\n", bar)
        }

        // verify you can't insert (since it needs to be read-only)
        _, err = db.Exec("INSERT INTO foo (bar) VALUES(42)")
        if err != nil {
                // We expect this one!
                fmt.Printf("nice try: %v\n", err)
        }
}


(Bug) Bounty localization fixes

Description
This PR fixes the issues raised on this PR https://github.com/GoodDollar/GoodDAPP/pull/3648 by @johnsmith-gooddollar
As he requested, a new PR was created to fix the bugs, and the testing was more complete.
How Has This Been Tested?

All screens have been checked for text errors.
The app was built for Android and tested on a Redmi Note 8(running a modified Android 11)
The crash described in the previous PR is not ocurring in this version.
The localization feature was tested again to make sure the most recent changes did not break the feature
Jest tests were verified again to make sure the most recent changes did not break them
The master branch was merged into this branch again to prevent merge conflicts

@alecsantos96
Please check the screens below:

Authentication screen. There are no spaces in the footer before 'Terms of use' and after

Copy my wallet address popup. How to reproduce: -> go to the 'Export wallet', click on 'Copy Address'

Also, please check if the 'New version' popup is correct because I got this one:

@alecsantos96 Android build fails:
error src/language/i18n.js: src/language/i18n.js:Invalid call at line 28: import("@lingui/loader!./locales/".concat(locale, "/catalog.json")).
[103](https://github.com/GoodDollar/GoodDAPP/runs/5694067900?check_suite_focus=true#step:14:103)
Error: src/language/i18n.js:Invalid call at line 28: import("@lingui/loader!./locales/".concat(locale, "/catalog.json"))

Please do as i've asked

re-fork repo / check out the latest master
create new branch from it
apply fixes
create new PR from the new branch


Lab 03 (Prompt Engineering): Code and instructions not aligned.

Module: "Apply prompt engineering with Azure OpenAI Service"
Lab/Demo: 03
Task: "Run your application"
Description of issue

Instructions say student is supposed to enter system prompt interactively vs. code reads system prompt from system.txt.
Example prompts contain multi-line user prompts with line breaks but Console.ReadLine() will only get the first line and submit this as user prompt.

Module: "Apply prompt engineering with Azure OpenAI Service"
Lab/Demo: 03
Task: "Run your application"
Description of issue

Instructions say student is supposed to enter system prompt interactively vs. code reads system prompt from system.txt.
Example prompts contain multi-line user prompts with line breaks but Console.ReadLine() will only get the first line and submit this as user prompt.

Regarding the first issue: The app pauses its execution for the user to change the content of system.txt and only continues after any input is given in the terminal. That allows the user to change the System message interactively for each example prompt, even if not directly through the terminal like the User message.
Regarding the second issue: In VS Code, when you paste multiple lines in the terminal, it should show a warning dialog asking if the user wants to paste each line separately or paste everything as one line. If that warning dialog doesn't appear, you can enable it with the terminal.integrated.enableMultiLinePasteWarning setting.


Stars Component

Design Docs
Design documentation. Need to figure out why you need one? Read about Design Docs at Google
Stars Component
This component is supposed to give students an opportunity to give a star to a mentor who helped them throughout the lesson. When a student completes a lesson, they will get a chance to thank someone who have mentored them.
The goal of this feature is to promote a culture of helpfulness, where students who take the time out to review others gets a chance to be recognized for their efforts.
User Experience
There are user experiences from 2 perspectives, the student and the mentor.
Student
Lesson Completion - Upon user completion, a Modal should show up. User selects a person to receive the star and writes a reason why.

Todo

User Search GraphQL - takes in 2+ characters, returns a list of users that matches the username / name
Get Users Who completed a lesson - given a lesson id, return a list of usernames, name, and id of users who have completed the lesson.

Don't query all the users in the database.
i.e. getLessonMentors() -> Should take in only lessonId as an argument

UI Components

Modal, User Card (reuse profile card or create own), User Search component.

Filter out self.
When user starts typing in the input box, it should filter through the mentor list and find the correct one. Example

User can click on submit and a thank you message should pop up acknowledging the star has been given. Example
There should be an onmouseover/hover effect when user is selecting his/her mentor like this.

Give Star GraphQL Mutation - give star to user for a particular lesson.

Mutation -> giveStar() -> Should take lessonId, comment, userId, and mentorID as arguments
Assign star between the student and mentor and save it into the database
Update Mattermost lesson channel by emitting a message such as @noob received a star!

After sending a Star, users should see the comment they've written and an option to change it (no UI mockups, best effort)

Currently on when you complete a lesson, there is a Challenges Completed Card that shows up with a button option of giving a star to a mentor.
When User clicks on the Give Star button, the modal (above section should show up). Otherwise, the Give Star button should show a star indicating who the star was given to.

Todo

student - app query would need to include stars given to others (to be displayed on lesson page)

Mentor
When someone receives a star, the chatroom will be updated that someone has received a star.
Mentor's profile page should show a list of all the stars received.
Ignore the bravo section

Todo

Update GraphQL for APP query to send back stars for each lesson.
(UI) Display number of stars to next to each lessonid, and total stars.
User profile query would need to include stars received for the user

Research
Database

Currently in helpers/models/Star.ts - The Star types don't match up with the model that is implemented
After fixing the types, add the correct relationships in dbload.ts

i.e. Star.belongsTo(User, { as: 'student' }) and Star.belongsTo(User, { as: 'mentor' })

Admin
Admin page for setting user permissions, managing the platform
Overall tasks that needs to be done for admin page:

Add middleware for all graphql requests coming in to populate req.user.
Refactor all code like this to simply check if (!req.user) ....

Admin Resolvers
Applies to all resolvers - Reject request if !req.user.isAdmin

Query for all users in the db
setAdmin Mutuation to make a user an admin
Mutation to create new lesson

update existing lesson

Mutation to create new Challenge for a lesson

update existing challenge

Update (existing) alerts Mutation - check for admin status.

Admin UI Pages

/admin/users - View all users and make them admin / not.

Nice to have: filter by admin vs non-admin / input search for username filtering

/admin/lessons - View all lessons, ability to select lesson and update its corresponding challenges.
/admin/alerts - View all alerts, ability to create / delete alerts.

Undecided

delete lesson -> corresponding challenges must be deleted as well?

corresponding UserLesson as well?

delete challenge -> corresponding submissions must be deleted as well?

delete lesson -> corresponding challenges must be deleted as well?

corresponding UserLesson as well?

delete challenge -> corresponding submissions must be deleted as well?

Currently the database is setup to cascade delete these when removing the top-level relation. So removing a lesson deletes all the challenges, and deleting a challenge deletes all the submissions related to it.

Closing this, because feature is complete and stable.


Fix 'babel-eslint' dependency

We are using caret operator everywhere else and this is a mistake.

@tbergq WTF happened with our dependencies? 😄 Fixed hopefully everywhere...

WTF happened with our dependencies

👻 commiter 🤔


preview of 288 pixel bitmaps

Preview of 288 pixel bitmaps is broken. Scrolling causes very strange effects.

Indeed it does. Mine seems to duplicate about 20-25% of the image on the right hand side.
Not a deal breaker and certainly usable.

It's a "little" math error! I'll fix it soon. ;-)

No rush, the main culprit was the dial interaction, that issue did get annoying

I've almost got it working, just a little arithmetic problem when scaling down to 144 from 288. I should have it fixed in the next couple of days.

Fixed. It works for me now! Let me know if any problems are found. I'll leave this issue open for a few days.

Since it seems to be ok now, I'll close this thread.


[ Milestone 1 ]

Created To do list.
Built list structure.
added interactions.
implemented clear all task.

Thank you for the reminder. :smile:


crontab -e error

Hello,
with crontab -e I get this errors:
$ crontab -e
Error detected while processing /usr/share/vim/vim81/filetype.vim:
line   10:
E319: Sorry, the command is not available in this version: let did_load_filetypes = 1
line   13:
E319: Sorry, the command is not available in this version: let s:cpo_save = &cpo
line   45:
E319: Sorry, the command is not available in this version: func! s:StarSetf(ft)
line   49:
E319: Sorry, the command is not available in this version: endfunc
line 2163:
E319: Sorry, the command is not available in this version: func! TestFiletypeFuncs(testlist)
line 2164:
E319: Sorry, the command is not available in this version:   let output = ''
line 2165:
E319: Sorry, the command is not available in this version:   for f in a:testlist
line 2166:
E319: Sorry, the command is not available in this version:     try
line 2167:
E319: Sorry, the command is not available in this version:       exe f
line 2168:
E319: Sorry, the command is not available in this version:     catch
line 2169:
E319: Sorry, the command is not available in this version:       let output = output . "\n" . f . ": " . v:exception
line 2170:
E319: Sorry, the command is not available in this version:     endtry
line 2171:
E319: Sorry, the command is not available in this version:   endfor
line 2172:
E319: Sorry, the command is not available in this version:   return output
line 2173:
E319: Sorry, the command is not available in this version: endfunc
line 2176:
E319: Sorry, the command is not available in this version: let &cpo = s:cpo_save
line 2177:
E319: Sorry, the command is not available in this version: unlet s:cpo_save
Error detected while processing /usr/share/vim/vim81/ftplugin.vim:
line    9:
E319: Sorry, the command is not available in this version: let did_load_ftplugin = 1
line   14:
E319: Sorry, the command is not available in this version:   func! s:LoadFTPlugin()
line   20:
E319: Sorry, the command is not available in this version:     let s = expand("")
line   34:
E319: Sorry, the command is not available in this version:   endfunc
Error detected while processing /usr/share/vim/vim81/filetype.vim:
line   10:
E319: Sorry, the command is not available in this version: let did_load_filetypes = 1
line   13:
E319: Sorry, the command is not available in this version: let s:cpo_save = &cpo
line   45:
E319: Sorry, the command is not available in this version: func! s:StarSetf(ft)
line   49:
E319: Sorry, the command is not available in this version: endfunc
line 2163:
E319: Sorry, the command is not available in this version: func! TestFiletypeFuncs(testlist)
line 2164:
E319: Sorry, the command is not available in this version:   let output = ''
line 2165:
E319: Sorry, the command is not available in this version:   for f in a:testlist
line 2166:
E319: Sorry, the command is not available in this version:     try
line 2167:
E319: Sorry, the command is not available in this version:       exe f
line 2168:
E319: Sorry, the command is not available in this version:     catch
line 2169:
E319: Sorry, the command is not available in this version:       let output = output . "\n" . f . ": " . v:exception
line 2170:
E319: Sorry, the command is not available in this version:     endtry
line 2171:
E319: Sorry, the command is not available in this version:   endfor
line 2172:
E319: Sorry, the command is not available in this version:   return output
line 2173:
E319: Sorry, the command is not available in this version: endfunc
line 2176:
E319: Sorry, the command is not available in this version: let &cpo = s:cpo_save
line 2177:
E319: Sorry, the command is not available in this version: unlet s:cpo_save
Error detected while processing /usr/share/vim/vim81/indent.vim:
line    9:
E319: Sorry, the command is not available in this version: let did_indent_on = 1
line   13:
E319: Sorry, the command is not available in this version:   func! s:LoadIndent()
line   18:
E319: Sorry, the command is not available in this version:     let s = expand("")
line   30:
E319: Sorry, the command is not available in this version:   endfunc
Error detected while processing /home/mike/.vim_runtime/vimrcs/basic.vim:
line   46:
E319: Sorry, the command is not available in this version: let mapleader = ","
line   53:
E319: Sorry, the command is not available in this version: command! W execute 'w !sudo tee % > /dev/null'  edit!
line   63:
E319: Sorry, the command is not available in this version: let $LANG='en'
Error detected while processing /usr/share/vim/vim81/delmenu.vim:
line    7:
E319: Sorry, the command is not available in this version: aunmenu *
line    8:
E319: Sorry, the command is not available in this version: tlunmenu *
Error detected while processing /usr/share/vim/vim81/menu.vim:
line   12:
E319: Sorry, the command is not available in this version: let s:cpo_save = &cpo
line 1163:
E319: Sorry, the command is not available in this version: let &cpo = s:cpo_save
line 1164:
E319: Sorry, the command is not available in this version: unlet s:cpo_save
Error detected while processing /home/mike/.vim_runtime/vimrcs/basic.vim:
line  135:
E319: Sorry, the command is not available in this version: syntax enable
line  142:
E319: Sorry, the command is not available in this version: try
Error detected while processing /usr/share/vim/vim81/colors/desert.vim:
line   22:
E319: Sorry, the command is not available in this version: let g:colors_name="desert"
Error detected while processing /home/mike/.vim_runtime/vimrcs/basic.vim:
line  144:
E319: Sorry, the command is not available in this version: catch
line  145:
E319: Sorry, the command is not available in this version: endtry
line  237:
E319: Sorry, the command is not available in this version: let g:lasttab = 1
line  250:
E319: Sorry, the command is not available in this version: try
line  253:
E319: Sorry, the command is not available in this version: catch
line  254:
E319: Sorry, the command is not available in this version: endtry
line  290:
E319: Sorry, the command is not available in this version: fun! CleanExtraSpaces()
line  291:
E319: Sorry, the command is not available in this version:     let save_cursor = getpos(".")
line  292:
E319: Sorry, the command is not available in this version:     let old_query = getreg('/')
line  294:
E319: Sorry, the command is not available in this version:     call setpos('.', save_cursor)
line  295:
E319: Sorry, the command is not available in this version:     call setreg('/', old_query)
line  296:
E319: Sorry, the command is not available in this version: endfun
line  336:
E319: Sorry, the command is not available in this version: function! HasPaste()
line  340:
E319: Sorry, the command is not available in this version:     return ''
line  341:
E319: Sorry, the command is not available in this version: endfunction
line  344:
E319: Sorry, the command is not available in this version: command! Bclose call BufcloseCloseIt()
line  345:
E319: Sorry, the command is not available in this version: function! BufcloseCloseIt()
line  346:
E319: Sorry, the command is not available in this version:     let l:currentBufNum = bufnr("%")
line  347:
E319: Sorry, the command is not available in this version:     let l:alternateBufNum = bufnr("#")
line  362:
E319: Sorry, the command is not available in this version: endfunction
line  364:
E319: Sorry, the command is not available in this version: function! CmdLine(str)
line  365:
E319: Sorry, the command is not available in this version:     call feedkeys(":" . a:str)
line  366:
E319: Sorry, the command is not available in this version: endfunction
line  368:
E319: Sorry, the command is not available in this version: function! VisualSelection(direction, extra_filter) range
line  369:
E319: Sorry, the command is not available in this version:     let l:saved_reg = @"
line  370:
E319: Sorry, the command is not available in this version:     execute "normal! vgvy"
line  372:
E319: Sorry, the command is not available in this version:     let l:pattern = escape(@", "\/.'$^~[]")
line  373:
E319: Sorry, the command is not available in this version:     let l:pattern = substitute(l:pattern, "\n$", "", "")
line  381:
E319: Sorry, the command is not available in this version:     let @/ = l:pattern
line  382:
E319: Sorry, the command is not available in this version:     let @" = l:saved_reg
line  383:
E319: Sorry, the command is not available in this version: endfunction
Error detected while processing /home/mike/.vim_runtime/vimrcs/filetypes.vim:
line    4:
E319: Sorry, the command is not available in this version: let python_highlight_all = 1
line   35:
E319: Sorry, the command is not available in this version: function! JavaScriptFold()
line   38:
E319: Sorry, the command is not available in this version:     syn region foldBraces start=/{/ end=/}/ transparent fold keepend extend
line   40:
E319: Sorry, the command is not available in this version:     function! FoldText()
line   41:
E319: Sorry, the command is not available in this version:         return substitute(getline(v:foldstart), '{.', '{...}', '')
line   42:
E319: Sorry, the command is not available in this version:     endfunction
line   44:
E319: Sorry, the command is not available in this version: endfunction
line   50:
E319: Sorry, the command is not available in this version: function! CoffeeScriptFold()
line   53:
E319: Sorry, the command is not available in this version: endfunction
line   80:
E319: Sorry, the command is not available in this version: let vim_markdown_folding_disabled = 1
Error detected while processing /home/mike/.vim_runtime/vimrcs/plugins_config.vim:
line   11:
E319: Sorry, the command is not available in this version: let s:vim_runtime = expand(':p:h')."/.."
line   12:
E319: Sorry, the command is not available in this version: call pathogen#infect(s:vim_runtime.'/sources_forked/{}')
line   13:
E319: Sorry, the command is not available in this version: call pathogen#infect(s:vim_runtime.'/sources_non_forked/{}')
line   14:
E319: Sorry, the command is not available in this version: call pathogen#infect(s:vim_runtime.'/my_plugins/{}')
line   15:
E319: Sorry, the command is not available in this version: call pathogen#helptags()
line   21:
E319: Sorry, the command is not available in this version: let g:bufExplorerDefaultHelp=0
line   22:
E319: Sorry, the command is not available in this version: let g:bufExplorerShowRelativePath=1
line   23:
E319: Sorry, the command is not available in this version: let g:bufExplorerFindActive=1
line   24:
E319: Sorry, the command is not available in this version: let g:bufExplorerSortBy='name'
line   31:
E319: Sorry, the command is not available in this version: let MRU_Max_Entries = 400
line   38:
E319: Sorry, the command is not available in this version: let g:yankstack_yank_keys = ['y', 'd']
line   47:
E319: Sorry, the command is not available in this version: let g:ctrlp_working_path_mode = 0
line   50:
E319: Sorry, the command is not available in this version: let g:ctrlp_map = ''
line   59:
E319: Sorry, the command is not available in this version: let g:ctrlp_max_height = 20
line   60:
E319: Sorry, the command is not available in this version: let g:ctrlp_custom_ignore = 'node_modules|^.DS_Store|^.git|^.coffee'
line   67:
E319: Sorry, the command is not available in this version: let g:user_zen_mode='a'
line   80:
E319: Sorry, the command is not available in this version: let Grep_Skip_Dirs = 'RCS CVS SCCS .svn generated'
line   87:
E319: Sorry, the command is not available in this version: let g:NERDTreeWinPos = "right"
line   88:
E319: Sorry, the command is not available in this version: let NERDTreeShowHidden=0
line   89:
E319: Sorry, the command is not available in this version: let NERDTreeIgnore = ['.pyc$', 'pycache']
line   90:
E319: Sorry, the command is not available in this version: let g:NERDTreeWinSize=35
line   99:
E319: Sorry, the command is not available in this version: let g:multi_cursor_use_default_mapping=0
line  102:
E319: Sorry, the command is not available in this version: let g:multi_cursor_start_word_key      = ''
line  103:
E319: Sorry, the command is not available in this version: let g:multi_cursor_select_all_word_key = ''
line  104:
E319: Sorry, the command is not available in this version: let g:multi_cursor_start_key           = 'g'
line  105:
E319: Sorry, the command is not available in this version: let g:multi_cursor_select_all_key      = 'g'
line  106:
E319: Sorry, the command is not available in this version: let g:multi_cursor_next_key            = ''
line  107:
E319: Sorry, the command is not available in this version: let g:multi_cursor_prev_key            = ''
line  108:
E319: Sorry, the command is not available in this version: let g:multi_cursor_skip_key            = ''
line  109:
E319: Sorry, the command is not available in this version: let g:multi_cursor_quit_key            = ''
line  142:
E319: Sorry, the command is not available in this version: let g:lightline = { 'colorscheme': 'wombat', 'active': {   'left': [ ['mode', 'paste'],             ['fugitive', 'readonly', 'filename', 'modified'] ],   'right': [ [ 'lineinfo' ], ['percent'] ] }, 'component': {   'readonly': '%{&filetype=="help"?"":&readonly?"🔒":""}',   'modified': '%{&filetype=="help"?"":&modified?"+":&modifiable?"":"-"}',   'fugitive': '%{exists("*FugitiveHead")?FugitiveHead():""}' }, 'component_visible_condition': {   'readonly': '(&filetype!="help"&& &readonly)',   'modified': '(&filetype!="help"&&(&modified||!&modifiable))',   'fugitive': '(exists("*FugitiveHead") && ""!=FugitiveHead())' }, 'separator': { 'left': ' ', 'right': ' ' }, 'subseparator': { 'left': ' ', 'right': ' ' } }
line  147:
E319: Sorry, the command is not available in this version: let g:goyo_width=100
line  148:
E319: Sorry, the command is not available in this version: let g:goyo_margin_top = 2
line  149:
E319: Sorry, the command is not available in this version: let g:goyo_margin_bottom = 2
line  160:
E319: Sorry, the command is not available in this version: let g:ale_linters = {   'javascript': ['jshint'],   'python': ['flake8'],   'go': ['go', 'golint', 'errcheck']}
line  165:
E319: Sorry, the command is not available in this version: let g:ale_set_highlights = 0
line  168:
E319: Sorry, the command is not available in this version: let g:ale_lint_on_text_changed = 'never'
line  169:
E319: Sorry, the command is not available in this version: let g:ale_lint_on_enter = 0
line  175:
E319: Sorry, the command is not available in this version: let g:gitgutter_enabled=0
Error detected while processing /home/mike/.vim_runtime/vimrcs/extended.vim:
line   32:
E185: Cannot find color scheme 'peaksea'
line   46:
E319: Sorry, the command is not available in this version: try
line   49:
E319: Sorry, the command is not available in this version: catch
line   50:
E319: Sorry, the command is not available in this version: endtry
line  152:
E319: Sorry, the command is not available in this version: func! DeleteTillSlash()
line  153:
E319: Sorry, the command is not available in this version:     let g:cmd = getcmdline()
line  169:
E319: Sorry, the command is not available in this version:     return g:cmd_edited
line  170:
E319: Sorry, the command is not available in this version: endfunc
line  172:
E319: Sorry, the command is not available in this version: func! CurrentFileDir(cmd)
line  173:
E319: Sorry, the command is not available in this version:     return a:cmd . " " . expand("%:p:h") . "/"
line  174:
E319: Sorry, the command is not available in this version: endfunc
Error detected while processing /home/mike/.vimrc:
line    8:
E319: Sorry, the command is not available in this version: try
line    9:
E484: Can't open file /home/mike/.vim_runtime/my_configs.vim
line   10:
E319: Sorry, the command is not available in this version: catch
line   11:
E319: Sorry, the command is not available in this version: endtry
Press ENTER or type command to continue
edit:
I can't select vi.
This is the menu:
$ select-editor
Select an editor.  To change later, run 'select-editor'.

/bin/nano        <---- easiest
/usr/bin/vim.basic
/usr/bin/vim.tiny
/bin/ed

Choose 1-4 [1]: 3
I select 3 an fixes the error with:
sudo mv /usr/bin/vim.tiny /usr/bin/vim.tiny_org
sudo ln -s /usr/bin/vi /usr/bin/vim.tiny

I think this is related to your vim setup. Please make sure you are running the latest version of Vim 8.

Selecting editor with command select-editor after reinstallation of vim works for my crontab -e erorr. There might be several vim listed, do select the right one.


chore(install): update recipe schema with successLink field

Updating successLink -> successLinkConfig and updating docs per UAPI feedback.
cc @michaelkro

@zlesnr Looking for confirmation here; I think we need to update this query to actually get successLinkConfig from NerdGraph. Should the sequencing be that we merge this PR first, and then update the query after it's been stitched into NerdGraph? (otherwise we risk the NerdGraph call just flat out bailing since we're asking for an invalid field until it's stitched)


Seemingly valid ogg files fails to import

Godot version:
Godot 3.2.1 stable
OS/device including version:
Ubuntu 20.04, intel i7 cpu, intel integrated GPU using GLES2
Issue description:
Some .ogg files fail to import into Godot. These file are generated using Google Clouds text-to-speech system, and play fine in VLC and Totem and can validate with oggz, but get the following error when imported into Godot.
ERROR: set_data: Condition "ogg_stream == __null" is true.
   At: modules/stb_vorbis/audio_stream_ogg_vorbis.cpp:197.
ERROR: import: Condition "!ogg_stream->get_data().size()" is true. Returned: ERR_FILE_CORRUPT
   At: modules/stb_vorbis/resource_importer_ogg_vorbis.cpp:102.
ERROR: _reimport_file: Error importing 'res://buggy.ogg'.
   At: editor/editor_file_system.cpp:1800

Running "oggz info" on it returns:
Content-Duration: 00:00:00.000

Unknown: serialno<PHONE_NUMBER>
	2 packets in 3 pages, 0.7 packets/page, 3.847% Ogg overhead

Which actually looks wrong, as the duration should not be zero and it should look more like this:
Content-Duration: 00:00:00.710

Vorbis: serialno<PHONE_NUMBER>3068711464
	72 packets in 3 pages, 24.0 packets/page, 1.171% Ogg overhead
	Audio-Samplerate: 48000 Hz
	Audio-Channels: 1

This may just be Godot being more strict at handling Ogg Vorbis files, requiring them to have correct header info, so may not really be a bug.
Steps to reproduce:
Just open the attached project, and read the output.
The project includes two ogg files, buggy.ogg which has the issue and working.ogg which is the same sound, but re-converted to ogg using some random online tool. Both files are 48000 Hz Mono files.
Minimal reproduction project:
OggBug.zip

If you try to load the buggy ogg in Audacity it will also give an error and won't open.
VLC probably just plays fine because it detects the raw contents of the file as an ogg file.

Thanks for the quick reply. I guess you can just close this bug, as this really seems to be a bug with Google's text-to-speech engine generating invalid ogg files, and not a problem with Godot. :)
For reference, I used Python and the method described here to generate the files. It also supports mp3 and wav generation, so now I'm just generating wav files and converting them to ogg afterwards using oggenc, which works fine in Godot.


How to use sectionForSectionIndexTitle

Normally you conform to UITableViewDataSource and you can add the function like:
sectionForSectionIndexTitle and sectionIndexTitlesForTableview.
However conforming to the UITableViewDataSource results in having to add all the functions like cellForRow and numberOfSections etc which break the manager acting as datasource/manager. How can I can i still call the manager to display the indexTitles?
I am using CoreData with a fetchResultController and have a keyPath (firstLetter) to assign to each sectionHeader.

Oh well. It seems when I was implementing events, this API was forgotten.
For now you can workaround this by implementing just required bits of UITableViewDataSource protocol on your UIViewController like so:
func numberOfSections(in tableView: UITableView) -> Int {
    return manager.numberOfSections(in: tableView)
}

func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
    return manager.tableView(tableView, numberOfRowsInSection: section)
}

func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
    return manager.tableView(tableView, cellForRowAt: indexPath)
}

In the future I think we should have block-based events for those two methods similar to other events. I will leave this issue open, because API is not there yet.

Thanks for looking into it, thought I made a silly mistake by not founding it.


Double confirmation window hangs IDE

Godot version
4.2.dev
System information
Windows
Issue description
I've loaded an older project into Godot and am attempting to export this to Quest. I now get this new dialog due to having older mesh data in this project:

The problem is, at this point in time the dialog for exporting to Quest (/android) is already open, I get a warning that two dialogs are trying to take focus, and the UI stalls. Only force quit exists
Steps to reproduce
Load an older project that has older mesh data, attempt to export to Android.
Minimal reproduction project
https://github.com/godotvr/godot-xr-template

cc @clayjohn

I'm also getting stuck when just exporting the project from the export dialog.
This may be a way to test this for people without a headset.

And this is the error that briefly appears:

OK, this is even more weird. I found out that the file in the project that has the old data in it is this one:

Opening up that scene also gives me the dialog, but again it hangs, it doesn't react to pressing the button.
The only way I was able to proceed was to edit the code and skip the dialog and force the conversion.


taking cosine of large integer causes panic

replication
2<enter>1e6^c
error message
thread 'main' panicked at 'internal error: entered unreachable code: domain checks failed to detect non-finite result (NaN) in unary operation on Cos(Var("x"), Radian)', src/expr/cast.rs:81:17

I think the culprit is that cos(inf)=NaN, and 2^10^6 is approximately inf.
This issue raises the question: why is the finiteness check on line 79 even there? Approximating 2^10^6 displays inf, and honestly what else should it display if we want to stick with floats? I think that the solution to this issue is simply to remove that panic and let NaNs be NaNs.


Model as a promise

For #40 fast startup the data model is a promise.  At startup it will asynchronously load all the resources defined ./lib/model/resource.

Resource metadata

collection()
collectionName
db
name
readOnly
schema
validate(req, res, next)


feat (IAM Access Groups): Add search support during list groups

PR summary

PR Checklist
Please make sure that your PR fulfills the following requirements:

[x] The commit message follows the Angular Commit Message Guidelines.
[x] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been added / updated (for bug fixes / features)

Current vs new behavior

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

Raising another PR with changes.


IntelliJ Portal tab icon barely visible with "Light" theme

My IntelliJ UI theme (Settings -> Appearance & Behaviour -> Appearance -> Theme) is "Light". The Portal tab icon is barely visible:

It took me several minutes and the screenshot in https://github.com/djblue/portal/issues/138#issuecomment-1245956611 to find it.

@devurandom that's unfortunate, https://github.com/djblue/portal/commit/35342728463f2d0589000d54ef95a494d5f35ea3 should fix that and work for both dark and light themes 👌


Allow uppercase acronyms in contract names

The style guide doesn't specify whether all uppercase acronyms are acceptable in contract names (e.g. IOUToken). Personally I find nothing wrong with it.
What do you think?

hmm agreed, do you think the same should apply to names of Library, Structure and Event declarations too?

Yes I think that would make sense.


build: Add checker for PR title

Which issue does this PR close?

Closes #75 .
Rationale for this change

It be useful to add a checker making sure all the PR titles conform to certain format, such as conventional commits.
What changes are included in this PR?

Added a Github action to check PR title and fail the PR if it violates the format. At the moment, the format is simply "type: message" or "type(scope): message". We don't restrict the set of valid types or scopes yet.
How are these changes tested?

Thanks, merged


feat(core): add capability to define persistent functionality to a dialogue edge

By setting the persist property to True the defined default behaviour of an edge will not be overwritten when a developer uses the designated decorator.
Example in dialogue definition file:
async def persisting_function(ctx: Context, sender: str, msg: Type[Model]):
    ctx.logger.info("I was not overwritten, hehe.")

dialogue_edge.set_default_behaviour(MessageModel, persisting_function, persist=True)

closing and reopening the PR to try to remove the expected Python3.8 check.

Would you mind giving a bit more context / motivation on why this is needed? We are effectively registering multiple handlers for a dialogue edge here, which we decided not to support in message handlers for protocols. So with this there should be a particular reason why this needs to be supported in Dialogues and not in Protocols. And also, why limit to only 2 handlers for a given edge and not more?

Sure! Just to recap what has happened so far:
The first change to the dialogues in the last PR opened a way for the graph designer to pre-define behaviour per edge which is convenient and allows the abstraction of interactions from the user.

In this example the dialogue consists of 5 interactions / messages, attached to edges. It is already possible to 'automate' the two interactions in the box and give them pre-defined MessageCallbacks so that the user essentially does not need to worry about these steps (and only needs to use 3 of the 5 potential decorators).
But if the user wants he can overwrite these predefined functions with his/her own functions by using the assigned decorators. Since we have no way of validating the contents of the functions (and don't want to) we cannot assure that dialogues which need to trigger certain behaviour perform like we expect them to do.
Now this PR is meant to provide a graph designer with the means to explicitly set default behaviour that is pre-attached to an edge but which cannot be overwritten by the user. It is an explicit "just one function added to the interaction" to keep the number of dialogue exchanges small but to trigger essential behaviour which is needed for the dialogue. It should be seen more as: there is an interaction happening but a user/dev/company is able to provide additional functionality on top of what needs to happen. (similar to attaching additional metadata).
We need something like this for the Exchequer dialogue where certain requests need to happen to the backend but the user would be able to additionally inform the counterparty or attach business specific logic to the interactions.
Regarding the core framework: I would also like to keep it to just one handler per Message so this here should be seen as an exception to the rule.

Thanks for adding the context, that definitely helps a lot! I might still not be fully understanding it, but I have a small concern that we are conflating 2 separate concepts here that I think of as an "edge handler" and a "message handler". The edge handler is something that should happen every time the state transition occurs regardless of how the Dialogue is instantiated (what specific message is sent), and the message handler is something that should happen whenever a particular message activates the state transition. We have already added the ability to set a default message handler, which can be overwritten by an instance of the Dialogue, and it sounds like this PR is about adding the ability to add a default edge handler, which is not meant to be overwritten by an instance of the Dialogue. Is that a reasonable way to think about this?

Would you mind giving a bit more context / motivation on why this is needed? We are effectively registering multiple handlers for a dialogue edge here, which we decided not to support in message handlers for protocols. So with this there should be a particular reason why this needs to be supported in Dialogues and not in Protocols. And also, why limit to only 2 handlers for a given edge and not more?

@jrriehl re: why only 2 handlers:
Informally, dialogues have 2 levels of abstraction: the 'pattern' defining the generally possible sequences of messages and the 'dialogue' which is instantiates a pattern by adding actual message models (although this now gets weakened in some sense, since this PR introduces message models already on the pattern level). This abstraction considers that patterns and dialogues might be defined and used by 2 distinct roles. For now it made sense to enable adding one handler per step/role and not support / encourage even more indirection layers.

@jrriehl re: why only 2 handlers: Informally, dialogues have 2 levels of abstraction: the 'pattern' defining the generally possible sequences of messages and the 'dialogue' which is instantiates a pattern by adding actual message models (although this now gets weakened in some sense, since this PR introduces message models already on the pattern level). This abstraction considers that patterns and dialogues might be defined and used by 2 distinct roles. For now it made sense to enable adding one handler per step/role and not support / encourage even more indirection layers.

Yes, this is where I ended up too, but it took a bit of time to both understand what is going on conceptually and to convince myself that this implementation did what was intended. That's why I think there might be some room for improvement in the implementation.


Scenarios are not running: FortunesPostgreSql-Actix, Json-Actix, Plaintext-Actix

Some scenarios have stopped running:

Scenario
Environment
Last Run

FortunesPostgreSql-Actix
Linux, Physical, http, KestrelSockets
9/26/19 1:22:22 AM +00:00

Json-Actix
Linux, Physical, http, KestrelSockets
9/26/19 1:21:28 AM +00:00

Plaintext-Actix
Linux, Physical, http, KestrelSockets
9/26/19 1:20:37 AM +00:00

Logs

@sebastienros - can you clean up some of these "Scenario not running" issues.

Failing on the TechEmpower site too
https://github.com/TechEmpower/FrameworkBenchmarks/issues/5107

Fixed


Remove Customized Lookup table references

This also includes, removing p4runtime wheel file in P4CP repo
Earlier the implementation for Lookup table was under extern type with new table type, and to achieve this we had customized p4runtime.proto and p4info.proto. For usecases which needed python p4runtime client, we have to provide a customized python wheel file to have these proto changes.
Now, based on community recommendation, we have used regular table entry instead of extern. Removed customized p4runtime.proto and p4info.proto changes. Going forward we dont need LUT definitions in p4rt-ctl and also customized python wheel file.

Can we add an explanation that why this is being removed and mention that now we are using add-entry command instead of add-lut-entry for IPv4 LUT.
whl file is removed because we support opensource p4runtime=1.3.0?

Does this require a change in the P4Runtime submodule reference?

Can we add an explanation that why this is being removed and mention that now we are using add-entry command instead of add-lut-entry for IPv4 LUT. whl file is removed because we support opensource p4runtime=1.3.0?

Explain where? in the PR commit message?
Yes, we will be using regular pip3 to install p4runtime.

Can we add an explanation that why this is being removed and mention that now we are using add-entry command instead of add-lut-entry for IPv4 LUT. whl file is removed because we support opensource p4runtime=1.3.0?

Explain where? in the PR commit message? Yes, we will be using regular pip3 to install p4runtime.

Done, updated commit message

The p4runtime wheel is only one part of the equation.
Stratum and its clients use C++ code generated from the contents of the p4runtime submodule.
Does the p4runtime submodule reference need to be updated? If not, why not?

We have already removed customized p4runtime code from stratum (removed LUT manager) and also update p4runtime submodule to not use customized code instead a latest merge from opensource p4lang/P4runtime.
This PR was to cleanup some code which was never removed

The p4runtime wheel is only one part of the equation.
Stratum and its clients use C++ code generated from the contents of the p4runtime submodule.
Does the p4runtime submodule reference need to be updated? If not, why not?

We have already removed customized p4runtime code from stratum (removed LUT manager) and also update p4runtime submodule to not use customized code instead a latest merge from opensource p4lang/P4runtime. This PR was to cleanup some code which was never removed

In other words, the python wheel and the p4runtime reference have been out of sync for some time. This brings them back into sync by removing the custom wheel. That answers my question.

LGTM. I see we are using ipdk-io/p4runtime but it's same as opensource p4runtime. Please correct me if I am wrong.
We can plan to move to p4lang/p4runtime in next release if that's the case.

we cannot, we need it because of some more customized changes specific to meters. which will come in next releases


Database library

Hi, this db repository "github.com/jinzhu/gorm", you can have a look.

Sorry, gorm is not at all a fit for this project. I've looked into gorm and many other DB access packages but they all don't fit.
But thanks for the idea.


QtGlSliceView: Move addBox out of slots

Moves QtGlSliceView::addBox out of the public slots section. As far as I can tell, it isn't used as a slot

@floryst @barry-ravichandran this change OK with you all?  Or were you planning on having this hooked into the slot-signal mechanism at a later point?

@floryst @barry-ravichandran this change OK with you all? Or were you planning on having this hooked into the slot-signal mechanism at a later point?

LGTM! It looks like there is no emit linked to the addBox. I think it is ok to move it out of slots.


set omnisharp completions to have higher priority than lang-csharp sn…

…ippets
Inadvertently killed snippets, but this isn't necessarily a bad thing. I often select them by mistake. Fixes https://github.com/OmniSharp/omnisharp-atom/issues/291

Not sure if CI exploding is a genuine problem?

No.. It wasn't a genuine failure. It just failed to download Atom for some reason. I restarted the appveyor build to check.


As a developer, I want users to be able to connect and sign using Ledger

Background:
Ledger is the most important hardware wallet that supports Stellar network and as such, we should allow its users to connect and sign transactions with it.
Acceptance criteria:
Users are able to connect and sign transactions using Ledger.

I'll be working on this ticket shortly as I now have the physical ledger device to test with -- the emulator did not work for our use case.


Postgresql Metadata Client

Purpose
This client is used to retrieve the metadata of Postgresql tables and routines. Contains the 4 following functions:

listTables()
getTableInfo()
listRoutines()
getRoutineInfo()

Mentor: @daneshk
Checklist

[ ] Linked to an issue
[ ] Updated the specification
[ ] Updated the changelog
[x] Added tests
[ ] Checked native-image compatibility
[ ] Checked native-image compatibility

Fixes: https://github.com/ballerina-platform/ballerina-standard-library/issues/3723

Please update the SQL connector version

@Akshay-De-Silva Please update the changelog file


Perf or no perf, there is no try...

I discovered today that adding custom tryCatcher members to operators with try/catch optimization concerns actually improved performance quite a bit.
So far: map doubled in overall speed (from factor of 1.7x to 3.2x on my machine),
mergeMap improved by a "factor" of a little more than 1x
zip improved by a "factor" of a little more than 1x-2x.
("factor" coming from micro perf output).
This will be part of an effort to go through and examine improvements that can be made where tryCatch/errorObject is being used.
See commits for details.
All of these perf tests are of course in V8/Node, however I don't see any reason they wouldn't carry over to other JIT'ed runtimes.
cc/ @trxcllnt

:+1:

Cool. How do we determine other operators can apply same pattern? try & compare perf manually?

Yes, I'm trying and comparing perf manually

Merging this work for now, it's about half done, but it gives a lot of examples of how to improve perf by using tryCatch handling that's a little more focused than tryCatch/errorObject

Eventually, tryCatch and errorObject can probably be removed from this project entirely.

I'll try to apply same approach on other operators as well.

Eventually, tryCatch and errorObject can probably be removed from this project entirely.

: makes sense - in that case if refactoring does not brings noticeable perf improvement, will it still considered as good to checked in by removing usage of custom tryCatcher?

@blesh

All of these perf tests are of course in V8/Node, however I don't see any reason they wouldn't carry over to other JIT'ed runtimes.

How about ChakraNode (https://github.com/Microsoft/node)? We may be able to use it as a sample.


Frontend comp: React, Graphql, Apollo, Pusher

It was a LOT! I totally kept forgetting to push up from time to time when I should have, especially after every NPM package.


logger is not consist

some logs are like {"controller": "HarborCluster"}, and some are {"controller": "harborcluster",...}

@soulseen

Work has been done


After upcoming release: Let's address the sysadmin requirement & providing more info on connect failure

Is this:
Just place "x" to indicate selection (e.g. "[x]")

[ ] feature
[x] bug:

System Details
Let's address the sysadmin requirement & providing more info on connect failure

I'm not sure I follow what sysadmin requirement you are talking about?
Most actions we have in commands can be done without being given explicit sysadmin role membership. Are we talking about verifying a user's permissions when they connect or something? If so, why?
Any error message you get from SQL Server, whether it be direct SMO or running a query, will give in the exception that permission was denied.

Quick idea...internal function that at most validates permissions.
Initial version we just check for role membership, example.
I have not looked to deeply but have to think there is some Enum method in SMO that will cycle through permissions a given login has for instance level and database maybe that we could use for more detail checking.
Majority of the docs for SQL Server though only specify role membership. With a few actions noting things like must have VIEW SERVER STATE.

We then add a parameter to Connect-SqlInstance to pass in the permissions. Have some mapping maybe in a json file that we can update easily. Like Permission that would pass in say a role or explicit name:
#action requires sysadmin role explicitly
Connect-SqlInstance -SqlInstance myserver -MinimumVersion 10 -Permissions securityadmin

#action requires explicit permissions, not requiring a role memebership
Connect-SqlInstance -SqlInstance myserver -MinimumVersion 12 -Permissions 'VIEW ANY DATABASE','VIEW SERVER STATE'

Reference all SQL Server security posters

@potatoqualitee I think we have already addressed this one have we not?

No way,  cl!