Clarify semantics of updating @data vs. changed data

This issue has its origins in #117, some bits are copied here to focus the discussion only on the topic of what should happen when @data or a tracked property (@data.foo) is updated, while the form might have "dirty" data itself.

headless-form takes the approach of being strict about DDAU, even though in the case of forms there are some more or less valid cases for allowing two-way bindings maybe. But we don't do this, so the user will only get the new data by receiving it from @onSubmit. That means we have the original (unaltered) data coming from the caller as @data, and we have an internal data object that tracks the "dirty" data (user has filled in some fields, making those diverge from @data). What is displayed in the form is then basically the union of these, with any dirty value overriding the original one. Resetting the form then basically means resetting the internal data to an empty object, so all of @data is visible again (for forms used for "create" operations this is mostly just an empty object).
Im trying to incorporate the different cases of the state of the input (pristine - has never been touched by the user - vs. dirty - user has entered a different value than the initial one) and the action that is happening.
So the question we have to answer is: what would a user expect to happen? I.e. what should the ? be in:

@data.foo is updated (@tracked)
@data is reassigned

input[name=foo] is pristine
?
?

input[name=foo] is dirty
?
?

1. data gets copied initially, loses connection with @data afterwards

@data.foo is updated (@tracked)
@data is reassigned

input[name=foo] is pristine
input is not updated (keeps original in value)
input is not updated (keeps original in value)

input[name=foo] is dirty
input is not updated  (keeps filled in value)
input is not updated  (keeps filled in value)

2. changed data (dirty fields) is preserved, only untouched fields reflect @data changes

@data.foo is updated (@tracked)
@data is reassigned

input[name=foo] is pristine
input is updated with @data.foo
input is updated with @data.foo

input[name=foo] is dirty
input is not updated  (keeps filled in value)
input is not updated  (keeps filled in value)

FWIW, I think this is how ember-changeset behaves, having a similar concept of changed vs. original data
3. when @data is updated, any local changes (dirty fields) are discarded

@data.foo is updated (@tracked)
@data is reassigned

input[name=foo] is pristine
input is updated with @data.foo
input is updated with @data.foo

input[name=foo] is dirty
input is updated with @data.foo
input is updated with @data.foo

This would allow the use case of resetting (#117) to be covered by a simple this.data = {}.
4. Only reassigning @data is discarding local changes

@data.foo is updated (@tracked)
@data is reassigned

input[name=foo] is pristine
input is updated with @data.foo
input is updated with @data.foo

input[name=foo] is dirty
input is not updated  (keeps filled in value)
input is updated with @data.foo

This would allow the use case of resetting (#117) to be covered by a simple this.data = {}, while preserving local changes when only properties have been updated. Could this be useful?
5. Make this configurable
We could provide some options to choose between different modes (we already have @dataMode). But having to support multiple cases - some of which are probably not trivial to implement themselves, but the complexity might explode when having to support multiple ones in parallel - comes at a cost.

Thanks for opening this, it makes more sense indeed. I wanted to throw into the mix the idea that when resetting the form state we probably want to reset any possible invalid state as well as clean error messages. So resetting should somehow be done internally. Did you already take this into account? Do you have any thoughts on it?

Yeah, this makes sense, and I had it in my mind in general. But let's keep the reset use case out of this discussion here. we can discuss it in #117 though! :wink:

I think #3 (when @data is updated, any local changes (dirty fields) are discarded) is the most common default behavior.
Blank forms

User opens form

@data is empty
internal data is set as the form is filled

Form is submitted

@data goes from empty to full
internal data is reset to empty (local changes are discarded)

Blank forms, reset before submitting

User opens form

@data is empty
internal data is set as the form is filled

Form is reset

@data is (re)set to empty
internal data is reset to empty (local changes are discarded)

Pre-filled form from server data

User opens pre-filled form

@data pre-filled from server
internal data is set as form is edited

Form is submitted

@data goes from initial to @data plus internal data changes
internal data is reset to empty (local changes are discarded)

Pre-filled form from server data, and then form is reset before submitting

User opens pre-filled form

@data pre-filled from server
internal data is set as form is edited

Form is reset

@data is reset to it's initial @data
internal data is reset to empty (local changes are discarded)

Those are the situations I am most familiar with. So to me #3 seems the most likely.
I think #5 (making it configurable) might be an option too, but only if there are situations aside from these 4 I can think of.

Thanks for the discussion @simonihmig!
I'm all for #3 here.
Having changes to underlying data reset any dirty changes made to the form would be the most in line with DDAU, and yield the most predictable behavior. I'm having a hard time coming up with a use case where another process made a change to an attribute, but i still wanted the dirty change in a form. I can only imagine this being a source of confusion / bugs.
If you don't want the data in the form to update, all you have to do is... not change the data :)
That should be well in hand by the dev at that time, and the business logic should be pretty simple to get the result they want.
I haven't thought about this long and hard, but it seems like with #4, instead of throwing away only the data that changed it'd be a chore to not throw away all changes. You'd do something like get the current data out of the form, them merge it with the new data, and set the data again. Seems like a lot of work for what for me has been the primary use case.

I did a little research on FireFox forms and how it handles the same problem in Vanilla HTML.
Playground to experiment
Turns out that the browser already has a concept of dirty/pristine under the hood. If the user enters a different value as the value="…" attribute it will remain even with a data-down change. But if the data-down change affects a field that is pristine it will update.
This fits the logic:
2. changed data (dirty fields) is preserved, only untouched fields reflect @data changes
| @data.foo is updated (@tracked) | @data is reassigned
-- | -- | --
input[name=foo] is pristine | input is updated with @data.foo | input is updated with @data.foo
input[name=foo] is dirty | input is not updated  (keeps filled in value) | input is not updated  (keeps filled in value)
It would be my preference and I presume that of other developers that this behavior remain as expected to match what browsers already offer. I suspect that users would also feel the same.

After this discussion here (and internally), I am leaning towards the following...
First of all, I think we need to separate the need to support a use case from what should happen when @data changes (the original question here), as we can support a use case in a different way also.
It seems we definitely have a strong case to support #3 here, but also #2 has some support. I feel the latter is especially the case as there is some similar behaviour we see in other cases of having original vs. dirty/pristine data:

as mentioned above, ember-changeset also works that way
and as @sukima mentioned, there is some similarity also with native form behaviour (value attribute vs. value)

With that, I would suggest the following:

when @data changes, the form behaves as laid out in #2
we still can and need to support the use case of "resetting", so we can have some reset action (yielded to the inner template block and/or some "action down" approach as discussed in #117). So when reset() is called, it basically means to throw away all dirty data, i.e. the form will display again what it gets as @data
so when you just want to reset the data to what @data is representing, then you just call reset() obviously. But when you want to completely change the form data, e.g. because the user has selected a different model whose data flows into the form, then you would make @data update with the new form data and call reset(), to wipe out any previous dirty data, thereby supporting case #3

What do you think, does that make sense?

@simonihmig Thanks for summarizing this, looks like we're heading into a good direction, given all the feedback above. One simple question, to clarify things in my mind. When you mention "@data changes", do you mean the whole @data object is reassigned or do you refer to changes within the @data object?
Otherwise what you summarized above makes sense to me 👏

Closing this, #2 is implemented in #132


Handle duplicate imports

Problem:
Importing an element with the same name as an existing element causes a crash (since there are two import statements with the same alias in the file).
Reproduce:
Add a FlexCol to the playground from the utils.js file. Then add a FlexCol to the playground from utopia-api
Fix:

Change the inserting logic (across the system) to handle and change duplicate import names.
Change mergeImports to return an importsMergeResolution - automatically renaming duplicate imports and also returning the duplicate name mapping (so callers can adjust component names if needed)
Change addImport to handle duplicate names
Hook into adding elements from the top insert menu and the draw-to-add right panel - to change component names when inserting (if needed)

Current status/TODO:

Imports are being renamed consistently, according to the import source. We need to rename them using a running number.
Only reparenting (which also includes adding from the top panel and right panel) is manually tested, need to handle copy/paste as well.
Adding tests

@ruggi thanks! yes, I'm adding exaustive tests to the logic, before officially opening the PR

@liady as it's been a while, can you add a couple of gifs or a video with scenarios showing this now working?


Made the default type readers publicly accessible

Added method public IDictionary<Type, TypeReader> CommandService.GetTypeReaders(Type type) which gets all type readers for the given type, default readers included. This is intended to allow commands to use the built in type readers, rather than being restricted to the custom ones that can be added.
I also changed the naming of an existing method from GetTypeReaders to GetCustomTypeReaders and a private readonly variable from _typeReaders to _customTypeReaders to better fit what I understand their purpose to be with relation to the new function I added.

:-1: This is not how type readers are intended to be used.


Weekdays width does not change properly when iPad changes orientation.

Hi, there:
How did you setup FSCalendar and which version did you use?

I installed it using cocoapods. This is the version from Podfile.lock: FSCalendar (0.9.0)

Can I take a look at your viewController?

Try this please. Thanks
https://github.com/f33chobits/FSCalendar/tree/0.9.2


Remove Fn::StackReference doc

Stack references will now be a resource that can be declared, rather than accessed via a function

@AaronFriel @iwahbe We should probably document somewhere else that the user can declare stack references, as well as what other resources pulumi:pulumi:{resourceName} can be created other than the default Stack and now StackReference (if any)

If you have GitHub Code Search enabled, this query should find any relevant replacements, there are a few in this repo:
https://cs.github.com/?scope=org%3Apulumi&scopeName=pulumi&q=Fn%3A%3AStackReference
Looks like:
https://github.com/pulumi/pulumi-hugo/blob/429ed7bfcd95afc3095b341f5fc682914e402388/themes/default/content/docs/intro/concepts/stack.md#L671
https://github.com/pulumi/pulumi-hugo/blob/429ed7bfcd95afc3095b341f5fc682914e402388/themes/default/content/blog/shared-config-with-aws-systems-manager-parameter-store/index.md#L153

It looks like there are still two Fn::StackReference usages in concepts/stack.md.

It looks like there are still two Fn::StackReference usages in concepts/stack.md.

My bad, thanks for catching that! Think that should be all of them now

I think we should pair this with an equivalent section on how you now should create stack references.

The update for the Stacks intro page might suffice? Before YAML was a bit inconsistent in using a function when the docs said to create an instance of the StackReference type using the fully qualified name of the stack as an input


safari (IOS 9) link dropdown does not work

When I click on dropdown bootstrap 3 is open however when I click on the link inside nothing append
issue on ipad safari ios 9
if someone have any advice  ??

    {{_ "SEARCH::RESULTS::Sort by Recency" }}
    {{_ "SEARCH::RESULTS::Sort by Relevance" }}
    {{_ "SEARCH::RESULTS::Sort by Popularity" }}
    {{_ "SEARCH::RESULTS::Sort by Downloads" }}
    {{_ "SEARCH::RESULTS::Sort by Undiscovered" }}
    {{_ "SEARCH::RESULTS::Sort by Relevance" }}

{{_ "SEARCH::RESULTS::Recent"}}

{{_ "SEARCH::RESULTS::Relevant"}}

{{_ "SEARCH::RESULTS::Popular"}}

{{_ "SEARCH::RESULTS::Downloads"}}

{{_ "SEARCH::RESULTS::Undiscovered"}}</a

```

@hellsingblack Please post a JS Bin, JS Fiddle, or similar live example that demonstrates the problem.

Hey there!
We're automatically closing this issue since the original poster (or another commenter) hasn't yet responded to the question or request made to them 14 days ago. We therefore assume that the user has lost interest or resolved the problem on their own. Closed issues that remain inactive for a long period may get automatically locked.
Don't worry though; if this is in error, let us know with a comment and we'll be happy to reopen the issue.
Thanks!
(Please note that this is an automated comment.)


Report language of the app in Matomo

Problem

Report language of the app in Matomo

Part of

#2855

@teolemon I'm not familiar with matomo, but wouldn't a "matomo dimension" be adapted for that? Same with app version (#3769)?


As a user of Garden-Ai I would like the quickstart.rts to have updated CLI info

Short description
After following the quickstart docs I was unable to follow them literally. My tired brain struggled for a bit then Will was able to assist me in discovering the necessary prefix of garden-ai prior to the other CLI args/params.
Creating the issue for documentation; this looks like an easy fix, but I was not sure if auto docs (Sphinx) created the quickstart. If not might be a simple update.
Assumptions:

Appears the quickstart should have the preface of garden-ai garden create --help rather than the bare garden create --help
Assumption that the previous docs might have been acting directly on the repo/local use of garden, when installing via pip the prefix of garden-ai appears to be required.
Can reproduce via following exact lines on the quickstart.

Acceptance Criteria
Given the quickstart docs, when the user follows them, then they are able to successfully get proper CLI responses.

Closed by #83


"Remote Refs"?

When a pull request merge is kicked off, the Initialization action fails with these messages: "couldn't find remote ref refs/pull/40/merge."
Pull request succeeds, code is merged, CI/CD runs without error.
Where to look to correct this?
Run actions/checkout@v3
with:
lfs: true
ref: refs/pull/40/merge
repository: CAI-Software-Inc/CAI-Software-Precious-Metals-Solution
token: ***
ssh-strict: true
persist-credentials: true
clean: true
sparse-checkout-cone-mode: true
fetch-depth: 1
submodules: false
set-safe-directory: true
env:
workflowDepth: 1
ALGoOrgSettings: {"doNotPublishApps": true,"artifact": "https://bcartifacts.azureedge.net/sandbox/22.0.54157.55210/us"}
ALGoRepoSettings:
Syncing repository: CAI-Software-Inc/CAI-Software-Precious-Metals-Solution
Getting Git version info
Working directory is 'D:\a\CAI-Software-Precious-Metals-Solution\CAI-Software-Precious-Metals-Solution'
"C:\Program Files\Git\bin\git.exe" version
git version 2.41.0.windows.1
"C:\Program Files\Git\bin\git.exe" lfs version
git-lfs/3.3.0 (GitHub; windows amd64; go 1.19.3; git 77deabdf)
Temporarily overriding HOME='D:\a_temp\de854350-9743-4edf-b764-b1eb031bd64c' before making global git config changes
Adding repository directory to the temporary git global config as a safe directory
"C:\Program Files\Git\bin\git.exe" config --global --add safe.directory D:\a\CAI-Software-Precious-Metals-Solution\CAI-Software-Precious-Metals-Solution
Deleting the contents of 'D:\a\CAI-Software-Precious-Metals-Solution\CAI-Software-Precious-Metals-Solution'
Initializing the repository
"C:\Program Files\Git\bin\git.exe" init D:\a\CAI-Software-Precious-Metals-Solution\CAI-Software-Precious-Metals-Solution
Initialized empty Git repository in D:/a/CAI-Software-Precious-Metals-Solution/CAI-Software-Precious-Metals-Solution/.git/
"C:\Program Files\Git\bin\git.exe" remote add origin https://github.com/CAI-Software-Inc/CAI-Software-Precious-Metals-Solution
Disabling automatic garbage collection
"C:\Program Files\Git\bin\git.exe" config --local gc.auto 0
Setting up auth
"C:\Program Files\Git\bin\git.exe" config --local --name-only --get-regexp core.sshCommand
"C:\Program Files\Git\bin\git.exe" submodule foreach --recursive "sh -c "git config --local --name-only --get-regexp 'core.sshCommand' && git config --local --unset-all 'core.sshCommand' || :""
"C:\Program Files\Git\bin\git.exe" config --local --name-only --get-regexp http.https://github.com/.extraheader
"C:\Program Files\Git\bin\git.exe" submodule foreach --recursive "sh -c "git config --local --name-only --get-regexp 'http.https://github.com/.extraheader' && git config --local --unset-all 'http.https://github.com/.extraheader' || :""
"C:\Program Files\Git\bin\git.exe" config --local http.https://github.com/.extraheader "AUTHORIZATION: basic ***"
"C:\Program Files\Git\bin\git.exe" lfs install --local
Updated Git hooks.
Git LFS initialized.
Fetching the repository
"C:\Program Files\Git\bin\git.exe" -c protocol.version=2 fetch --no-tags --prune --progress --no-recurse-submodules --depth=1 origin +refs/pull/40/merge:refs/remotes/pull/40/merge
Error: fatal: couldn't find remote ref refs/pull/40/merge
The process 'C:\Program Files\Git\bin\git.exe' failed with exit code 128
Waiting 12 seconds before trying again
"C:\Program Files\Git\bin\git.exe" -c protocol.version=2 fetch --no-tags --prune --progress --no-recurse-submodules --depth=1 origin +refs/pull/40/merge:refs/remotes/pull/40/merge
Error: fatal: couldn't find remote ref refs/pull/40/merge
The process 'C:\Program Files\Git\bin\git.exe' failed with exit code 128
Waiting 19 seconds before trying again
"C:\Program Files\Git\bin\git.exe" -c protocol.version=2 fetch --no-tags --prune --progress --no-recurse-submodules --depth=1 origin +refs/pull/40/merge:refs/remotes/pull/40/merge
Error: fatal: couldn't find remote ref refs/pull/40/merge
Error: The process 'C:\Program Files\Git\bin\git.exe' failed with exit code 128

From the error message and your description, it sounds like you merged the PR while the Pull Request Build was running. Is that the case?
refs/pull/40/merge is a reference GitHub creates and updates as long as the PR is open. Once the PR is merged the reference will disappear as well.

That makes plausible sense.  I will pay attention to that going forward, and pause before merging. Thanks!

No problem :) This is a question we've gotten before so we might want to look into failing/canceling PR Builds more gracefully. I've added an item to the backlog Fail Pull Request Build more gracefully


Revise repository documentation for devfiles

Which area/kind this issue is related to?

/area releng
/area documentation
Issue Description

A review and revising of all the documentation in devfile repositories, including READMEs. This includes adding missing instructions, updating outdated information and separation of documentation where it makes sense.
Acceptance Criteria

[ ] devfile/api @yangcao77
[ ] devfile/registry @johnmcollier
[ ] devfile/registry-support @michael-valdron
[ ] devfile/registry-operator @johnmcollier
[ ] devfile/library @yangcao77
[ ] devfile/devfile-web @michael-valdron

Partial revision of the index server README completed and ready for review: https://github.com/devfile/registry-support/pull/176

This issue should be an epic, converting the acceptance criteria items into child issues with their owners and this item into an epic.

/kind epic

This issue has been converted into an epic. Tracking will now be done by each component documentation task item.

All uncompleted issues are stale, closing this epic issue until there is priority.


Migrate tasks endpoints

Context
JIRA
Since this API PR the updated /tasks
endpoint has provided the behaviour provided two seperate endpoints (tasks/reallocatable, tasks/:taskType).
This PR consolidate these endpoints to use the /tasks endpoint without any change to behaviour.
Changes in this PR

move the tasks/reallocatable calls to the /tasks endpoint
move the tasks/:taskType calls to the /tasks endpoint.

@edavey thanks Ed, I have fixed that test :)


Physics Simulation Example

We could use some open source physics engine to implement a simple physics simulation in regl.
Or we could take it even farther, and implement a demo where you can drive a car in a heightmap.
Does anyone have any recommendations for good physics engines in javascript?

The graph example is actually kind of a particle physics engine, but there is more we could do for sure.
The hard part is collision detection.  We could try using some older ideas like Takahiro Harada's voxelization methods.  There is a bunch of stuff on his home page:

https://sites.google.com/site/takahiroharada/

The best solution though is just sparse grids + sorting, though it is tricky to do in shaders.

Yeah, but I was thinking that doing collision detection and stuff would be a bit too ambigious for a simple demo, so a library that does it on the CPU would be better.
But doing it on the GPU would also be interesting. I will take a look at those links.

Yeah, CPU is probably more pragmatic.  For collision detection you should use this library:
https://github.com/mikolalysenko/box-intersect

I shall see if I can figure out how integrate a physics engine with regl. And then implement a simple example.

Resolved in PR #342.


Do not allocate event_meta_data when it is not needed

I'd rather pass this review to someone who knows how history events work, possibly @fordN or @Jannis.

Rebased to latest master and addressed review comment.


Convert stddev and stddev_pop to UDAF

Which issue does this PR close?

Closes #10827 .
I converted stddev_pop to UDAF, too.
Rationale for this change

What changes are included in this PR?

Are these changes tested?
Yes

Are there any user-facing changes?
no

Thanks @goldmedal and @comphead

Thanks again @jayzhan211 @comphead


Support 'catalog_caching' extra for extractors

Related to:

https://github.com/meltano/meltano/issues/2848
https://github.com/meltano/meltano/issues/6763
https://github.com/meltano/meltano/discussions/6757#discussioncomment-3650870

There seems to be a path forward with catalog_caching being able to be declared as an extra and being able to be disabled with meltano config tap-something set _catalog_caching disabled. One nice thing about not starting with a simple true/false, is that we could expand this in future to be meltano config tap-something set _catalog_caching '60 min' to allow short-lived catalogs in the future.
As an initial boolean toggle though, I think we probably would want to use the true/false or enabled/disabled value to drive the following behaviors:

If caching enabled, use the same catalog file path we have today. (No change.)
If caching is disabled, use a catalog path specific to the execution. (Will not be found on a subsequent run, is multi-process safe, and will still be available afterward for debugging.)

What do you think?

Originally posted by @aaronsteers in https://github.com/meltano/meltano/issues/2848#issuecomment-1249695260

@tayloramurphy, @visch - Are we happy with the initial spec of:

Add catalog_caching as an 'extra' setting for extractors, with initial support for 'enabled' (default) or 'disabled'.
Add CLI support for: meltano config tap-something set _catalog_caching disabled and/or modifying the yaml file to add catalog_caching: disabled to their plugin definition.
If caching is 'disabled', then the catalog file path is generated with a name seed reflecting the current execution ID. Because of the name change, it will not be available to subsequent executions.
We should probably still cleanup the file after execution completes, since otherwise there could be significant storage bloat after hundreds/thousands of executions. (I'm also open to other thoughts on this.)

A completely different approach would be to add something like a global --no-catalog-cache option to the meltano run CLI command. That would work similarly to --no-state-update except instead of ignoring input state we'd be ignoring the previously cached catalog files.

@tayloramurphy, @visch - Are we happy with the initial spec of:

Add catalog_caching as an 'extra' setting for extractors, with initial support for 'enabled' (default) or 'disabled'.
Add CLI support for: meltano config tap-something set _catalog_caching disabled and/or modifying the yaml file to add catalog_caching: disabled to their plugin definition.
If caching is 'disabled', then the catalog file path is generated with a name seed reflecting the current execution ID. Because of the name change, it will not be available to subsequent executions.
We should probably still cleanup the file after execution completes, since otherwise there could be significant storage bloat after hundreds/thousands of executions. (I'm also open to other thoughts on this.)

A completely different approach, instead of modifying the yaml definition, would be to add something like a CLI flag in meltano run like --no-catalog-cache, or --refresh-catalogs. That would work similarly to --full-refresh except instead of ignoring input state we'd be ignoring the previously cached catalog files. This approach doesn't require any change to how catalogs are stored, but it also doesn't give a lot of control, and it would feel odd to have it on meltano run but not meltano invoke or meltano elt.
A third option is to go back to @edgarrmondragon's suggestion and extend meltano select with a '--refresh' option, or similar. That option is looking increasingly nice. Originally, I suggested a better place would be under a meltano catalog command, but the scope for defining such a command (and the broader catalog feature vision) is beyond what we can achieve in a near-term iteration. Presumably, if we add a meltano catalog command in future, we could refactor this operation under that header in the future. (More discussion on future catalog UX here: #6766.) New issue logged:

feature: Add a --refresh option for meltano select to refresh a new copy of the discovered catalog #6919

#1 👍
I just want a way to do this, right now I template this out on all my projects. Work on a new project and forget to do it again and I'm trying hard to not have a seperate repo for workarounds on my end!

Something like this would be very nice, right now catalog caching causes headaches as you have to know about what its behavior is, and it's not easily controllable without knowing the internals.


Add field into issue form

Is your feature request related to a problem? Please describe.
Don't have enough info regarding cloud provider when issue is open
Describe the solution you'd like
Add field asking cloud provider/on premise info
Describe alternatives you've considered
Ask question on thread
Additional context
N/A

We actually do have Environment - Which environment, cloud vendor, OS, etc are you using? section in the template of opening a bug.
Are you referring to "Feature" issue?


Support for audio messages using OpenAI's Whisper API

Right now Whisper-1 does not support ogg and oga file format which Telegram uses for voice messages, it would be easier to wait for support rather than converting it on the fly.


Build(deps-dev): Bump ts-loader from 9.2.8 to 9.2.9 (#3412)

Pull request opened by the merge tool on behalf of #3412

Merged in 47bf74559f223079bf08c8fe6c53f249019f330f


Can't copy/paste images from the web

If you copy an image from a web browser, you cannot paste that image into zulip. If you copy an image from any other program (photoshop, screenshot capture, etc) pasting into Zulip works fine- zulip uploads the image and creates an automatic markdown embed for it.
Tested copy from all listed web browsers and pasting into zulip running on all listed:
RHEL 6.9: (I know these are ancient)

Chromium Version 61.0.3163.79
Firefox 52.3.0

Windows

Google Chrome Version 60.0.3112.90
Firefox 52.3.0
Zulip Desktop App 1.4.0
Zulip Desktop App 1.5.0

OSX 10.12

Google Chrome 62.0.3202.62
Zulip Desktop 1.5.0

On OSX, the URL of the image will be pasted instead of the actual image itself. Obviously there's something system level going on here- possibly having to do with images being copied from web browsers having a more complicated format involving the URL. Hangouts somehow accomplishes this in both the in browser, extension and application forms.
My guess is that the user expectation here is that pasted images and gifs from web browsers would be uploaded the same way that pasted images are normally. If not uploading, then the auto markdown behavior should automatically wrap the URL in the same manner.

Interesting!  If this is possible to fix, I'd certainly love to fix it.  May require some research, but I imagine there must be some copy/paste library we can use to get better access here.

Technical Notes:

Clipboards support the storing of multiple data formats simultaneously
When data is added to the clipboard by an application, it typically makes it available in as many different data formats as it can.
The internal clipboard functionality of the operating system (e.g. Windows) will often automatically translate data from known advanced formats to simpler formats, increasing the likelihood that any given application can interpret some form of the original data.
Files are commonly mapped to their location. (Try pasting a file to the command line.)

If I right click an image from chrome and copy it to clipboard, I can't paste it into Zulip, unless I first paste it into MS Paint and re-copy it from there. (Web client)

On the Mac you can take a screenshot of the desired part with CMD + Ctrl + Shift + 4 and paste it into Zulip. When copying from the browser, the URL is copied along with the actual image, and Zulip uses it instead of the actual image content. I guess it's a matter of JS implementation, bc in Rocket.Chat (and github and others) this works as the user would expect it.

That's OS implementation, the above (copy image) doesn't work on macOS nor Windows. It does work in Slack / Discord to mention few.

@redfellow do you mean that this is possible in the Slack/Discord desktop apps, or in a browser using one of those?

In-browser. Also on popular image sharing sites such as Imgur, so many people might expect to be able to do it.


Update samples and minimum target framework of packages to net461 as ServiceProvider disposal requires MS.Extensions.DependencyInjection 2.x

Relates to https://github.com/AxaGuilDEv/extensions-dependency-injection/issues/19

Net461 reached EOL. Update should be net462


Horizon: DB Runway: reingest with a HDD disk, and time it against the current SSD

Do we need this? I'm 100% sure HDD are just to slow for Horizon.

You would be better served by determining a per-ledger ingest io/operations required estimate and scaling that up.  FWIW i've been running a series of stellar horizon nodes with a 7 million ledger retention count.
My numbers are rough, but it looks like an 'idle' (only ingesting, zero api traffic) mainnet horizon instance in my setup (32GB ram, 6GB postgres shared_buffers) consistently uses around 4-7K IOPs (as reported via tps output from linux iostat at 10 second intervals, using XFS as the postgres volume), with periodic spikes into the 10-14k IOPS range.  I would guess at needing to burst to 8k IOPS for significant periods of time to be able to keep up with the network. Active API use will increase that depending on your application traffic.
If you can build a HDD array that can meet those TPS numbers you can ingest on HDD with no problem.  Getting hard numbers out of HDD performance in the wild generally requires benchmarking, as vendors don't really commit to hard numbers on their datasheets, even for 'enterprise' drives.  As an example though we can extrapolate and still get some ballpark figures.  If we look at, for example, the 2022 Seagate Exos 4kN SAS drives (https://www.seagate.com/files/www-content/datasheets/pdfs/exos-7e10-DS1957-6M-2104US-en_US.pdf), which are listed across their range of having an 'average' latency of 4.16ms, we can guess that we'd at least be able to achieve 6ms access times/seek speed.  Practically this means that to ensure duplication of my above setup, you would need a JBOD of around 100 HDDs to get to the same IOPS rate. (6ms suggest around 166 IOPS per drive).
A modern 'enterprise' SSD or nVME SSD will easily produce orders of magnitude faster operation.  For comparison, seagate's 'Nytro' SSD line (https://www.seagate.com/www-content/datasheets/pdfs/nytro-3032-sas-ssd-DS2047-2-2011US-en_US.pdf) claims to have 40k-160k IOPS depending on the drive model.
So yes, HDDs are too slow to run Stellar Horizon, unless you're building a purpose-built array for the task.


Demonstration of the I18n Task Notifier

Verification of the behavior diff detection.
The first commit (https://github.com/hhiroshell/tag-app-delivery/pull/2/commits/8186299c2be54bc77e0833334cf6df913b61d4c1) updated two existing files. One is located at the end of a symlink and the other is located without a link. Both are detected by GitHub Action. Below is a list of files recognized by GitHub Action as having differences.

https://github.com/hhiroshell/tag-app-delivery/actions/runs/8201709313/job/22430991608?pr=2

In the second commit (https://github.com/hhiroshell/tag-app-delivery/pull/2/commits/1f69288a3c0c931084f1e8efd5f5f799339329df), I have added a new file. This has also been properly recognized as a difference.

https://github.com/hhiroshell/tag-app-delivery/actions/runs/8201744673/job/22431102245?pr=2


corrupted jar

Hey man, nice work! Just for you to double check the file VnCoreNLPServer.jar is probably corrupted.

Hi @alg0s,
Thank you for your message, I have quickly checked with the latest version of VnCoreNLP 1.1.1, there is no problem so far. Could you please check it again or post your problem in detail? Ex. How did you know it's corrupted?

So I will close this issue, if you still have the problem, please feel free to reopen it. Thanks

Hey, I missed the notification for this. Basically, I download your file and tried to run it and it didn't work. It works when I copied the file you shipped to pypi package. Certainly the file on this repo has issue, not the one with VnCoreNLP python pkg.


ROX-19843: Use https://stackrox.io/ for image maintainer label

Description
This is the more correct location for community contact.
Checklist

[ ] Investigated and inspected CI test results

Testing Performed
CI

hmm isn't this typically an email?

@connorgorman and @RTann, I thought so as well but there is no standard for LABEL maintainer= (that I could find) and there are enough others doing maintainer=http that I decided it makes sense from the context of the opensource image to point people a website which will be most likely to have up to date contact links. One could argue that we should switch to OCI annotations in which case the closest to maintainer is org.opencontainers.image.authors contact details of the people or organization responsible for the image (freeform string) which in the case I'd still say best bet is the stackrox.io site.


Two-Factor Authentication with Microsoft Authenticator

Expected behavior
Windows 10 64x
Login to Connect to Docker Hub
Enter Username and Password
Enter Authentication Code
Login Successful
Actual behavior
Enter Username and Password
Error:  Require secondary authentication on MFA enable account
Information about the Issue
When logging into docker desktop on Windows 10, after username and password input, screen is redirected to enter the two0factor identification code. When logging in on Kitematic, after entering in username and password, a red error text comes up with "Require secondary authentication on MFA enabled account". Nothing on the login screen allows me to enter my code, nor do any approval notifications pop up on my device.
Steps to reproduce the behavior

Enable two-factor authentication with Microsoft Authenticator
Try to Login to Windows 10 version of Kitematic

I have the same. Windows 10 Kitematic 0.17.11, Docker Toolbox 19.03.1

Hello! If you can't login from Kitematic yet, try with an Access Token for Docker CLI. It worked for me on Kitematic v.0.17.7 in Windows 10.


Reland engine display features

Relands https://github.com/flutter/flutter/pull/89430
For context, this engine change https://github.com/flutter/engine/pull/24756 adds display features on Android, provided by Jetpack WindowManager (androidx.window). Since this adds a new library, the gradle dependecy lockfiles need to be updated and because the library requires compileSdkVersion 31, the gradle build files need to be updated.
List which issues are fixed by this PR. You must list at least one issue.

https://github.com/flutter/flutter/issues/49411
https://github.com/flutter/flutter/pull/89430
https://github.com/flutter/engine/pull/24756

If you had to change anything in the flutter/tests repo, include a link to the migration guide as per the breaking change policy.
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I signed the CLA.
[x] I listed at least one issue that this PR fixes in the description above.
[ ] I updated/added relevant documentation (doc comments with ///).
[ ] I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt.
[ ] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

There are two remaining issues that need to be solved:

androidx.window uses a newer version of kotlin, which is incompatible with version 1.3.50, used in templates. I updated kotlin to 1.4.32 but this is not compatible with AGP 3.3.0 - There is a test that specifically makes sure apps using AGP 3.3.0 still compile, which is no longer the case. I think this is a breaking change and it should be discussed. Theoretically, I think we can make this new kotlin version work with AGP 3.3.0 by asking the compiler to ignore the differences in metadata versions (which is what it complains about) - but I haven't tried this yet, might not work ok and seems like a temp solution. The test that fails: https://github.com/flutter/flutter/blob/e7b7ebc066c1b2a5aa5c19f8961307427e0142a6/packages/flutter_tools/test/integration.shard/android_plugin_example_app_build_test.dart#L24
androidx.window requires Android API 31. The camera plugin, which is used in one of the tests, uses code that is deprecated in API 31, and warnings are treated as errors. I have opened a separate issue for the camera plugin, which, once fixed, should also fix this test https://github.com/flutter/flutter/issues/89578 . If we want to make this land faster, we can consider removing the -Werror flag. The test that fails is https://github.com/flutter/flutter/blob/e7b7ebc066c1b2a5aa5c19f8961307427e0142a6/packages/flutter_tools/test/integration.shard/deprecated_gradle_settings_test.dart#L17

These version bumps (kotlin, android API and AGP) need to be dealt with eventually. Is there anything in the tooling or framework that helps with old plugins or old apps that I'm missing? @blasten Could you please advise? I'm asking because of  https://github.com/flutter/flutter/pull/71964

@andreidiaconu I filed https://github.com/flutter/flutter/issues/89609. Does your change require to bump the targetSdkVersion/compileSdkVersion?

Yes, it does.
On Wed, 8 Sep 2021 at 00:38 Emmanuel Garcia @.***>
wrote:

@andreidiaconu https://github.com/andreidiaconu I filed #89609
https://github.com/flutter/flutter/issues/89609. Does your change
require to bump the targetSdkVersion/compileSdkVersion?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/pull/89511#issuecomment-914645927,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKWJPWJ7WIWNVNTGI3HVZDUA2A4ZANCNFSM5DPB76AA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

does it mean that your change will break older apps that don't update these?

Yes, unfortunately, unless I am missing something.
On Wed, 8 Sep 2021 at 00:41 Emmanuel Garcia @.***>
wrote:

does it mean that your change will break older apps that don't update
these?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/pull/89511#issuecomment-914647111,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKWJPRLERU7QPNXCZFLMW3UA2BHDANCNFSM5DPB76AA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

This is problematic then. I'm not sure what the next step should be, other than split the changes so that the activation requires a manual step.
You mentioned that this is is hard to land as a plugin, but can a portion of this change land as a plugin? In particular, the code that brings the Android dependency, and requires a higher SDK?

@blasten The problem is not with targetSdkVersion / compileSdkVersion. The compatibility issue shows up between old versions of AGP and newer versions of kotlin, which is added with this engine PR.
For an application to run into issues, it would need to use AGP version 3. The framework templates is are set to version 4.1.0, which works fine with the latest kotlin 1.5.30. If an app stops building after this PR, it would only need to run flutter create .
Older apps still using AGP 3 are already forced to update if they try using plugins with newer version of kotlin. Here is an example issue of this happening https://github.com/flutter/flutter/issues/83834 . Moving forward, less and less apps will even be able to use AGP 3 due to this lack of compatibility with newer kotlin. It only takes one plugin to use it for the developer to be forced to update AGP.
For more exact numbers, androidx.window uses kotlin version 1.5.21 and this version is not compatible with AGP 3.3.0 (used in this test).

Thanks for the research. In this case, it sounds like reverting the targetSdkVersion/compileSdkVersion changes in this PR will fix the issue seen in #89609

@blasten I spoke to soon on compileSdkVersion. androidx.window does have minCompileSdk set to 31, which then requires anyone using it to have compileSdkVersion set to at least 31. From what I can see, there isn't anything specific in the library to warrant this requirement. I will try to see if this restriction can be dropped on their side, since it also contradicts their own guidelines -- assuming this was not intentional https://github.com/androidx/androidx/blob/androidx-main/docs/api_guidelines.md#choosing-a-minsdkversion-module-minsdkversion
I will keep you updated and sorry for my confusion

@blasten I discussed with the androidx team and they will not lower the minCompileSdk. They now use this configuration on all their libraries and doing this has standardisation advantages for them and their users.
Bringing in androidx.window forces us to use compileSdkVersion 31. targetSdkVersion can remain whatever developers prefer. This means that:

Apps not yet using compileSdkVersion 31 will need to run flutter create . to update their android configuration
Apps using methods deprecated in API 31 need to be updated because of the -Werror flag. A solution for not breaking these apps would be removing the -Werror flag.

compileSdkVersion 31 is fine as it only says 'we want the last features from Android 12' and not 'compatibility mode'. The issue is that every year there is a new version, and Flutter itself, its libraries and apps have been historically bad at keeping track of this.

Hey @andreidiaconu thank you for all of your work and research on this. I am just catching up on it. :)
Given your last update, do you want to proceed with this change using compileSdkVersion 31? I am here to help move this along, so let me know if there is anything I can do to assist.

Yes, I want to continue with compileSdkVersion 31.
On Fri, 1 Oct 2021 at 22:09 Kate Lovett @.***> wrote:

Hey @andreidiaconu https://github.com/andreidiaconu thank you for all
of your work and research on this. I am just catching up on it. :)
Given your last update, do you want to proceed with this change using compileSdkVersion
31? I am here to help move this along, so let me know if there is
anything I can do to assist.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/pull/89511#issuecomment-932484934,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKWJPRBTDL4QJUEOZRZRQTUEYBPDANCNFSM5DPB76AA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Ok thanks for clarifying! :)
@blasten do you think this breaking change is acceptable if we go through the process and provide a migration guide?

Thanks @Piinks. Andrei, I'm sorry this is taking longer, or that this issue wasn't brought up earlier.  (I was collecting information from the design doc reviewers.)
I'd like to see a proposal where we define an interface with a default implementation that doesn't require any of these changes to an app. At a high level, I'm mostly concerned that new features all the sudden require new embedding dependencies, or migrations guidelines for everyone, even if an app doesn't use these features.
AndroidX libraries themselves were carefully designed, so they can be included in an app as needed. I'd like to see how that model can work in Flutter as well.
There are exceptions to this model. e.g. Android's lifecycle was a necessary dependency that had our team debating for nearly a quarter (cc @xster).
Given that the communication channel between the framework and the native side is platform channels, what sort of limitation do you see by having an interface with two different implementations?  That is, one shipped as a plugin that requires the changes to the app you are suggesting, and one with a default (no-op) implementation.

One limitation I see is that viewport metrics can get out of sync, which is
why (to my recollection) we opted to use existing engine methods directly
for delivering that data from android to engine to dart.
Just to make sure that we avoid confusion, I would like to say that display
features (these changes) are not using platform channels, but method calls
on the engine directly.
Regarding high level concerns:
Having a less coupled system for adding features to the engine and
framework sounds good, but it seems like a bigger change, compared to this
one feature. It would require refactoring the engine. If what you had in
mind is not a system for existing and future features, I think I
misunderstood.
For this feature specifically, communication could be moved from calling
engine methods to platform channels, but there are several implications if
we go down this path:

Agreement from initial reviewers.
A rewrite of the engine PR. Most of the code is specific to the method we
chose to use.
Introduction of a new concept: Parts of Flutter (display features, in
this case) would not work unless you also include a package in pubspec —
but you would not get any error. This has its own implications, like the
need for lint rules or other mechanisms for making sure apps that use this
feature don’t get shipped without including the feature package.

When you say you would like to see a proposal based on interfaces with
default implementations, do you mean

for this feature specifically or
in general as a path for engine and framework contributions

and

who do you see owning the proposal?
what happens to this feature while this system is being developed?

On Fri, 1 Oct 2021 at 22:36 Emmanuel Garcia @.***>
wrote:

Thanks @Piinks https://github.com/Piinks. Andrei, I'm sorry this is
taking longer, or that this issue wasn't brought up earlier. (I was
collecting information from the design doc
https://docs.google.com/document/d/1GpGok1btvPlfK24cBQY9D1mlsxT_EQ5RTGJuewaRr3o/edit?resourcekey=0-4pQAmbSPppAGxDIbJubBFw#heading=h.pub7jnop54q0
reviewers.)
I'd like to see a proposal where we define an interface with a default
implementation that doesn't require any of these changes to an app. At a
high level, I'm mostly concerned that new features all the sudden require
new embedding dependencies, or migrations guidelines for everyone, even if
an app doesn't use these features.
AndroidX libraries themselves were carefully designed, so they can be
included in an app as needed. I'd like to see how that model can work in
Flutter as well.
There are exceptions to this model. e.g. Android's lifecycle was a
necessary dependency that had our team debating for nearly a quarter (cc
@xster https://github.com/xster).
Given that the communication channel between the framework and the native
side is platform channels, what sort of limitation do you see by having an
interface with two different implementations? That is, one shipped as a
plugin that requires the changes to the app you are suggesting, and one
with a default (no-op) implementation.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/pull/89511#issuecomment-932500248,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKWJPQRZB6OHKQXIMVJTGLUEYET5ANCNFSM5DPB76AA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

One limitation I see is that viewport metrics can get out of sync, which is
why (to my recollection) we opted to use existing engine methods directly
for delivering that data from android to engine to dart.

Looking at https://github.com/flutter/engine/pull/24756, it seems doable to add a method (e.g. buildFlutterView()) to FlutterActivity that allows to override the implementation of FlutterView.   You could subclass FlutterView and add the changes added to the engine that use the  androidx.window.* packages.
Lastly, a plugin could have a FlutterView subclass as well as WindowInfoRepositoryCallbackAdapterWrapper class.  Then, the only step for a developer becomes overriding the buildFlutterView() in FlutterActivity, and bumping compileSdkVersion.
Would there be an issue with this approach?

The engine and framework would still need to know about the concept of
display features (viewport metrics would contain display features). The
framework would still use display features but they would not be populated
by default. Developers might expect them to work, without any obvious
signal that they don’t, unless they also include a plugin.
Are we doing all of this to avoid bumping compileSdkVersion from 30 to 31?
On Sat, 2 Oct 2021 at 04:07 Emmanuel Garcia @.***>
wrote:

One limitation I see is that viewport metrics can get out of sync, which is
why (to my recollection) we opted to use existing engine methods directly
for delivering that data from android to engine to dart.
Looking at flutter/engine#24756
https://github.com/flutter/engine/pull/24756, it seems doable to add a
method (e.g. buildFlutterView()) to FlutterActivity that allows to
override the implementation of FlutterView. You could subclass FlutterView
and add the changes added to the engine that use the androidx.window.*
packages.
Lastly, a plugin could have a FlutterView subclass as well as
WindowInfoRepositoryCallbackAdapterWrapper class. Then, the only step for
a developer becomes overriding the buildFlutterView() in FlutterActivity,
and bumping compileSdkVersion.
Would there be an issue with this approach?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/pull/89511#issuecomment-932652993,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKWJPRITJVS76JBFTAW67LUEZLOLANCNFSM5DPB76AA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Are we doing all of this to avoid bumping compileSdkVersion from 30 to 31?

...and the embedding dependency.
Bumping compileSdkVersion has the potential to cause warning. In this case, the only solution would be to disable warnings as errors if this is caused by a plugin.

To my knowledge, the embedding dependency has already been agreed to at the beginning. We waited for the dependency to reach beta status, which was the only thing holding us back at the time.

My main concern is the required step for all developers after a flutter upgrade. Do you have a doc about what should happen and what is the DevX?

DevX stands for Developer Experience (as in Surface Duo Developer Experience) and it's the team I'm part of. I'm not sure why you're asking, but I hope that answers your question. The only doc we have so far is the one you linked to earlier in this thread.
I understand the issues devs will face by changing the compileSdkVersion, but as I understand it, androidX already moved all their libraries to require a min sdk version of 31 (including any library flutter already uses and will have to update at some point). Staying on api 30 is a temporary solution.
In fact, not using compile version 31, while using libraries compiled with it is dangerous, as parts of the code might get obfuscated / removed during the build process. To my understanding, that is why androidX specifically added the minCompileSdk to all their libraries.
On the other hand, my concern with the proposed solution is that devs might end up using display features without them actually working. Devs might expect dialogs and popups to avoid the hinge, but without opting in, that will not happen, and they will not be aware of it.

How did Flutter got into compileSdk 30? I think you bump it like every year randomly.
For example, 28 -> https://github.com/flutter/flutter/pull/26798
In a few months, there will be 32 with the rumored Pixel foldable. Next year there will be 33. I think we should have a plan for these upgrades as they are very common and Google forces sdk-2 every year.

sorry for the confusion. Maybe, we should set up some video chat to make sure we are in the same page.
My question around DevX is what is the developer experience proposal for Flutter users once they do a flutter upgrade and flutter build apk for example. Do we envision a warning generated by the Flutter tool with concrete steps?  What about warnings, do we disable warnings as errors for all apps?

How did Flutter got into compileSdk 30? I think you bump it like every year randomly.

@bernaferrari - To my knowledge those cases didn't affect existing apps.
If my understanding is correct,  the issue we are discussing is that all apps will stop compiling once this change is merged.
The fix appears to just be one line change, but if warnings are found due to the use of plugins, then warnings as errors settings must be removed as well.

My explanation about DevX was just silly in this context :) - The video call is a great idea and was thinking the same thing. Will reach over email.
As for the compile sdk, since most Flutter apps end up using at least one androidX library at some point, and since all androidX libraries now have minCompileSdk=31, this will become a problem for all devs sooner or later. This is a rather new (a few months ago) addition to androidX libraries, so a guided migration for flutter developers is not something we're doing just for this contribution but something that will affect devs anyway.

I'm moving compileSdkVersion to flutter.gradle, so it's easier to manage version bumps in the future. https://github.com/flutter/flutter/blob/3d4b25dcaeca58495ba7248af7d4e85470b647ed/packages/flutter_tools/gradle/flutter.gradle#L38

Gold has detected about 3 new digest(s) on patchset 2.
View them at https://flutter-gold.skia.org/cl/github/89511

Engine reland PR https://github.com/flutter/engine/pull/29447

@blasten Could you please have a look at https://github.com/flutter/engine/pull/29447 for trying to reland this?
This PR si most likely still needed, because of the lockfiles.

Does luci-flutter turn green when all other checks are green? I'm a bit confused as to what I can do to make it pass.

It turns green when all tests are passing on master. In this case, one test failed in the last invocation, so I retriggered it.

From what I see, one of the red areas in https://ci.chromium.org/p/flutter/g/flutter/console relates to one of the tests also fixed in this PR (failure caused by firebase requiring minSdk 19 instead of 16).

Got it.


[cleanup][functions] Remove unused code

Motivation
Since #3969, packageUrl is not set anymore in FunctionDetails so code that depend on it can be removed.
In the case of KubernetesRuntime we currently download the function itself and not the package.
This change doesn't modify this behaviour.
Verifying this change

[x] Make sure that the change passes the CI checks.

This change is a trivial rework / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:
no
If yes was chosen, please highlight the changes

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API: (yes / no)
The schema: (yes / no / don't know)
The default values of configurations: (yes / no)
The wire protocol: (yes / no)
The rest endpoints: (yes / no)
The admin cli options: (yes / no)
Anything that affects deployment: (yes / no / don't know)

Documentation
Check the box below or label this PR directly.
Need to update docs?

[ ] doc-required
(Your PR needs to update docs and you will update later)

[x] doc-not-needed
cleanup

[ ] doc
(Your PR contains doc changes)

[ ] doc-complete
(Docs have been already added)

/pulsarbot rerun-failure-checks

@nlu90 @freeznet Would like to know your thought

/pulsarbot rerun-failure-checks

@zymap can we merge this patch ?
@freeznet approved


EKS IPv6 target support

When we deploy IPv6 clusters in EKS the pods are only given IPv6 but currently Lattice Target Groups for EKS only support IPv4 therefore IPv6 pods can't be targets. Would be great to add IPv6 to Lattice for EKS backends.

Should be supported with #329


Buy Command Issue.

Pika responds with "Could not find [store-item] in the shop. Make sure you entered your choice case sensitive!"
This is only applies for items in the shop that have a "-" in it. For example p*buy Icead-Tea

Hello Proxy,
We are currently looking into this issue and commiting a fix.
We will update this thread as soon as possible.
~ Tayron, CEO of Little Studios
VerifiedProxy @.***> schrieb am Fr., 30. Apr. 2021,
10:37 PM:

Pika responds with "Could not find [store-item] in the shop. Make sure you
entered your choice case sensitive!"
This is only applies for items in the shop that have a "-" in it. For
example p*buy Icead-Tea
[image: Screenshot_20210430-163647_Bluecord]
https://user-images.githubusercontent.com/83475317/116751616-4a514b00-a9d2-11eb-9a1f-3e9f28ee0efe.jpg
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/littlestudios69/Pika/issues/8, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMBPN7D5JLZBC6MTV6OZCJLTLMIINANCNFSM435NUL6Q
.

Hi Proxy,
the name of that item is "Iced Tea", there's no "-" inbetween.
Please try again with the correct spelling.
~ Felixprogram

Hi @VerifiedProxy ,
after looking into it it seems like Tayron used different spellings in the shop and in the buy command.
It has been fixed with commits bcd4baf1fdf804b6bb6fa72339397f24a000ca87 and f1dd77583aa87fb9cb93f6b3df32f3bc8c987a5d
~Felixprogram, CTO of Little Studios


[Game Crash] WARNING: OutFox Engine: Failed to initialise Discord SDK Core! - Exiting on windows 10

Describe the crash
log.txt
It was loading songs until this error message keeps popping up every time I load the program.  I tried optimizing the files (.PNG, .FLAC, etc) but it still crashes at the same point.
How can you reproduce the error?
Just start the program and let it run.  It crashes at around "Love is Dreaminness".  II think the size of the program might have something to do with it.
Screenshots/Videos
No response
Additional Information
The size of the program on my machine is over 40G

B

I forgot to mention it was working before the last releases.

Do you also have your crashinfo.txt that you can share here? If you have that, that would help us even more.

could you run this again and provide the crashlog as well? cheers

no reply, but we have fixed several of the parsing crashes in 4.13, reopen if you find this bug again


Automatically scrolling cursor into view after selection change this will be disabled in the next version set editor.$blockScrolling = Infinity to disable this message

Hi there,
First, thanks for the library, works pretty good.
But I am getting this annoying warning.
Wonder how I am able to shut it off as I cannot seem to find a way to access the editor variable
Thanks

Hi collapsarzhang,
You can use it the same way as Manhlg -> https://github.com/fxmontigny/ng2-ace-editor/issues/12

hmm, yeah, I got the editor variable/instance, but seems like the console prints out the warning message before I could do anything with it.
maybe there is a way I could set $blockScrolling = Infinity with a globally available variable/instance?

@collapsarzhang If you set it in the ngAfterViewInit() method it will stop the message from appearing.
@fxmontigny It will be good if this can be set globally in the constructor of the component and the directive rather than manually for each instance of it.

I am trying this
export class GlobalSettings implements AfterViewInit, OnDestroy, OnInit {
  @ViewChildren('editor') public editorQueryList: QueryList<any>;

  ...

  public ngAfterViewInit(): void {
    this.editorQueryList.changes.subscribe((comps: QueryList <any>) => {
      if (comps.first) {
        const editor = comps.first.getEditor();
        editor.$blockScrolling = Infinity;
      }
    });
  }

  ...

}

But as @collapsarzhang said it seems to be too late (after the warning).

What worked for me was setting this.editor._editor.$blockScrolling, like this:
import { OnInit , ViewChild } from '@angular/core';
...
export class PropertyEditorComponent implements OnInit {
  @ViewChild('editor') editor;
  ...
  ngOnInit() {
    this.editor._editor.$blockScrolling = Infinity;
  }
  ...
}

I'd first tried console.log(this.editor) there and saw the $blockScrolling was already set to Infinity in this.editor, so I dug further and found that it actually needs to be set in that editor._editor object.
Of course, in the HTML template, I also had to add #editor to the <ace-editor> tag to make @ViewChild work, like this:
<ace-editor ... #editor></ace-editor>

Thanks for your reply, @RobertSundling. I've just tried your proposal, but it does not seem to work for me. In ngOnInit, this.editor is still undefined!

You could always derive a class from AceEditorDirective or AceEditorComponent using component inheritance and then add the code directly in an init method, which is called by the AceEditorComponent constructor immediately after the editor object is created.  Something like this (untested code):
import { Component } from '@angular/core';
import { AceEditorComponent } from 'ng2-ace-editor';

@Component({
  selector: 'my-ace-editor'
})
export class MyAceEditorComponent extends AceEditorComponent {
    init() {
        super.init();
        this._editor.$blockScrolling = Infinity;
    }
}

Then use my-ace-editor in your templates rather than ace-editor.
(This is assuming you're using the component version of ng2-ace-editor; if you're using the directive version, you'll need to change the above code as appropriate; the selector would be '[my-ace-editor]', and then you'd change all the references of Component to Directive.)

The following works for me:
HTML:
<ace-editor #editor [(text)]="text" [mode]="'json'" [theme]="'tomorrow_night_eighties'"
    [autoUpdateContent]="true" [durationBeforeCallback]="1000"></ace-editor>

Note: make sure you are using ace-editor component rather than directive.
TS:
@ViewChild('editor') editor;
ngOnInit() {
    this.editor.getEditor().$blockScrolling = Infinity;
  }

Hi,
Now block scrolling infinity is included by default.
:D


Force Delete Flag for some resources

What problem are you facing?
Some resources do not allow deletion if they have dependent resources (s3 bucket with items, vpc with resources, etc). This can cause the provider reconciler to fail to delete resources. Our use case revolves around s3 and vpc's. We want users to be able to create and cleanup buckets and vpcs even if they have items created in them from outside crossplane.
How could Crossplane help solve your problem?
Was thinking for these resources add a force delete flag in the spec and logic to controller to do the cleanup. Similar to force_destroy option for s3 buckets in terraform.

Thanks for this feature request @enderv! I agree this would be good functionality to have, but we need to think about how it should work.
Architecturally we try to ensure that our managed resources map cleanly to a cloud provider API object or at least concept to keep our implementation granular and predictable. Terraform et al achieve this "force delete" functionality by listing and deleting all objects in the bucket being deleted, which blends concepts a little more than I'd like - i.e. ideally when you operate on a Crossplane "bucket" you could could be confident that you're only ever exercising code that operates on AWS buckets, and not objects.

Thanks for this feature request @enderv! I agree this would be good functionality to have, but we need to think about how it should work.
Architecturally we try to ensure that our managed resources map cleanly to a cloud provider API object or at least concept to keep our implementation granular and predictable. Terraform et al achieve this "force delete" functionality by listing and deleting all objects in the bucket being deleted, which blends concepts a little more than I'd like - i.e. ideally when you operate on a Crossplane "bucket" you could could be confident that you're only ever exercising code that operates on AWS buckets, and not objects.

I think I'm in the same boat with @negz . It's a very useful feature for sure, but with the high fidelity goal, I'm not sure if it fits in the bucket controller. Maybe a small webhook or controller could do what you want; if <bucket cr>.deletion { list and delete every object } or maybe you could incorporate this functionality into your uninstall/removal process of the application if possible.

I think I'm in the same boat with @negz . It's a very useful feature for sure, but with the high fidelity goal, I'm not sure if it fits in the bucket controller. Maybe a small webhook or controller could do what you want; if <bucket cr>.deletion { list and delete every object } or maybe you could incorporate this functionality into your uninstall/removal process of the application if possible.

Agree not really a fan of flag but wanted to throw it out there. Something we are thinking about doing is using a helm release that just uses pre-delete hook to run a job that does the cleanup and just include that in the composition.
Which makes me think a handy pre-delete job hook somewhere would be nice.

Agree not really a fan of flag but wanted to throw it out there. Something we are thinking about doing is using a helm release that just uses pre-delete hook to run a job that does the cleanup and just include that in the composition.
Which makes me think a handy pre-delete job hook somewhere would be nice.

@ulucinar / @muvaf asked me on slack to list some examples of stuck-on-deletion issues I had seen. As there already is an issue I'll write them here:
Patched invalid external-name
apiVersion: ecr.aws.crossplane.io/v1alpha1
kind: Repository
metadata:
  name: delete-demo1
spec:
  forProvider:
    imageScanningConfiguration:
      scanOnPush: true
    imageTagMutability: MUTABLE
    region: eu-north-1

Status:
  At Provider:
    Created At:       2021-06-17T16:20:31Z
    Registry Id:      123
    Repository Arn:   arn:aws:ecr:eu-north-1:123:repository/delete-demo1
    Repository Name:  delete-demo1
    Repository Uri:   123.dkr.ecr.eu-north-1.amazonaws.com/delete-demo1
  Conditions:
    Last Transition Time:  2021-06-17T16:20:31Z
    Reason:                Available
    Status:                True
    Type:                  Ready
    Last Transition Time:  2021-06-17T16:20:31Z
    Reason:                ReconcileSuccess
    Status:                True
    Type:                  Synced

k annotate -f repo1.yaml --overwrite 'crossplane.io/external-name=foo/$USER/bar'
k delete -f repo1.yaml
repository.ecr.aws.crossplane.io "delete-demo1" deleted
# hangs
k get -f repo1.yaml -o yaml

...
status:
  atProvider:
    createdAt: "2021-06-17T16:20:31Z"
    registryId: "123"
    repositoryArn: arn:aws:ecr:eu-north-1:123:repository/delete-demo1
    repositoryName: delete-demo1
    repositoryUri: 123.dkr.ecr.eu-north-1.amazonaws.com/delete-demo1
  conditions:
  - lastTransitionTime: "2021-06-17T16:20:31Z"
    reason: Available
    status: "True"
    type: Ready
  - lastTransitionTime: "2021-06-17T16:23:03Z"
    message: 'observe failed: failed to describe repository with id: InvalidParameterException:
      Invalid parameter at ''repositoryName'' failed to satisfy constraint: ''must
      satisfy regular expression ''(?:[a-z0-9]+(?:[._-][a-z0-9]+)*/)*[a-z0-9]+(?:[._-][a-z0-9]+)*'''''
    reason: ReconcileError
    status: "False"
    type: Synced

This is a special corner case - I believe. If a webhook refused the invalid external name patch (there are two issues here - 1) what is a valid name for this specific resource 2) What should we do when someone patches the external name of a provisioned resource) I believe this would never happen. So it might be better to prevent the possibility of this issue happening, instead of handling this specific issue.

Non-empty ECR repo
This is easier to handle, a force flag is available in the API.

ECR Policy refers to a non-existing repo - already fixed
https://github.com/crossplane/provider-aws/commit/32bd5c63a3437847310a13ab6b2c7bb4739f6243
  - lastTransitionTime: "2021-06-17T17:23:11Z"
    message: 'observe failed: failed to get repository policy: RepositoryNotFoundException:
      The repository with name ''delete-demo2'' does not exist in the registry with
      id ''234235989272'''
    reason: ReconcileError
    status: "False"
    type: Synced

I had a similar issue with the CloudFront Distribution resource. AWS does not allow you to delete a Distribution if it's enabled. If the managed resource is deleted while its spec.forProvider.distributionConfig.enabled is true, then AWS would block deletion of it returning an error in response to the deletion call. We discussed this issue with @muvaf and my proposal was to provide a "higher-level" API for this resource with something like spec.forceDelete or similar so that its controller would take the required actions to get it deleted (i.e., disable the corresponding Distribution AWS resource prior to deletion). I think putting it under spec.forProvider would not be suitable as it would violate our high-fidelity goal.
There are also certain resources like KMS CMKs for which, according to my understanding, it is not even possible to force an immediate deletion.

Another example: deleting a security group which is in use / referenced by another security group. Slightly related to https://github.com/crossplane/crossplane-runtime/issues/261

Another example, IAMRole: failed to delete the IAMRole resource: DeleteConflict: Cannot delete entity, must detach all policies first.

Hello, I will just update in here as in I'm currently trying out crossplane but I got stuck on deletion of IAM. Ran few tests and works great although I wanted to clear out and start new. I think the policies get deleted before the Policy Attachment which makes them stuck in deletion (an hour currently and going). Tried forcing it but no luck.
 Any idea how I can force delete the resources currently so I can reroll the configuration?

Hello, I will just update in here as in I'm currently trying out crossplane but I got stuck on deletion of IAM. Ran few tests and works great although I wanted to clear out and start new. I think the policies get deleted before the Policy Attachment which makes them stuck in deletion (an hour currently and going). Tried forcing it but no luck.
 Any idea how I can force delete the resources currently so I can reroll the configuration?

@St0rmRage try describe on the resource. AWS will normally not let you delete a resource which is in use/has a dependent. So you need to remove that dependency or clear the relation.

There's a very simple solution to this problem. Create a "DeletePolicy" resource in Crossplane. Tekton is the tool we need to handle any of the little quirks, i.e emptying an s3 bucket of its content before attempting to destroy the bucket. If there's an official Crossplane-Tekton provider, we can have the S3 Bucket's DeletePolicy  invoke the PipelineRun and depend on it's status: success to proceed in S3 bucket delete.
Please build an official Tekton Provider for Crossplane. ArgoCD/Flux + Tekton + Crossplane is by far the best stack for fully on-demand app-infrastructure & declarative setups. Having to implement Tekton via Helm release is depressing. It would be much better to have a native Tekton PipelineRun status field to use as a dependency in Crossplane's implicit dependency via variable configuration.

Seems this issue has been forgotten. We really need this feature for non empty s3 buckets

below works for me:
To force delete a custom resource, follow these steps :
Edit the Object : kubectl edit customresource/name
Remove finalizer parameter
Delete the object : kubectl delete customresource/name

There is force parameter in DeleteBucket and according to https://stackoverflow.com/a/68065463 there is no way to actually force delete a bucket in AWS. One would have to delete all objects and versions before finally removing the bucket. I don't think we are going to implement this in the provider as it would make the already complex bucket controller even more complex. Furthermore it would most likely not possible to perform this in a single reconcile since we would likely run in a context timeout.
I suggest to implement a custom controller or K8s job that will prune a bucket before removing it.
Regarding other resources: There are force delete flags at least for Repository.ecr and Secret.secretsmanager.
If there are any resources where an API is provided by AWS but not implemented in the provider, feel free to open a PR to add it.


Hit the WebSocket RateLimit!

General Troubleshooting

[x] I have checked for similar issues.
[x] I have updated to the latest JDA version
[x] I have checked the wiki and especially the FAQ section for similar questions.

Question
When building a ShardManager instance using the DefaultShardManagerBuilder and also disabling specific Intents and CacheFlags do I receive these warnings without knowing what the issue is:
Hit the WebSocket RateLimit! This can be caused by too many presence or voice status updates (connect/disconnect/mute/deaf). Regular: 0 Voice: 0 Chunking: 503

(note that 503 is different depending on the shard)
This starts once the bot connects to the websocket (Connected to WebSocket! message) and then spams in regular intervals the console.
Example Code
Code used to built a ShardManager instance
/*
 * getFileManager() is a getter for a class that loads and handles JSON files.
 * waiter is a EventWaiter (JDA-Utilities) instance.
 * getMessageUtils() is a class for various message-related stuff (in this case getting a random startup message)
 */
DefaultShardManagerBuilder
    .create(
        getFileManager().getString("config", "bot-token"),
        GatewayIntent.GUILD_MEMBERS,
        GatewayIntent.GUILD_MESSAGES,
        GatewayIntent.GUILD_EMOJIS,
        GatewayIntent.GUILD_MESSAGE_REACTIONS
    )
    .disableIntents(
        GatewayIntent.GUILD_VOICE_STATES,
        GatewayIntent.GUILD_PRESENCES
    )
    .disableCache(
        CacheFlag.ACTIVITY,
        CacheFlag.VOICE_STATE,
        CacheFlag.CLIENT_STATUS
    )
    .addEventListeners(
        new ReadyListener(this),
        new ConnectionListener(this),
        new GuildListener(this),
        new CommandListener(this, CMD_HANDLER),
        waiter
    )
    .setShardsTotal(-1)
    .setActivity(Activity.of(Activity.ActivityType.DEFAULT, getMessageUtil().getRandomStartupMsg()))
    .setStatus(OnlineStatus.DO_NOT_DISTURB)
    .build();

This is intended behavior. Discord requires to chunk the members for each guild individually. You have to either accept these warnings or disable chunking with setChunkingFilter(ChunkingFilter.NONE).

Would disabling the ChunkingFilter have any major impact on the bot? Like on what methods you can use or the general performance? Or is it neglectable?

Without chunking, JDA will use lazy loading and start off with a minimal set of members. If the GUILD_PRESENCES intent is disabled, we start off with only voice members. With GUILD_PRESENCES we start with online members and voice members. Additional members will be loaded once they are active.
There are many ways to load and access members without chunking:

retrieveMemberById
retrieveMembersByPrefix
retrieveMembers

Will Message#getMember() and similar get methods still work?

Will Message#getMember() and similar get methods still work?

Depends on the message origin. In events, yes. When you do retrieveMessageById discord currently doesn't provide the member instance, so it will be null.

Thanks for the clarifications.


Use typelevel/bobcats for crypto in core, server, client

This PR (binary- and source-compatibly) re-implements all crypto methods in core, server, and client to use the new cross-platform typelevel/bobcats library proposed in #5044. In doing so, we are able to purge all references to JVM-only classes that are not available on Scala.js
Although these changes are meaningless for 0.22 and 0.23, they will greatly simplify merges into 1.0 (such as #5023) where these implementations are currently "platformed" across multiple files. When this trickles up to 1.0, we'll be able to de-platform all those files and also remove the big ugly JS crypto facade currently sitting in core.
Why it would be excellent if this PR could make the next release train: to make things work, I had to binary-incompatibly change the signatures of the new public methods of the SignatureAlgorithm classes introduced in #5023. This is possible right now because those changes have not yet been released.

Oops, I guess this missed the release train. I'll have to rework for bincompat.

I'm sorry.  You were absolutely right on the timing.

It's ok, it was the right call! The GHSA was very important and this was would have been last minute crypto-related changes which shouldn't be rushed imo. I'll be able to fix this, it just won't be as nice as it was before for both our merges and user migrations.

That said, depending on a brand new library on the production branches is a pretty big risk.  A breaking bobcats would break us, or if we remain pinned, set up nasty diamond dependencies.  The impulse to unify the branches is good, but it would feel a lot safer on a bocats-1.0.

[continued] whereas main might be an ideal place to make sure bobcats is mature.

That said, depending on a brand new library on the production branches is a pretty big risk. A breaking bobcats would break us, or if we remain pinned, set up nasty diamond dependencies.

I am very aware of this. I think for now we should treat it like blaze i.e. strongly dissuade other libraries from depending on bobcats while it stabilizes. Then bobcats can basically evolve in tandem with http4s.

The only place I think this should target is 1.0. And we should get a very very stable component first for bobcats

That's fair, but making this change only in 1.0 will make merges worse than the current situation.

And we should get a very very stable component first for bobcats

How do we know when it is "very very stable"? Thorough review? Genuine question, it helps to have specific goals to achieve.
Based on this feedback, maybe this bobcats experiment doesn't make sense for http4s after all. The two goals were to (1) simplify forward merges and (2) clean up the JS crypto mess currently in 1.0. But it sounds like the risks outweigh these positives and so maybe 1.0 should continue as it is now.

So I've been thinking about this, and still hope we can find a compromise that lets us achieve my goals (1) and (2) from above. IIUC yours (and my own) concerns stem from the fact that bobcats is an immature, external component.
In which case I propose we incubate bobcats as an internal http4s library (e.g. org.http4s.crypto or similar) make everything private[http4s], and not expose any interfaces. This would mitigate all the risks, while still achieving goals (1) and (2) while giving time for the concept to incubate.
Then, when 1.0 rolls around, if we feel confident about its stability, we could reconsider spinning it out as a separate typelevel lib. Or not! The goal here is first and foremost to simplify things for http4s.

Any new thoughts on this before the next release train? Ok if it's a hard no.

Private incubation seems reasonable.  As long as it doesn't leak into the public interface, using it to simplify the innards and prove a library sounds like pretty standard refactoring.

Cool, thanks. That's basically what I've done here anyway due to binary compatibility constraints. So, the only remaining question is: incubate as a module inside http4s/http4s, or inside yet another repo e.g. http4s/crypto? Obviously inside http4s itself is easiest, but it would mean (unused) JS crypto stuff would be living in series/0.22.

What do we gain over bobcats if it's in a separate repo?  That it's private[http4s] and can't introduce diamonds?  That's what we did with our parboiled2 fork for years, so I think that works.  It's basically an implicit MiMa exemption.

Yes. Isn't that kind of how blaze is working right now? It warns away external dependencies in the README with no promises of bincompat.

Blaze was presented as a standlone project through 0.14.  The original author left, and it had little uptake outside http4s, so I lopped off all the features that prevented an easy Scala 3 upgrade.  It's not so explicitly private to http4s as our parboiled2 fork was.  The safe way to do this is to ensure that the entire API is private[http4s].

I see. In any case we can keep all of this crypto stuff private and hidden through series/0.22 and series/0.23. Once we get to main, there is a more interesting conversation to be had whether it may make sense to expose some of those APIs but even there it's not strictly necessary.

Okay, I set up http4s/http4s-crypto.  Alternatively, we could just transfer typelevel/bobcats if it's easier.  If I understand everything right, they're going to be the same thing modulo packaging.

Thanks! I found it under http4s/http-crypto.

Alternatively, we could just transfer typelevel/bobcats if it's easier. If I understand everything right, they're going to be the same thing modulo packaging.

I would have said so maybe a couple weeks ago, but bobcats is already finding some uses outside of http4s. So triangle dependencies were a real concern. So unfortunately I think we'll have to live with the fork for now.

This is ready for another look. It uses the new http4s-crypto lib where everything is private[http4s] and thus exposes no internal APIs.

We'll do two release trains this week so I can stabilize the GHSA merges.


Move TimeSignature to rendering

This PR simply moves TimeSignature from musicxml to rendering in order to be more aligned with the intent of musicxml being a pure data library.

Draft: I need to write tests for the new musicxml.Time API.


update handlebars to 5.1.1

update handlebars version to 5.1.1

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


[US] Dockerize PostGOAT

MoSCoW
Risk
Story Points

Must
High
5

Acceptance Criteria
Risks

Requires reorganization of part of the stack's architecture (microservice-adjacent ish)
Need to have solid understanding of Docker - creating an image to publish on Dockerhub and to be used by others (fault-free)
Can be hard to define the expected behaviour since we are not yet super clear on the other moving parts (eg Postgoat website documentation and deployment, containerizing the application so that an application configurator may use it appropriately; how does an app configurator truly expect to use the platform?)

Pre-requisites

[x] Meet with the stakeholder to clarify the requirements
[x] Understand the types of users that will be involved - define their roles, what permissions do they have?
[x] Read Dockerization documentation (see links below) to ensure proper creation and deployment (risk of having to fix this later can have heavy consequences)

Tasks

[x] Read Docker docs about dockerizing a full stack app (https://milanwittpohl.com/projects/tutorials/Full-Stack-Web-App/dockerizing-our-front-and-backend)
[x] Create Dockerfile to define dependencies, base image, and any necessary configurations
[x] Create a self-contained docker image that has the front end deployed on it as well as all the required tooling (.sh scripts, and volume access to the "usecases") (created from dockerfile that uses an official base image + everything else needed)

Technically, the new dockerfile should be correctly written, but there is a lot of confusion relating to the way the new dockerfile should overlap with the existing dockerfile for the other three services using containers. The dockerfile as is should technically live in the root of the application platform, but there's a bit of confusion with the compose.yml file... The other issue is that we have to copy the services existing on the development side for the application configurators, which raises a few concerns for me/creates a bit of messiness.
Note that I had a couple of issues relating to the other containers, which need to be replicated for the application configurator.
TLDR; I'm still figuring out how I should package this new docker service so that I can publish it to Dockerhub and then just churn out use cases by using this custom image. In the meantime, here's the dockerfile as is, so that there's at least some sense of progress visible:

Second compose.yml with the new postgoat service added:

This needs additional integration and testing, as well as a better understanding on how to implement alongside existing compose.yml (existing containers).

Last minute changes made to existing containers, need to resolve and account for this in new compose.yml for the new service

Updates:

Had to change dockerfile into a multi stage build; ran into a bunch of issues when trying to run npm run build (tsconfig and viteconfig were missing some stuff and had a couple of errors in them like the build target version; this took an entire day to debug as you can read in these GitHub issues about:
https://github.com/vitejs/vite/issues/6985
https://github.com/remix-run/remix/issues/7969
). This along with having to modify parts of files that simply weren't respecting TypeScript rules and for which the dev environment was manually forced to allow, but this was not working during the build process obviously.
-I'm getting somewhere but keep running into the following issue:

Working on a couple of fixes; here's a few breadcrumbs relating to the issues I am having:
https://github.com/moby/buildkit/issues/4305
https://github.com/docker/buildx/issues/1079
^Most recent update (4 days ago) on the issue...

On the other hand, after almost two days of debugging, I finally managed to run a build to create JS out of all of our TS/TSX files locally! :D

This was the first step, because the image I have to create needs to be able to do this in a container, so it was necessary to get this working locally first.

MAJOR UPDATES!

The build files get created successfully, allowing the static web page to eventually be deployed using the minified js files inside of a folder called /build

I finally managed to successfully create the image container:

Got the container running!

Only issue is that it seems that the content of the web page is not displaying when I open localhost:8080 (it does however open correctly):

This US is pushed to Iteration 9, since we are missing the demo video, as our Stakeholder requested to keep doing the videos for sign-off.

Looks good! Signing off!

Included original software architecture diagram I had done for this story:


DateTime.TryParse behaving differently in IE11 vs Chrome

This code alerts false in Chrome (correct), but true in IE (incorrect):
DateTime date;
var culture = new CultureInfo("en-US");
Global.Alert(DateTime.TryParse("22/22/2222", culture, out date).ToString());

I haven't included a link to live.bridge.net because that seems broken for another reasons (amDesignator not found on undefined), which I suspect is due to being an old version. I tested this on latest code taken from GitHub about an hour ago.

The problem that IE considers that string as valid date. To avoid the issue I can suggets to use TryParseExact method
DateTime.TryParseExact("22/22/2222", "dd/MM/yyyy", culture, out date)
We will try to solve that issue


As an organised tutor, I can view which students I have in the day

... so that I know what to expect in the day.

Closed by #80


Support android-arm64

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

the linux arm64 binary should work on termux but I'm not sure how the gh cli would handle it maybe just publishing a copy of the binary with a different name would be enough.
relates to: #68

Just copying the binary and renaming it might not work in this case, see: https://github.com/golang/go/issues/8877

I've opened a PR for this. #137


Prometheus 2: no token found for scraping target

What did you do?
Set up monitoring side-by side Prometheus 1.x and Prometheus 2.x
What did you expect to see?
Identical set of active scraping targets.
What did you see instead? Under which circumstances?
Some scraping targets are down on Prometheus 2.x with exception "no token found".

Prometheus version:
prometheus, version 2.0.0-beta.0 (branch: master, revision: 2b5d9159537cbd123219296121e05244e26c0940)
build user:       root@fc24486243df
build date:       20170712-12:24:53
go version:       go1.8.3

After troubleshooting I discover that a problem is in label name. When metric has label which starts with underscore scraping fails. For example:
FAILS: DatabaseInvoker_MaxWorkers{_name="Main",} 10.0
OK: DatabaseInvoker_MaxWorkers{name="Main",} 10.0

A leading underscore on a labelname is discouraged, however it is supported.

Fixing.

Fix in https://github.com/prometheus/prometheus/pull/2961

Can this be closed?

@Gouthamve Thanks, yes, closing.
I don't understand why this issue wasn't auto-closed, since https://github.com/prometheus/prometheus/pull/2961 contained a "Fixes ..." mention for this issue in the commit and PR description.

That is because issues are closed only when merges happen into the default branch of the repo. I was also surprised and had to look the exact rules up.


Update ?

Is there any plan to update this repo ? With newer models etc ?

You're free to do that in your own copy or open a PR


Shorten hash produced by _create_violation_hash()

Using the latest dev branch, Cloud SCC is returning 500 errors due to the violation hash being too long. Cloud SCC is working on fixing this, but in the interim, @blueandgold and I have determined a 64 character hash does not produce the same errors. This should be sufficient to uniquely represent violations, but please verify before implementing.
https://github.com/GoogleCloudPlatform/forseti-security/blob/dev/google/cloud/forseti/services/scanner/dao.py#L371
We appended [:64] to the end of this return line, but that might just be truncating a larger hash and risk collision, so please investigate before implementing this.

We are relying on the current hash to determine uniqueness of violations and so this will break how we detect new violations.

Thanks Ramesh for letting us know your use case.  I will think about an alternate way of doing this, and make sure the change (somewhere) will work out for everyone.  :)

Fixed by #1803


Add support to azure-openai deployed models

Apparently Azure OpenAI deployed models can't be reached with the openai.OpenAI client instead it requires the openai.AzureOpenAI client which has a slightly different interface (see link for further details).
I was able to do what I needed by adding this rough solution in the "lm_eval/models/openai_completions.py":
@register_model("azure-openai-chat-completions")
class AzureOpenaiChatCompletionsLM(OpenaiChatCompletionsLM):
    def __init__(
        self,
        model: str = os.getenv("AZURE_OPENAI_DEPLOYMENT_NAME"),
        base_url: str = os.getenv("AZURE_OPENAI_ENDPOINT"),
        api_version: str = "2023-12-01-preview",
        truncate: bool = False,
        **kwargs,
    ) -> None:
        super().__init__()
        try:
            import openai  # noqa: E401
        except ModuleNotFoundError:
            raise Exception(
                "attempted to use 'openai' LM type, but package `openai` or `tiktoken` are not installed. \
    please install these via `pip install lm-eval[openai]` or `pip install -e .[openai]`",
            )
        self.model = model
        self.base_url = base_url
        self.truncate = truncate
        self.client = openai.AzureOpenAI(azure_endpoint=base_url, api_version=api_version)

Therefore, I believe that a more general/better thought solution won't require much effort.

Thanks Bruno. What task were you evaluating? I get this error when I run it with lambada_openai:
NotImplementedError: No support for logits.
I've heard that the azure code slightly lag the openai code so may not be surprise that something hasn't been implemented yet

wow its wonderful

vote for this!!

This OpenaiChatCompletionsLM has not been defined and needs to be rewritten？ @bcarvalho-via