Add a setting to mark file(s) readonly [nonEditable]

fix for: #161715 (and 98% of #4873; if we pull branch files-readonly-active with readonlyToggle then 100%)
see discussion at the bottom of that issue  for why this simpler approach; also a lot of edits required)
Enable users to mark files as readonly using include/exclude globs in settings.
(independent of OS-filesystem writability)
So users can avoid accidental typing/edits into files that are OS-writeable, but semantically intended to be read-only.
For example: build/tsc.out *.js files, log files, protogen output files, etc.
Test: open a text file ('foo.any'); observe it is editable/writeable.
In settings.json, add glob"files.readonlyInclude":  { "**/foo.any": true }  observe that Editor is marked readonly.
In settings.json, add glob "files.readonlyExclude": { "**/foo.any": true }  observe that Editor is marked writeable.

/assign @bpasero who I think is well placed to assess this  contribution.
@jackpunt endgame is about to start, so you may need to have patience.

John, thanks.
Q: should I know what 'endgame' refers to? and how much patience that requires?

https://github.com/microsoft/vscode/wiki/Development-Process#end-game
This is going to be the main focus of the team for the next couple of weeks.
After that the next iteration is likely to be the annual Issue Grooming which may delay adoption of this enhancement.

Ok. it's been waiting 6 years, a few more weeks is not a big deal.
Also: I notice that checkDidChangeReadonly() pro'ly should be marked private
What is the process to update the PR? (pretend I'm rusty on git and vscode approval process...)

What is the process to update the PR? (pretend I'm rusty on git and vscode approval process...)

@jackpunt make changes in your local workspace, commit it and push to update the files-readonly branch of jackpunt/vscode. It will show up on this PR as a second commit.

Thanks, John.
I privatized checkDidChangeReadonly
and removed true // from mouseHandler.ts (which i see now that @bpasero has already done...

@gjsjohnmurray you've been quite helpful here; maybe one more?
I see there's an error reported from vs/workbench/contrib/files/test/browser/fileEditorInput.test.ts:443
Can you say how I can run those tests locally?
[I'm a bit curious that the incrementing counter reports: -3 (being not === 1)
How does an event counter go negative ?? ]
Also: The changed count is not totally unexpected, since there are now 2 places checking for DidChangeReadonly.
As mentioned above:
I had code to integrate 'checkDidChangeReadonly' with the check in updateLastResolvedFileStat
(basically: take out the set&test in updateLastResolvedFileStat and just call isReadonly(); at the end of updateLastResolvedFileStat so it uses the new checkDidChangeReadonly()
I took it out of this mod, to keep it simple.
If I can get the tests running, I can see if that mod would resolve the changed count.

@jackpunt I suggest you install this extension:
https://marketplace.visualstudio.com/items?itemName=ms-vscode.vscode-selfhost-test-provider
Then click on the Testing icon (lab beaker) in your Activity Bar.
As for -3, I think you are misinterpreting this part of the output:

The minus prefix denotes that what follows is the actual, and the plus prefix indicates that what follows is the expected.

Thanks (and of course)
I also found: ./scripts/test.sh  --run src/vs/workbench/contrib/files/test/browser/fileEditorInput.test.ts

remove redundant test/signal in updateLastResolvedFileStat();
checkDidReadonlyChanged() now signals only once; test is passing.
(yarn watch died overnight [macOS died], so confused me for a long while that my changes were not having effect...)

@microsoft-github-policy-service agree [company="Individiual"]

the readonlyInclude/Exclude settings contribution was injected between
watcherExclude/Include; moved so watcherExclude is again adjacent to watcherInclude.

Given the extra time to learn...
I'll submit an update to format the include/exclude patterns using { [pattern: string]: boolean }
To be compatible with other files.*Include/Exclude
If someone can point to how to tell the Settings Editor to use "Add Pattern", I'll incorporate that also.

Note: I have another small mod that extends the logic of isReadonlyByPath().
This allows an extension to easily set/toggle the read-only status of a file
with a keybinding (like emacs's ^X^Q).
It's secondary to the glob-based semantic marking of this PR, but people asked for it.
Q: Would you like me to merge that into this PR? or do it as a separate PR after this one settles?
The mod looks like: (plus an entry in files.contribution.ts for 'files.readonlyPath')
  // stable/semantic 'readonly'; typically based on filetype or directory.
  private isReadonlyByGlob(): boolean {
    const readonlyInclude = this.configurationService.getValue<{ [glob: string]: boolean }>('files.readonlyInclude');
    const readonlyExclude = this.configurationService.getValue<{ [glob: string]: boolean }>('files.readonlyExclude');
    return this.anyGlobMatches(readonlyInclude, this.resource.path)
      && !this.anyGlobMatches(readonlyExclude, this.resource.path);
  }

  private isReadonlyByPath(): boolean {
    const settingName = 'files.readonlyPath';  // temporary override readonly for this file.
    const readonlyPath = this.configurationService.getValue<{ [path: string]: boolean | null } | undefined>(settingName);
    for (const key in readonlyPath) {
      if (key === this.resource.fsPath) {
        this.tmpReadonly = readonlyPath[key];  // can be set to null to disable
      }
    }
    return this.tmpReadonly === null ? this.isReadonlyByGlob() : this.tmpReadonly;
  }

  // tri-state: true | false overrides isReadonlyByGlob; null does not.
  private tmpReadonly: boolean | null = null;

@jackpunt I saw on the issue thread something about how this would behave with Remote SSH extension. I suggest you use https://marketplace.visualstudio.com/items?itemName=jrieken.vscode-memfs by @jrieken as a simple and self-contained way to play with a FileSystemProvider extension.

"This branch is out-of-date with the base branch"
Q: should I be using git to merge vscode (base branch) into my branch?

Hi guys, which release is this planned for?

@gjsjohnmurray

/assign @bpasero who I think is well placed to assess this contribution.
@jackpunt endgame is about to start, so you may need to have patience.

Are we still waiting for the endgame?

@bpasero @gjsjohnmurray Good morning,
If you find the time, could you give and update on this one?
Would be nice to have it in the next release if possible.
I know you are busy people so this would be much appreciated.

I really need it

@bpasero.
Thank you for your comments, please let me know how to proceed.
I suspect that confusion continues between "read-only files" (aka non-writeable) where we deal with file system operations
And "read-only editor" (non-editable buffer) independent of the files-system status of the underlying file.
Likewise, comment about other component to make changes to the file:
--> THIS PR IS NOT ABOUT PROTECTING the FILE <--
This PR is about protecting the buffer from being modified.
Perhaps this PR is mis-named... should be: "Add setting to mark a buffer non-editable" ??
[I come from decades of Emacs, so the distinction between file & buffer is explicit,
but in VS Code, there is less documentation about 'buffer'... but I infer that is the "Model" ?]
A priori, the linkage from FileSystem.Readonly to the editor was in textEditorModel.isReadonly() so that seems to be the right place to extend to include non-file-system "readonly-ness"...
(So that's why this PR is focussed on the textEditorModel)
(altho: the full/companion branch (files-readonly-active) includes a patch that propagates stat.mode to set FilePermission.Readonly so textEditorModel.isReadonly() can dynamically sync with FileSystem.Readonly)
Seeing prior feedback about "too much core modification", in this PR we avoid trying to boil the ocean.
I suggest: If other file/model types have a problem with inadvertent/unexpected user mods to the buffer/model, those "custom editors" can solve that problem if/when it becomes documented.
THIS problem, with textFileEditor being inadvertently modified by keystrokes, etc. has been documented for 7 years...
If there is an Issue that speaks to Workbook and/or Custom editors, link it and maybe it can be addressed...
(since the documents for Custom Editors include how to make "[Readonly Custom editors]
(https://code.visualstudio.com/api/extension-guides/custom-editors#readonly-custom-editors)", i suspect that is not a problem)
All that being said, if you point to a code-block/location that is more appropriate than textEditorModel.isReadOnly() to achieve the goals of #4873, then I'll see if this mod can be made to work there.

If the setting is only for marking a text editor readonly, then I think the setting name needs to reflect that. Settings on the level of file.* are typically applied in many contexts.
A different approach for applying the setting is to set it on the level of the editor control itself instead of the model. Setting it on the model will prevent certain operations from being applied that do not go through the editor by the user, for example global search & replace operations. Relevant location in code would be:
https://github.com/microsoft/vscode/blob/d1f42f4857c638aa1580f0ea6d0855618f7d47ad/src/vs/workbench/browser/parts/editor/textEditor.ts#L252
Just to set some expectations: we are in issue grooming iteration (see https://github.com/microsoft/vscode/issues/167999) and part of it is to go through PRs and triage them. That does not mean all issues associated with PRs are being resolved as well this month. There are almost 200 comments in https://github.com/microsoft/vscode/issues/4873 and to be honest, I did not go through any of the comments so far except the first opening statement. If consensus of that issue is to have a setting for marking a text editor as readonly based on a file path, then this approach seems OK to me, pending the consideration of applying it to the editor control and not the model. Is there consensus?

Ok, thanks for your explanation.
In regards the 200 comments of #4873, that is why I made #161715; to focus on the relevant issue and solution.
The setting was named "file.readonly*" because the intent is to identify files that may be file-system-writeable, but which the user wants to protect from [inadvertent] editing. (for example: ./node_modules/** or dist/**/*.js or whatever)
[For ex: the problem of "go to source" and then spend time editing the .js instead of the .ts file]
For "discoverability" it seemed to make sense to name the settings with "file" and "readonly",
but that can easily be changed if there is a better place to put them.
The approach for this PR is derived from distilling the requirements from the lengthly discussion/comments in #4873.
The comments (of #161715 or #4873 post-Sept) especially from the 'early adopters' indicate that this approach [a setting to identify file-blobs to treat as readonly] is providing the desired feature.
[I don't have your depth of knowledge to differentiate the 'editor control' vs 'editor model', but preventing global search/replace and refactor/rename from operating on the designated files/buffers would be correct.]
I know your time is limited, so you won't likely spend the time to read all the comments (and as this was my first PR, i likely over-explained/commented...) but if I can help interpret the design/intent just let me know.
.
The follow-on PR/branch (files-readonly-active) extends the declarative settings/blob with an "interactive" setting and a keybinding/extension to set/toggle the model.isReadonly() attribute.

Actually I think having this in the model or the file service is better than having this in the editor control for this reason: if you do an operation such as "Peek References", the embedded editor that opens also should be readonly and it would not work if we did what I had suggested when going via editor control.
There is an interesting problem though that I did not have the time yet to fully investigate: some operations such as search/replace or even extensions may alter the text model directly, bypassing the readonly checks we have. In other words, even though the text file model is declaring to be readonly, if the underlying editor text model is directly changed, we do not prevent this. The readonly flag in the text model was mainly meant to block typing in the editor or use editor operations within the editor, but not to block modifications that go through other code.
Another interesting challenge is that even though we may be offering a setting to mark files readonly, we need to adopt this in all editors that allow for editing. Changing it in textFileEditorModel makes it work for text editors. However documents can also be edited with other editors:

notebooks are using storedFileWorkingCopy which is similar to textFileEditorModel
text based custom editors will run with a textFileEditorModel but may not respect the isReadonly flag
non-text based custom editors are fully controlled via extensions

Since we cannot control extensions, maybe the setting needs to be very specific only for text editors, but then it could never be called as generic as files.readOnly imho.

Ack and agree: this PR only addresses the issue to 'manual' text editing.
If you can suggest a better name/place for the settings, let me know and I'll update the PR:

files.readOnlyTextInclude & files.readOnlyTextExclude
files.noEditTextInclude & files.noEditTextExclude
textEditor.readOnlyInclude & textEditor.readOnlyExclude
readOnly.textFilesInclude & readOnly.textFilesExclude

Or whatever would fit with your existing conventions.
[I don't expect that the folks who requested/use this feature really care what the settings are called]
--
wrt "not boil the ocean": if there are programatic ways to modify a buffer/model which do not respect model.isReadOnly(), I suggest it is not necessary to solve that at this time.

The readonly flag in the text model was mainly meant to block typing in the editor or use editor operations within the editor

Which is the feature requested in #4873/#161715 ;  we are trying to staunch the 7 year-old bleeding wound and allow users to declaratively protect themselves from editing certain files.
(Note: #4873 does not contain comments of the form: "I wish I could block [SomeExtension] from modifying my text" nor "I want to prevent notebook from modifying my ./node_modules files" )
--
Also: the joy of time-zone differential between Zurich & Cali...

How long will it take for this measure to be completed? Sorry, I'm getting a little hasty, but this feature will be a huge help in reading code. I'm sure there are many, many others waiting for this feature. Again, thank you very much for your work to make vscode more perfect!

I am waiting for guidance from @bpasero (on #169782 ) regarding how to integrate filesystem non-writable files, and how to name the various related settings.
The coding is simple, but naming and user-interface takes some discussion.

notebooks are using storedFileWorkingCopy which is similar to textFileEditorModel

This code looks identical to the original code in textFileEditorModel;
I will make a new PR (or extend this PR?) to apply the same modification to storedFileWorkingCopy

text based custom editors will run with a textFileEditorModel but may not respect the isReadonly flag
non-text based custom editors are fully controlled via extensions

Custom editors will choose whether to upgrade and include nonEditable support
(it's fairly easy to include the globReadonly check)
[I expect that would mostly be for consistency rather than due to documented pain from users]
Please let me know how you want the settings to be named.

Q: Is the duplicated (copy/paste) code in textEditorModel and storedFileWorkingCopy intentional / desired?
Is there a place where we could put the common code? [DRY]
(a BaseFileEditor or such?)

How about if I make: readonlyHelper.ts with class ReadonlyHelper
Which contains the common code for watching file status and the readonlyInclude/Exclude globs, etc?
Then any EditModel/WorkingCopy could just create/initialized its own instance, and
isReadonly() { this.readonlyHelper.isReadonly(); }
does all needful.
Would that be a satisfactory/better solution?

Using a ReadonlyHelper makes the PR much cleaner/smaller.
Now there are a few lines in TextFileEditorModel (and the same few lines in StoredFileWorkingCopy)
to import, create and use a _readonlyHelper instance to check/track both file stat.mode and files globPatterns
isReadonly() returns true to indicate if the editor is to be treated as nonEditable
Should be likewise easy for custom editors to share the code/functionality.
@bpasero let me know if there are name changes to be done (setting names or to relocate readonlyHelper.ts)

Per comments in issue 17670
This PR now supports

implicit detection and marking of readonly disk files.
legacyReadonly setting (so readonly files are editable and can use chmod/sudo to unlock/overwrite)

With that resolved, I expect we should also merge in the file-readonly-active branch and include key-bindable commands to a user can easily/dynamically change/toggle the apparent readonly-ness of a file

Another 2 months...
What should I/we be doing to get progress/feedback on this PR?
I'm new here, so don't know the process; but other than repeatedly sync'ing with the base, what should I do?
@bpasero

Benjamin, thanks for getting back to this.

the readonly state computation is here implemented on the level of text file models and working copies and thus will only apply in an editor...
Yes. The issue is really about making the editor/buffer 'editable' or 'not-editable' (based on the file/path name [and chown stat]); but the pre-existing terminology/code uses the phrase "readOnly" (which historically refers to the filesystem stat) so that is intrinsically confusing. If the original settings and variable names had been "editable" rather than "readOnly" this would all be much easier to describe.

FilePermission.IgnoreReadonly and legacyReadonlyStat:
Ok, yes; that is just historical artifact: IgnoreReadonly came first, as a way to regularize/legitimize the historical way that diskFileSystemProvider ignores the stat.mode and allows/makes the buffer be 'editable' in all cases. Based on comments that some people/code may rely on the default edit-ability of all diskFiles, I added the legacy setting; it keeps the concepts orthogonal:
IgnoreReadonly is a feature of the FileSystemProvider; legacyReadonlyStat is a feature of the user/environment.
If you are ok with hard-coding the intersection of the two into the diskFileSystemProvider and fileService, I'll code it and see if there are any unforeseen problems.

when both include and exclude settings are present and there is overlap, which setting should win? can we start with just 1 setting?
I thought it was a common Include/Exclude pattern (from git, tsc, ...): Includes are applied first and then Excludes are checked. I wanted to be thorough/flexible... allow: '**/*.ext' are non-editable, except in these directories; or files in dir are non-editable, except with this name or extension. That's hard to without Include and Exclude.  Maybe we can hit 80% with just the Include (eg: './node_modules/**', './dist/**')
If it is really important to pare it down, can we: Commit to providing the interactive command/keybinding extension?
So that exceptions can be toggled interactively, on-demand.
--   Note: that feature uses another setting [generally unseen by users] to record the indicated files/editors.
--    (A keybinding also makes the legacyReadonly setting generally unnecessary; just press the key-chord to edit)

Looking at ResourceGlobMatcher; That looks promising, esp to elide/provide the workspace path. Wishing there were docs on its usage... the code mentions 'globalExcludes' and 'updateExcludes'... Is 'excludes' is just a name vs something semantic?  will ResourceGlobMatcher will also match to 'Include' things? (if, per above, there is only one setting, it will be Include) What is expected of the globFn?  how is the (root?: URI) used? is the returned IExpression the globPattern? what are siblings?

I'll happily to do the necessary hacking, it will be good to have your continued guidance and requirements/constraints.

FilePermission.IgnoreReadonly and legacyReadonlyStat

Ah! here's the problem:
For most/other fileService: stat.Readonly is honored, it is only diskFileService that ignores stat.Readonly and allows the editor to be 'editable'.
If we have a single flag (like legacyReadOnly) then code in fileService.throwifReadonly() needs some other way to detect that it is working with diskFileService.
The extra bit (FilePermission.IgnoreReadonly) is how we mark diskFileService as 'special'...
I don't see a way to otherwise override that private method.
We could do without 'legacyReadonly': forcing it either true or false:

true: editors will always and for everyone open chmod-readonly files as Editable
(which was the complaint that spawned #4873)
false: leads to  your concern:
Historically, one could edit and then try override the file-permissions when the Editor is written back to disk.

With a keychord/command to toggle 'editable', the second (false) case is negligible, would that be better?
If we commit to a keybinding/command/extension to rapidly toggle the editable state, then we don't need legacyReadonlyStat

Providing a brief answer here because we are going into endgame mode, testing for the next release:

can you please figure out how ResourceGlobMatcher works based on other usages we have today (e.g. files.exclude), it should be easy to understand and adopt
I still think a setting such as files.legacyReadonly (with a different name) makes sense to have, specifically for a user to configure if a readonly file on disk will open readonly in the editor (new behaviour) or not (old behaviour), but my hope would be that we can implement this in the disk file system provider conditionally by checking on the setting and then setting FilePermission.Readonly based on that without having to introduce a new permission
I am still going back and forward on whether this should be implemented on the file system or the model: the advantage of implementing this in the file system is that it will just work in a lot of places: working copies, text models all respect it. even the file explorer will not allow you to accidentally delete or move a readonly file. and search/replace would also refuse to work. this might make the change much smaller: we "only" need to bring the conditional readonly state into the file service [1]

[1] there is a bit of a layering issue with file service
File service and disk file system provider cannot depend on the configuration service as you maybe already figured out: because we need the file service to read the configuration... but maybe the file service could expose a method to set a "readonly helper" that it can use to detect readonly state based on settings. so essentially we would pass in a helper to file service to compute readonly state, similar to how you now have that for working copies?

About ResourceGlobMatcher:
RGM happily registers listeners to track when a given configuration changes,
and then, on demand, one can test if a given URI matches a Glob from the latest settings/configuration.
Note: both RGM and ReadonlyHelper listen/respond to event.affectsConfiguration('files.readonlyInclude')
Can we control which gets notified first?
ResourceGlobMatcher needs to be done before RH .matches the new Globs.
I'll expect/rely that the first added listener get evaluated first.

Yay! converted glob matching to use RGM and it works, and workspace-relative paths 'just work'.
I'm not doing anything with (root?: URI) or .NO_ROOT
LMK if there is something that should or needs be done with those.
Note: RGM needs a contextService, and since ReadonlyHelper is subordinate to where it plugs in,
the constructors for diskFileProviderService and storedFileWorkingCopy (and its tests and Managers)
have been extended.
Next up: try access 'diskFilesAssumedEditable' setting from fileService via ReadonlyHelper.

Ok.
With FileService.throwIfFileIsReadonly() checking FileSystemProviderCapabilities.Readonly, diskFileSystemProvider can do as the other FileSystemProviders and righteously set:
	permissions: (stat.mode & 0o200) === 0 ? FilePermission.Readonly : undefined,
and it all works as desired: chmod -w files do not throw, and can be made editable, and later try unlock; so YAY!
ReadonlyHelper now uses ResourceGlobManger to track and match the readonlyInclude/Exclude globs.
and watches 'files.ignoreReadonlyStat' to determine whether files that are not mentioned in the Globs should open as Editable or non-Editable. [ FileSystemProviderCapabilities.Readonly still vetoes all of that, being always readonly.]
The ReadonlyHelper plugs into EditorModel/Working copy, but per above, that seems to be a good approach.

I did a little test how VS Code behaves when readonly is configured on the level of the file system and not on the working copy / model

the explorer nicely prevents edit operations which I like (reported https://github.com/microsoft/vscode/issues/180999 as a bug to improve)
search & replace seems to not require the readonly bit on the file system, but the behaviour is very strange (reported https://github.com/microsoft/vscode/issues/181000)

I believe the only change that is needed to make this work with a setting is to set readonly to true based on configuration here:
https://github.com/microsoft/vscode/blob/d6290ef6582acecbf3bca1558111f2ee64375801/src/vs/platform/files/common/fileService.ts#L251
You are right that the file service and disk file system provider is used in many places and many processes. Here is what I have in mind:

we need a new method on IFileService to set the "readonly helper" which essentially allows the file service to ask it if a given resource is readonly or not and it would be used only in 1 place here
to simplify things, I am fine introducing a new FilePermission that the disk file system provider can use to signal the readonly bit on disk, maybe we call it WriteLocked? because I think that is the terminology used when it comes to saving these files. the "readonly helper" could then additionally report readonly: true when the setting is enabled

Does that make sense?

Firstly, thanks for all the detail.
That gives a much clearer picture of where you are heading.
[and why doing it at the filesystem layer is important/worrisome (#181000)]
I'll try again with to inject ReadonlyHelper:
Now that diskFileSystemProvider is "doing the right thing" and setting the stat.Readonly bit,
(and we check FileWriteUnlock to indicate that readonly is/may-be overridden, I don't think we need another bit),
and you are looking to inject into FileService (vs into the DiskFileSystemProvider),
and with the pointer to workbench.startup(),
I try today to see if that is doable.

Does that make sense?

I'm trusting that when I get into the source, I'll be able decode your hints and hopefully then it will all make sense ;)

Your proposal is to include the readonlyGlobStatus(resource) into the fileStat, so everyone sees the same write-ability.
Note, the "Big Issue" is not about where we test for readonly, it is about when we test for readonly.
That is: FileService computes fileStat.readonly from provider.stat(), and re-stats when a file changes state/mode.
On each stat(), VScode updates the write-ability of the given file (or files in a directory or whatever)
And that 'stat' is constant and reliable until the next filesystem event.
Presumably, each 'user' of fileStat.readonly relies on that bit being up to date.
(Q: do they request a new async stat() before using? if so, then all is well... but I expect this is not the case.)
The problem:
When the readonlyGlobs are changed, the IFileStat.readonly bit is obsolete.
It works for Editor.isReadonly() because each ReadonlyHelper is notified of the Settings change,
and Editor.isReadonly() is based on the resource's last globReadonly and the lastResolvedFileStat.
If we had a similar method: IFileStat.isReadonly() it could likewise merge file.permissions.Readonly with the latest configuration of the readonlyGlobs.
In the current code body, IFileStat.readonly is not a get() accessor that we can interpose on.
It appears the IFileStat is an object interface without a class...
Happily, that code point in FileService appears to be the only place with "IFilestat = {",
so maybe it will suffice to extend IFileStat and include IFilestat.isReadonly() => boolean
(which function will utilize the callback into a ReadonlyHelper)
That is: rather than providing only a 'bit' that may get out-of-date, we provide an accessor function that dynamically computes the current/correct value. (and the same logic used by Editor/WorkingCopy)
#181000 demonstrates that a cleanup is anyway required; so eventually changing those to use filestat.isReadonly() instead of filestat.readonly is no extra burden.

Ok. A dynamic IFileStat.isReadonly() is done; code is in files-readonly-active branch; still to be 'optimized'...
Using a callback to the ReadonlyHelper logic and the readonlyGlobs.
[If you want to set the readonly bit to reflect a snapshot with the readonlyGlobs,
that can be done, but it seems like asking for trouble.
OR? if the IFileStat object, once returned from FileService is never cloned?
Each Open Editor's RH has a pointer to the lastResolvedFileStat and could update the bit;
If that is the value that everyone will see, then that would work;
if we change IFileStat.readonly from itself being a readonly field...
I don't know the internal protocols and invariants; but this seems unlikely in an IPC world]
Anyway, the current code surfaced two questions:

Is there a map from resource: URI to Open Editors? (sure there is, where do I find it?)
because: some Editors may have transient readonly state that is not in the readonlyGlobs.
If the IFileStat.isReadonly() can peek into an Open Editor's RH, it can get the correct/current state.
For files/resources that do not have an Open Editor, the correct state is determined only by stat & readonlyGlobs.

ReadonlyHelper only needs singleton RGMs for tracking the readonlyGlobs,
with each RH just listening for the onExpressionChange callback to the RH instance.
Can each RH simply: this.disposables.add(rgm.onExpressionChange(onChanged));
and the disposables will all auto-magically unwind?

@jackpunt I think even today, when a file system provider changes its decision whether a file is readonly or not, we do not update any of the opened editors to indicate as such. So maybe we treat that as a separate feature and take it out of this PR. I think there are some interesting questions how to apply such a change to opened editors, esp. the ones that are dirty.
We have some settings that - when changed - require a restart of VS Code to take effect and we could treat changes to the new settings similar. Even though that is not the nicest user experience, it is a workaround for now and would match the behaviour we already have today without the setting.
When I was glancing at your changes, I would have expected no more changes needed to the working copies and text file model code, and the changes being scoped only to the file service and disk file system provider, or am I missing something?

When I was glancing at your changes, I would have expected no more changes needed to the working copies and text file model code, and the changes being scoped only to the file service and disk file system provider, or am I missing something?

Ah... probably I was missing something: your intent to start a new branch from the base code.
To 'undo' the extraction of common code from WorkingCopy/EditModel into ReadonlyHelper?
If you want to have the smallest code delta, we can go that way.
I'll make a new branch...
Q1: where in the source tree should I place the FileService's ReadonlyHelper.ts?
Q2: where in the runtime do we inject that ReadonlyHelper into the FileService?
-- I'll pick something, but you will likely have a better answers.

when a file system provider changes its decision ... we do not update any of the opened editors to indicate as such. So maybe we treat that as a separate feature and take it out of this PR
In this case, changing the readonlyGlob settings is more user-oriented, real-time feature than a "when a file system provider changes its decision", so giving immediate/visual feedback is part of the fundamental feature request.

When the readonlyGlob settings change, it [should be] easy/possible to map over the Open Editors to see if the 'isIncluded/isExcluded' has changed for a resource, emit an event ("as if" user had used chmod to alter stat)
Maybe have a listener/entry-point that knows to update FileStat.readonly without doing async stat(), and fire onDidChangeReadonly.

Now (I believe) the code has the minimum impact you were envisioning:

diskFileSytemProvider sets permissions.Readonly like every other provider.
but [still] asserts Capabilities.FileWriteUnlock.
FileService uses Capabilities.FileWriteUnlock to 'ignore' that Readonly bit
for toFileStat() and throwIfFileIsReadonly()
FileService uses the readonlyQueryFn to refine IFileStat.readonly
When instantiated, ReadonlyHelper injects its readonlyQueryFn() into FileService.

Open issues:

How/Where to instantiate ReadonlyHelper?
ReadonlyHelper registers itself using registerSingleton(..., Delayed)
To test, I hacked WorkingCopyManager to require instantiation of ReadonlyHelper (and that worked).
constructor(@IReadonlyHelper ReadonlyHelper: IReadonlyHelper) { super(); }
Did not commit it because it changes the signature for all the tests.
Q:  Is there a way to kick the InstantiationService to say: now instantiate a given [delayed] service?

This minimal form does not update the Lock icon until the Editor is focused.
VScode is already aggressive about re-stating things when settings are changed.
Not completely sufficient to resolve #4873, #161716, but provides a milestone checkin.
Next steps are the code to provide notify the GUI and also the interactive/command support.

LMK what you think.

Thanks, I think at this point I want to do some hacking myself for this feature to see what I feel is the best solution. In my mind I am still moving back and forth between putting this into the model/working-copy or the file service. While the file service solution is elegant, it is also a bit strange and hard to wire in:

we have no real support to report changes to readonly state (as you already figured out)
it is somewhat weird that a user setting could have such a big impact on the workings of the file service which so far is working as you would expect based on the file system provider implementation
the file service is instantiated in almost all our processes so we would need to wire in the setting into all these processes

Sorry for the back and forth, I will report back when I concluded my hacking, I cannot make any promises when this is going to happen though. I will try to lobby this into the May plan if possible.

:)
You had mostly convinced me that setting the IFileStat was ok/good/correct.
The previous approach made it easy for the WorkingCopy/Editor to _onDidChangeReadonly.fire()
which would update the lock icon. [through some chain of events which I cannot reproduce]
That is valuable/required for the interactive Command, which changes the [user/glob based] 'readonly' of the currently focussed Editor; seeing the icon flip is reassuring/necessary. Especially for the 'toggle' option.
I hacked a way to [try to] _onDidChangeReadonly.fire() in the current approach, but it does not propagate the same way as before. I'll guess it has to do with being in the wrong one of those many processes...
The more I've seen of VScode, the more I'm amazed that you can keep the architecture in your head!

Good news, the feature to mark files as readonly will be part of our May plan 🚀.
I am quite happy with https://github.com/microsoft/vscode/pull/181708 so far. It supports:

settings for readonly include and exclude as glob patterns
a setting to control if a readonly file on disk should be detected as readonly
events are wired in so that editors update live when changes occur

Things that are missing or might change:

tests!
do we really need a include and exclude setting?
how can we built a command to toggle readonly state properly [1]

[1]
We can easily add commands to add a path to settings for marking it readonly or not. But what if a setting exists that is more generic than a file path? For example, I may have a files.readonlyExclude: **/*.md, so adding the absolute path to the files.readonlyInclude setting would not work, given the override. I am open for ideas here, but I would not really want to introduce an in-memory state that is not backed by settings.
One idea would be to detect that toggling did not work and inform the user to check in settings.
@jackpunt happy for your feedback on the PR if you want to try it out. Now that I have spend some hours on this task and see my changes I realise that I would have had a hard time to give you this kind of feedback just by reviewing your code. So going forward, I would merge my PR and leave this one be, but since you started the effort I would want to make sure to have you mentioned in our release notes once we ship this 🙏 . I hope that is OK with you, but please let me know otherwise. Thanks for continuously pinging me on this effort.

Indeed, you clearly see more touch-points than are dreamt of in my philosophy; happy to transition to your PR.
About the Command and 'state':
The intent of the Set/Clear/Toggle/Ignore Command is exactly to temporarily override the Glob/settings.
It is a convenient way for the current user to say:
"I know the setting say this file is marked [one way or the other] but I want to override that for now,
and put it in the state I'm specifying (by a keystroke, not by editing a settings file directly)"
Note: Emacs has had ^X-^Q (toggle-readonly) for decades, it is widely used, and does not cause confusion.
The approach I used to transmit the user-intention from the front-end (extension host?) to the back end
was to set a value in the user settings. That was sufficient to trigger an event, and allow the processing to proceed.
If there is a more direct way to send and event a token for the 'current editor', that would obviously be better.
[But for my naive approach, putting the absolute path of the current file in the setting file did suffice.
We remove/overwrite that setting (vs appending) so the setting file does not grow to infinity with a history of every time the Command was invoked; that history is not interesting 'state']
Given the notification of [Editor + State] it also suffices to set/keep the result "in-memory".
Because: it is set by a keyboard command, so if the editor goes down and back up, the user can still see the 'lock' icon and hit the keystroke to return it.  That is why it was called "readonly-active", the user is interactively telling the Editor to set the state.
(users that want 'survivability' can edit the durable readonlyInclude or readonlyExclude, but that gets tricky for many reasons [esp without Exclude])
If you are Ok with using the signaling path from Extension through Settings to onDidChange,
then I'm inclined to advocate for accepting the 'transience' of the setting;
In computer-sciencey terms: it is an Event vs a State.
I'll load up your PR with my Extension and maybe say more after I see the look and feel.
...
About Include & Exclude: TTBOMK, regexps/globs do not have a user-friendly way to express exceptions to a general rule.
So doing the general rule as the Include and then, if/when necessary adding the exceptions is very general.
Is your question: Are there sufficient/interesting use-cases where an Exclude/exception is necessary?
A) I think so.
B) I would not want to find out post-release that users need/expect the Exclude globs and suffer their complaints until an even later release.  (but since you are in charge of what gets released, and the overhead for that, you may decide otherwise...)

Indeed, you clearly see more touch-points than are dreamt of in my philosophy; happy to transition to your PR.

Thanks 🙏

Note: Emacs has had ^X-^Q (toggle-readonly) for decades, it is widely used, and does not cause confusion

And my PR provides something similar, through a change in settings. We could in theory change this to only operate on the current session and not having it in settings, but I would think that users most likely want VS Code to remember this choice even between restarts and settings is currently the best approach to achieve that.

TTBOMK, regexps/globs do not have a user-friendly way to express exceptions to a general rule

Yes, currently. We have https://github.com/microsoft/vscode/issues/134415 that discusses a way to configure both excludes and includes from a single glob pattern, but we are not making progress there in the near term. I think as such I will keep having 2 settings for readonly includes and excludes.

And my PR provides something similar, through a change in settings.

My original implementation did that; but after seeing a dozen notations accumulating in the setting file, I changed it be self-deleting. But not a big deal either way.

I think https://github.com/microsoft/vscode/pull/181708 is good to be merged, will discuss this week with the team. If you have any feedback from trying it out, let me know. I would also ask for feedback in https://github.com/microsoft/vscode/issues/4873 once we have an insiders build with this change.

@jackpunt wow that is a great catch and kudos to spotting that 👍 . Thinking about it more, I am fine to going with your suggestion, given it seems to be standard practice in other cases such as TypeScript.
I pushed https://github.com/microsoft/vscode/commit/350797fa990f4e22b132533d3dc0c4c4bd9f7e77 to change that.
Let me know if you need help running the PR.

[After a 'yarn' to get something of typescript updated, it compiles]
Runs from scripts/code.sh, but does not start from "Run and Debug" |> VS Code
I'll pull your update and try again.
Can you say what is the command (or whatever) to toggle/set/clear the abs path?

After viewing async updateReadonly(resource: URI, readonly: true | false | 'toggle')
Another comment: updateReadonly(false) is not the same "remove readonly setting"
In the original, there were 4 values: true, false, 'toggle', and null (or any other token to indicate 'remove')
The point being: sometimes you want a toggle or 'false' to override chmod -w, or readonlyInclude/Exclude
And then later, you want to rescind that and get back to the usual/default value,
and at that point you would updateReadonly('remove', ...).
Likewise, updateReadonly(false,...) needs to be retained so it continues to override a readonlyInclude/Exclude setting;
the current code appears to save 'true' values and remove all 'false' values.
I haven't [yet] looked into configurationService.inspect()
After viewing async updateReadonly(resource: URI, readonly: true | false | 'toggle')
Another comment: updateReadonly(false) is not the same "remove readonly setting"
In the original, there were 4 values: true, false, 'toggle', and null (or any other token to indicate 'remove')
The point being: sometimes you want a toggle or 'false' to override chmod -w, or readonlyInclude/Exclude
And then later, you want to rescind that and get back to the usual/default value,
and at that point you would updateReadonly('remove', ...).
Likewise, updateReadonly(false,...) needs to be retained so it continues to override a readonlyInclude/Exclude setting;
the current code appears to save 'true' values and remove all 'false' values.
The original code was like this:
    const configName = 'files.readonlyPath';
    if (event.affectsConfiguration(configName)) {
      const readonlyPath = this.configurationService.getValue<{ [glob: string]: boolean | null | 'toggle' }>(configName);
      if (readonlyPath !== undefined) {
        const pathValue = readonlyPath[this.resource.path]; // <--- find setting for this resource
        if (pathValue !== undefined) {
          if (pathValue === 'toggle') {
            // must modify settings, so subsequent 'toggle' will be seen as a change:
            this.pathReadonly = readonlyPath[this.resource.path] = !this.oldReadonly;
            this.configurationService.updateValue(configName, readonlyPath, ConfigurationTarget.USER);
          } else {
            this.pathReadonly = pathValue;
          }
        }
      }
    }

Doing it all in files.readonlyInclude will be trickier, use updateValue to set/update a single "key": "value" pair.

About isReadonly() {...} I foresee a problem.
It appears that if configuredReadonlyFromPermissions is true,
then there is no way to make a chmod -w file editable?
The intent was to see the file initially/default as non-editable,
but a user could toggleReadonly (or set readonlyInclude Glob)
to obtain the "let me edit and I'll try to override the file-mode"
I don't exactly what stat?.locked implies, but the doc says:
"... editors should offer to edit the contents and ask the user upon saving to remove the lock"
But it appears that isReadonly() will always be true, so the user cannot edit the contents... ?
The #161716 logic was like:
isReadonly() {
  if (is a readonly Provider) return true;
  if (specific path is specified, from the Command) return the specified value;
  if (readonlyInclude matches) return that value, as modified by readonlyExclude;
  if (configuredReadonlyFromPermissions == false) return false; [the 'legacy' behavior]
  else return value from actual stat.readonly bit;
}

#181708 code:
  isReadonly(resource: URI, stat?: IFileStatWithMetadata): boolean {
    if (this.configuredReadonlyFromPermissions && stat?.locked) {
      return true; // leverage file permissions if configured as such
    }

    return this.readonlyIncludeMatcher.value.matches(resource) && !this.readonlyExcludeMatcher.value.matches(resource);
  }

The previous comment exposes another concern:
Including the Command value in the readonlyInclude setting
means that the Command value can be overridden by the readonlyExclude setting.
To continue the original example, with workspace settings:
"readonlyInclude": '**/foo/*, **/bar/*' , "readonlyExclude" '**/*.ini'
A user will find it difficult to set or toggle '**/foo/example.ini'
My answer was to use a separate config setting name for the Command.

@jackpunt good stuff, I have pushed https://github.com/microsoft/vscode/pull/181708/commits/1976534ef31b4e87ff954ca5452fc1fed40bba88 to address your feedback.
For one, the configuration is ignored for children of userRoamingDataHome where settings are stored. Even if you configured e.g. **/*.json to be readonly, you would still be able to edit settings file.
Furthermore, I have rethought the commands to toggle readonly state ad-hoc and made them NOT write to settings anymore. Instead, they update an in-memory set of resources that are either readonly or writeable for the duration of the session. I think you have rightfully pointed out that writing to settings and thus changing user preference is quite tricky to get right in this case here. If a user really wants to persist readonly configuration, the user has to go through settings her/himself.
Let me know if you find out more 👍

I just now saw your response!
As I came here to point you to my work: https://github.com/jackpunt/vscode/tree/ben-readonly-files2
I still don't know what your configuredReadonlyFromPermissions && stat?.locked does, exactly,
but the other bits mostly work as I expect
I added the new setting for the Command override.
and added , ConfigurationTarget.USER where needed.
now I'll go look at your update...

I still don't know what your configuredReadonlyFromPermissions && stat?.locked does, exactly,
but the other bits mostly work as I expect

I added a new FilePermission.Locked to convey the information of a file on disk having permissions configured that do not allow for writing. This is intentionally different from the existing FilePermission.Readonly: a locked file can still be edited in an editor and upon saving you get a notification asking to remove the lock and try again.  There is a new setting files.readonlyFromPermissions that you can use to make the editor readonly. This is essentially the fix for https://github.com/microsoft/vscode/issues/17670

Hmm, I might still want the ClearActiveEditorReadonlyInSession command

Yeah maybe it would be better if I tracked the in-session state in a Map as well that you can clear, I can look into that.

@jackpunt change https://github.com/microsoft/vscode/pull/181708/commits/97be614d5b98d497aff5716d2cd938ea0cfeaab5 introduces a new command to reset the readonly override and uses a ResourceMap for that purpose as you suggested.

Wow!
I think that now covers all the functional requirements.
(although I haven't yet tested all this)
One stylistic bit: in files.contributions you have:
    [FILES_READONLY_EXCLUDE_CONFIG]: {
      'type': 'object',
      'patternProperties': {
        '.*': { 'type': 'boolean' }
      },
      'default': {},
      'markdownDescription': nls.localize('readonlyExclude', "Configure paths or [glob patterns](https://code.visualstudio.com/docs/editor/codebasics#_advanced-search-options) to exclude from being marked as read-only if they match as a result of the `#files.readonlyInclude#` setting."),
      'scope': ConfigurationScope.RESOURCE
      },
    [FILES_READONLY_FROM_PERMISSIONS_CONFIG]: {
      'type': 'boolean',
      'description': nls.localize('files.readonlyFromPermissions', "Marks files as readonly when their file permissions indicate as such."),
      'default': false
    },

FILES_READONLY_EXCLUDE_CONFIG is externally defined as 'files.readonlyExclude';
For nls.localize(key, message), the 'key strings' are
A) not derived/synchronized with the definition of FILES_READONLY_EXCLUDE_CONFIG
B) not consistent with including the 'files.' prefix
Maybe don't use the external constants (consistent with the rest of the file)
or use the external def'ns consistently: nls.localize(FILES_READONLY_EXCLUDE_CONFIG, ...
??

Yeah the keys for nls do not matter that much actually, as long as there are no duplicates in the same file. I pushed a change to align them though.
Thanks for testing!

I hope you are working in Seattle this week, and not burning midnight oil in Zurich...

Oh! a possible semantic detail:
isReadonly() currently give chmod precedence over Inc/Exc Globs:
    const sessionReadonlyOverride = this.sessionReadonlyOverrides.get(resource);
    if (typeof sessionReadonlyOverride === 'boolean') {
      return sessionReadonlyOverride; // session override always wins
    } if (this.configuredReadonlyFromPermissions && stat?.locked) {
      return true; // leverage file permissions if configured as such
    }

    return this.readonlyIncludeMatcher.value.matches(resource) && !this.readonlyExcludeMatcher.value.matches(resource);

If I mostly want files to open based on the chmod permissions (so FromPermissions: true)
But there are a class of files that need/want to open as 'editable' by default,
then I would want the Globs to have precedence over chmod:
    const sessionReadonlyOverride = this.sessionReadonlyOverrides.get(resource);
    if (typeof sessionReadonlyOverride === 'boolean') {
      return sessionReadonlyOverride;           // determined by session override/Command
    }
    if (this.readonlyIncludeMatcher.value.matches(resource)) {
      return !this.readonlyExcludeMatcher.value.matches(resource);    // determined by Inc/Exc Globs
    }
    // determined by file permissions if configured as such:
    return (this.configuredReadonlyFromPermissions && stat?.locked)

@jackpunt that is fair. Can you actually do a PR targetting my branch in my PR so that you could just propose the change yourself and do it?

Ok. on it...

Before making that mod, i wonder about textFileEditorModel & storedFileWorkingCopy
  override isReadonly(): boolean {
    return this.lastResolvedFileStat?.readonly ||
      this.fileService.hasCapability(this.resource, FileSystemProviderCapabilities.Readonly) ||
      this.filesConfigurationService.isReadonly(this.resource, this.lastResolvedFileStat);
  }

It appears that a chmod -w FileStat.readonly cannot be influenced by filesConfigurationService.isReadonly(...)
I had been working on the theory that filesConfigurationService.isReadonly() was the full arbiter...
I think we need to remove the first check on this.lastResolvedFileStat?.readonly ||
and move it to the proper precedence in filesConfigurationService ??
[goes back to my confusion about stat?.locked, think that may have included the stat.readonly bit...]

PR submitted

@jackpunt thanks, I merged it in but I had to add back the check for stat.readonly:
return (this.configuredReadonlyFromPermissions && stat?.locked) ?? stat?.readonly ?? false;

I think the precedence now is:

file system provider readonly: true => file is readonly and you cannot change that
user defined session override exists => file is readonly or writeable
file is part of user data => file is writeable
file is part of files.readonlyInclude => file is readonly unless files.readonlyExclude
file is write locked (chmod...) and configured readonly from permissions => file is readonly
file is readonly by file system provider => file is readonly
finally => file is writeable

That is quite complex! I am happy with this precedence I think, but users might have other feedback.
One thing I wonder though: do we need to allow the user overrides to mark a file writeable even if the file system provider is readonly overall? Currently that check is still in the working copy:
https://github.com/microsoft/vscode/blob/05632b6afe4c43f8e058a7582ba91fc50f04b0e5/src/vs/workbench/services/textfile/common/textFileEditorModel.ts#L1162-L1165
To be consistent, we should probably move that into the files configuration service as well.

had to add back the check for stat.readonly:

Sounds right :( I clearly didn't test every case...    <chagrin/>
I think your precedence chart is what I also arrived at. (although I didn't have the 'user data' test)
I don't know the distinction between bullets (1) and (6), is (6) is redundant?

file system provider readonly: true => file is readonly and you cannot change that
file is readonly by file system provider => file is readonly

Related to your question:

do we need to allow the user overrides to mark a file writeable even if the file system provider is readonly overall?

I thinks it's correct that FileSystemProviderCapabilities.Readonly prevents any ability to modify.
(that is: "no"; esp if/when the text has no backing store, or the Editor is no capability to edit)
Back when ReadonlyHelper was an adjunct to SFWC & TFEM, the checks were all in one place.
If you want to move that check back to isReadonly() and consolidate in one place, I'm expect that will work.

I don't know the distinction between bullets (1) and (6), is (6) is redundant?

It is not: a file system provider can either signal that it is readonly entirely or that specific files are readonly and some are writeable, so there is difference, even though not visually for the user.

I thinks it's correct that FileSystemProviderCapabilities.Readonly prevents any ability to modify.
(that is: "no"; esp if/when the text has no backing store, or the Editor has no capability to edit)

Yeah I like that reasoning: if the entire file system provider is declaring to be readonly, it is likely that no write operation can ever happen. But if a single file is readonly, it indicates that the user maybe able to override that. So let's leave it like that.

Since https://github.com/microsoft/vscode/pull/181708 landed, I will go ahead and close this PR. Thanks a ton for your reviews 🙏 . We can still continue to tweak the experience going forward, it would only be released in stable early June.
I will also make sure to ask for user feedback in our nightly insiders release in the fixed issues.


boards: m5stack_core2: 5V bus is not controllable

Describe the bug
The m5stack_core2 board features a 5v bus domain, that for example is used by the grove connector. This 5V bus is not being supplied accordingly. In addition there currently is no possibility to enable/disable this power domain.
To Reproduce
Steps to reproduce the behavior:

The external Gove connector 5V pin (2) is showing 0V.
The documentation is not describing any behaviour on the 5V bus (https://docs.zephyrproject.org/latest/boards/xtensa/m5stack_core2/doc/index.html)
device list is not showing any regulator to enable the 5V bus.

uart:~$ device list
devices:
- rtc@3ff48000 (READY)
- gpio@3ff44800 (READY)
- gpio@3ff44000 (READY)
- trng@3ff75144 (READY)
- uart@3ff40000 (READY)
- i2c@3ff53000 (READY)
- spi@3ff65000 (READY)
- axp192@34 (READY)
- axp192_gpio (READY)
- LDO3 (READY)
- LDO2 (READY)
- DCDC3 (READY)
- DCDC1 (READY)
- ili9342c@0 (READY)
- ft5336@38 (READY)
- lvgl_pointer (READY)
uart:~$

Expected behavior
The 5V may not be disabled by default, but there should be at least the possibility
Impact
Grove extension port is not usable properly right now.
Logs and console output
none
Environment (please complete the following information):

OS: MacOS
Toolchain Zephyr SDK 0.16.4
Comit SHA: 0a9728f87e41e2956cfd47de97c8f57e41b13aaa

Additional context
none

Main reason for this is missing support to control EXTEN pin of AXP192 PMIC.
I further investigated into this and currently prepare according fixes.
According to the schematic of M5Stack Core2 (https://m5stack.oss-cn-shenzhen.aliyuncs.com/resource/docs/schematic/Core/CORE2_V1.0_SCH.pdf) VBUS is not connected to the USB-Port and therefore doesn't follow the intended usage.
5V_BUS can therefore be enabled independently.
To keep the PMIC in a properly defined state VBUS functionality should be controlled mainly by N_VBUSEN signal, which is pulled low  by default.

Fix in (67280 )[https://github.com/zephyrproject-rtos/zephyr/pull/67280] seems to work as intended. @kartben Do you maybe find some time to test it with some of your grove extension hardware?


Block Sum of Matrix

💥 Proposal
Block Sum of Matrix | DP
Have you read the Contributing Guidelines on Pull Requests?
(YES)

/assign

Done please check @ankitaggarwal23


Add possibility to do custom builds to fork's ghcr.io

This will add the possibility to easily do custom build to the GitHub packages of a fork.
E.g. users can manually publish images produced by a branch to their GitHub container registry so that they can use them and try them out before doing a PR or merging to master.
Please tell me if the name "Custom build" is fine for this category or not.

Can you add protection to not never run this in the upstream? Like the opposite of https://github.com/xskipper-io/xskipper/blob/363408c2449e74c1f0f3b534cfdd782719b42b9f/.github/workflows/release.yml#L18


String (+) operator doesn't work on Enums.

Expected
Language: English

Actual
Language: 0

Steps To Reproduce
Bridge Live
Dot Net Fiddle
public class App
{
    [Ready]
    public static void Main()
    {
        Console.WriteLine("Language: " + Enum.English);
    }

    enum Enum
    {
        English
    }
}

Related to #1312.

Thanks for the great sample. We have reproduced and will fix.

This one is hard to fix. We will have an internal discussion.
A workaround is to add ToString manually, example(Live):
public class App
{
    [Ready]
    public static void Main()
    {
        Console.WriteLine("Language: " + Enum.English.ToString());
    }

    enum Enum
    {
        English
    }
}


To call it a software

With all due respects, to the glorious developers and contributors of ee. I just wish there is an option or command to uninstall it completely. Every software has it. Isn't it? Or there is a reason for you to stay stuck on the end-users server?

RTFM: https://easyengine.io/commands/cli/self-uninstall/

Close?


Prevent NoClassDefFoundError crashing app using Sugar

Hi Satya,
I'm just getting started using Sugar ORM and it looks really good so far.  However, I had trouble getting my app to run because I kept getting a NoClassDefFoundError when I included Sugar.
I had a jar file on my classpath which wasn't actually being used by the project.  When Sugar tried to load a class from that library, my app crashed.
My guess is that because the library was not being used, the classes didn't actually get copied to the apk, or something like that.
I changed the catch clause in getDomainClass to catch all throwables.  It doesn't seem to matter why we can't load a class, the result will be the same: if there is an error of any kind, we're not going to be able to use that class as a domain class.
Thanks,
Alex

@nicolabeghin thanks, I will merge this PR


Require a payload to be provided with a signature

Summary
This is the companion to https://github.com/sigstore/cosign/pull/2785 ; I guess it should be discussed there.
Release Note
NONE
Documentation
Uh, this?

Can we revert this, given I think there's going to be a lot of discussion in the other thread?


drivers/video: Update unlink() and video_uninitialize() operation

Summary
Add unregister_driver() execution to unlink() operation to delete device file.
Also, add resource cleanup to video_uninitialize() operation to avoid memory leak without unlink() execution for compatibility.
Impact
drivers/video
Testing
Tested with spresense

@xiaoxiang781216  Yes, it's as you say.
video_unregister() should free resource,
and video_uninitialize()/video_unlink() might be necessary to call video_unregister.

@xiaoxiang781216 I moved resource release from video_uninitialize() to video_unregister().

@xiaoxiang781216 @Donny9  Thank you for information. I verified that work well with #11892 without my change. I withdraw this PR.

Ok, let me close this pr.


Closing tag error in the docs

Hello,
There are closing tag errors in code snippets on the Getting Started page.
◕‿‿◕

◕‿‿◕

◕‿‿◕

Did there mean the following?
◕‿‿◕
◕‿‿◕
◕‿‿◕

Can I fix it?

Yeah, please submit a PR.

okay, I submitted a PR.
confirm, please.


Unhelpful Error Message If Conditional Reference Points to Multiple Records.

Describe the bug
If you have a conditional reference that returns multiple results, then the error message indicates that the reference does not resolve to a resource.
FHIR Version?
All
Data provider?
All
To Reproduce
Steps to reproduce the behavior:

Create, for instance, duplicate organizations with the same identifier.
Attempt to create, for instance, an encounter object referencing that organization through a conditional reference.
Receive error message.

Expected behavior
Receive a message indicating that the conditional reference was ambiguous.
b'{"resourceType":"OperationOutcome","id":"a1f74190-04f6-4369-83b6-0141a32b440d","issue":[{"severity":"error","code":"invalid","diagnostics":"Given conditional reference \'Organization?identifier=https://github.com/synthetichealth/synthea|3bd5eda0-16da-3ba5-8500-4dfd6ae118b8\' resolved to multiple resources."}]}'
Actual behavior
Receive a message indicating that the conditional reference does not resolve to a resource.
b'{"resourceType":"OperationOutcome","id":"a1f74190-04f6-4369-83b6-0141a32b440d","issue":[{"severity":"error","code":"invalid","diagnostics":"Given conditional reference \'Organization?identifier=https://github.com/synthetichealth/synthea|3bd5eda0-16da-3ba5-8500-4dfd6ae118b8\' does not resolve to a resource."}]}'

AB#77964

AB#77964

Could the Olympus team provide details on how to reproduce it and clarify exactly what we should focus on, as given steps are not clear to us.

@EXPEkesheth I think this one can be closed, as the work item is closed!


Deploy Multicall3 on Unreal testnet

Chain Name
Unreal
Chain ID
18233
RPC URL
https://rpc.unreal-orbit.gelato.digital
Block Explorer URL
https://unreal.blockscout.com/
Deployment Funds
Yes

@mds1 if you need more info, just ping me, it is Arbitrum stack, deployed from Holesky testnet.

Hey @mds1. what can I do to speed up the process?

I see it's arbitrum stack so you won't be able to use the presigned transaction. I am planning to fulfill all deployment requests by the end of this week, so if you put the mainnet request in now too it can be part of that batch

Hi, it looks like someone tried deploying with the presigned transaction. This transaction failed, presumably with out of gas since it's built on arbitrum, using up nonce 0. As a result, the only way to get Multicall3 at the expected address on this chain is to ask the chain developers to place it as a predeploy.


Refactor the indy_config.py configuration.

Replace the template approach with a sed command that only updates the NETWORK_NAME variable.
This insures the indy-node package install is in complete control of the file and only the required variable, NETWORK_NAME, is updated as needed.

Signed-off-by: Wade Barnes<EMAIL_ADDRESS>

I ran into additional issues with the template approach to the configuration so I refactored it to use sed replacement to update the network name.


Fast rerendering

If i click next page button 10 times per second PDF freezes
pdf.js?4383:2656 Uncaught (in promise)
RenderingCancelledException
message: "Rendering cancelled, page 25"
name: "RenderingCancelledException"
type: "canvas"
__proto__: Error

I am also facing the same issue


raw.add_channels  'buffer_size_sec' error

I'm trying to add a stim channel (a clean combination of multiple already existing stim channels) to a raw object:
# read raw
raw = read_raw_edf(fname, preload=True)

# clean stim
raw_stim = raw.pick_channels(chs_stim, copy=True)
data = clean_stim(raw_stim._data)

# append data
info = create_info(ch_names=['stim_clean'], sfreq=raw.info['sfreq'], ch_types=['stim'])
raw_stim = RawArray(data, info=info, first_samp=raw._first_samps[0])
raw.add_channels([raw_stim])

But I get the following error:
RuntimeError: Don't know how to merge 'buffer_size_sec'. Make sure values are compatible.
What shall I do?
cc @choldgraf @Eric89GXL

Set buffer_size_sec in create_info to whatever it is in raw, i.e.:
create_info(..., buffer_size_sec=raw.info['buffer_size_sec'])

TypeError: create_info() got an unexpected keyword argument 'buffer_size_sec'

info = create_info(...)
info['buffer_size_sec'] = raw.info['buffer_size_sec']

However I can do:
info['buffer_size_sec'] = raw.info['buffer_size_sec']
But that doesn't feel very clean

It's a fine way to do it. We don't expose all options in create_info but you can set them afterward. We could change this behavior.

And now I have:
RuntimeError: Don't know how to merge 'filename'. Make sure values are compatible.
when I add the channel raw.add_channels([raw_stim])

Overall, it seems like an aweful lot of steps to just add a stim channel..

It works with
        info['buffer_size_sec'] = raw.info['buffer_size_sec']
        info['filename'] = raw.info['filename']

I'm keeping the issue opened. I think we should have a less hacky way. WDYT?

for key in ('buffer_size_sec', 'filename'):
    ...

is how I would do it to make it DRY.
I know it is more work, but it is also more explicit. It forces the user to think about what keys are being merged and what the values should actually be, which isn't necessarily a bad thing. I'm open to ideas about how to make it more automated. However, with automation there is the risk of getting burned by not understanding what's going on under the hood. As I mentioned in another issue, info actually stores a lot of information, and thinking of it as just containing channel types and names can cause problems.
If adding a stim channel to data that does not have one is a common enough use case, maybe we should add a function specific for that. Stim channels in general have less information than, say, EEG or MEG. Then the user won't need to care about info at all.

Stim channels in general have less information than, say, EEG or MEG. Then the user won't need to care about info at all.

1

If you don't have a problem totally obliterating what's in your info channel (e.g., if you're doing this with ecog or something that doesn't have montage metadata etc), then what I've done is first re-create my dataset using RawArray, and then append the stim channel to it.  That said, I think at the least it'd be helpful to have documentation about what fields will result in an error if you try to merge a manually-created info object with one read from an EDF file or something.

What if there were a function to merge info objects that behaved similarly to how pandas merges dataframes? E.g., it could have flags to either throw an error with a field mismatch, or to replace values using one or the other info object. Then any time that a field was overwritten it could write that to the log.

I think it's better to not create a RawArray from scratch, just in case we forget some info.
This is what I currently do
def add_channels(inst, data, ch_names, ch_types):
    from mne.io import _BaseRaw, RawArray
    from mne.epochs import _BaseEpochs, EpochsArray
    from mne import create_info
    if 'meg' in ch_types or 'eeg' in ch_types:
        return NotImplementedError('Can only add misc, stim and ieeg channels')
    info = create_info(ch_names=ch_names, sfreq=inst.info['sfreq'],
                       ch_types=ch_types)
    if isinstance(inst, _BaseRaw):
        for key in ('buffer_size_sec', 'filename'):
            info[key] = inst.info[key]
        new_inst = RawArray(data, info=info, first_samp=inst._first_samps[0])
    elif isinstance(inst, _BaseEpochs):
        new_inst = EpochsArray(data, info=info)
    else:
        raise ValueError('unknown inst type')
    return inst.add_channels([new_inst], copy=True)

how about:
read raw
raw = read_raw_edf(fname, preload=True)
clean stim
raw_stim = raw.pick_channels(chs_stim, copy=True)raw_stim._data =
clean_stim(raw_stim._data)
append data
raw.add_channels([raw_stim])
?

The raw_stim has multiple chans (one for each binary TTL) whereas the clean_stim is the combination (similar to STI 101 in elekta defaults).
One could however follow your solution and add an additional pick_channels, and perhaps a rename_channels afterward.
However, if one (i.e. me) wants to add, say, an auditory misc channel, then you need to change the ch_type (or already have a misc in your raw).
Overall, there's more than one hack that'll do the trick, I was mainly asking what should be the cleanest way.
(I don't want to reopen a fight on API changes; I'm personally just going to use the code above, that seems clean and generic enough to me)

I would be fine adding a "force" param to raw.add_channels to drop any
offending key in the Info and be therefore more permissive

That sounds good to me - it'd just force any overlapping keys w/ different values to take on the value of the self object, and raise a warning? Can anybody think of an instance where this might break things?

That's okay with me as long as it's opt-in by kwarg, not default

PR welcome then :)

can do this, but not right now...it will go on my list of "fun things to do
once I resubmit my paper" :)
On Mon, Feb 29, 2016 at 1:41 PM, Alexandre Gramfort <
<EMAIL_ADDRESS>wrote:

PR welcome then :)
—
Reply to this email directly or view it on GitHub
https://github.com/mne-tools/mne-python/issues/2948#issuecomment-190408411
.

I would be fine adding a "force" param to raw.add_channels to drop any offending key in the Info and be therefore more permissive

+1

can do this, but not right now...it will go on my list of "fun things to do once I resubmit my paper" :)

Ok, good luck ;)

@choldgraf certainly your paper is resubmitted by now? :)

:(

let me put it this way: I'm not shaving or getting a haircut until I resubmit the damn paper, and yesterday my labmate said that I had a nice "The Revenant" thing going on...

I'm going to move this to 0.13 but if you get to it by mid/end of April then it's fine to put in 0.12

OK - the tentative plan is to resubmit by the end of march, so that does seem reasonable. This thread is on my to-do list so I won't forget about it

Looking through this now. I'm not quite sure the best way to add a "force" option. The reason is that there's a lot of machinery under the hood to make sure that values are able to be merged between info objects. So here are a couple of thoughts:

Hard-code some fields that we know are going to be problematic for adding stim channels, and if a "force" parameter is given, then automatically add those fields to new info objects before merging (similar to what @kingjr and @Eric89GXL do above)
Separate from the merging code, write some kind of make_info_mergeable function that takes a base info object and a list of other info objects, and does something like 1 above for the to-be-appended info objects.
Write a more general function that has a force parameter which will overwrite all inconsistencies between the base / to-append info with those of the base info object.

If we think that the problematic fields won't change much in the future, I think that 1 might be the most verbose and easy to implement, but it might be a pain if we think that the fields which throw this error will change over time.
WDYT?

Would this work?

The force option takes any conflicting keys and uses the value from the
first dictionary (easy to explain, hopefully easy to implement). Call
_check_consistency at the end, and beef up that function of necessary to
hopefully catch any traps.


feat: add --quiet and --errors options

--quiet produces no output and only exists with exit(0) on success
and exit(1) on any one failure.
--errors only shows licenses that have a NOT APPROVED status.
Closes #5.

Looking at the travis test errors now.

@janl, thanks for the patch! Strange that Travis failed after nvm install node. I've asked Travis to do it again.
A number of Unix-style commands offer --quiet. But I can't help asking: Any chance licensee >/dev/null 2>&1 or licensee &>/dev/null (Bash 4) would satisfy your use case?  IIRC, there's a Windows shell equivalent, though I don't remember what it is.  Maybe something with taskkill.
I really like the --errors idea. Might put a little thought on the name of the flag. --errors-only, perhaps?

Just started reviewing :) :octocat: Sent from GH.

Heya, I think I’m finding a logic flaw and I’m running out of daytime here, I’ll go at this with a fresh head tomorrow.
I don’t feel strongly about --errors vs. --errors-only, happy to go with whatev.
My specific need is the option to only show the errors, I’m just doing --quiet here because it was raised and easy to add while I’m in here.
Thanks for the feedback so far.

Thank you for the patch!

To-do list for myself:

[ ] Document new flag(s) in README.
[ ] Document &>/dev/null in README if we don't implement in the code.
[ ] Add CONTRIBUTORS for credit.
[ ] Apache-2.0 for contribution?

I’ve sorted out the logic errors. npm test still fails for me, but I’m getting the sane failures on master and they seem unrelated to my change.

[x]  Document new flag(s) in README.

copied licensee -h output

[x] Add CONTRIBUTORS for credit.

https://github.com/jslicense/licensee.js/graphs/contributors is good enough for me

[x] Apache-2.0 for contribution?

absolutely, but I think this is also already enforced by GitHub’s newish ToS.

I’m getting the sane failures on master and they seem unrelated to my change.

The changes on master with the lockfiles fixed this. I rebased this branch and all passes locally.

nudge 😇

@janl Thanks for the changes. I'm having a look.

@janl, I'm going to split your commit for just --errors-only, fast-forward, and make a semver-minor release. That should be v4.1.0. I'm also going to add you on the repo and invite you to the org, since you and your patch are awesome. We can talk --quiet and other ideas in PRs.

4.1.0 is out with --errors-only.


make Connector, Token, and Pool contracts part of state/param

Closing as it looks no longer relevant. These are stored on-chain already.


Module parse failed: Unexpected token (20:8) Failed to compile.

I tried to run it according to the README, but this exception was thrown:
ERROR in ...\npm\node_modules\movy\src\movy.ts 20:8
Module parse failed: Unexpected token (20:8)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
| import TextMesh from "./objects/TextMesh";
|
> declare class CCapture {
|   constructor(params: any);
| }

webpack 5.18.0 compiled with 1 error in 2654 ms
i ｢wdm｣: Failed to compile.

I am not familiar with JavaScript, hope to get help. :)

I got the same problem(

I got the same problem(

My bad, fixed in v0.0.4. You could try npm i -g movy again to upgrade to the latest version.

My bad, fixed in v0.0.4. You could try npm i -g movy again to upgrade to the latest version.


Update contact details for project

Update contact details for project to point to stackoverflow/issues rather than individuals (kevin)

@hamishwillee the docs also have this reference, can you update the copyright there as well and update this pull request please?

@mrpollo , done, as described in #31

Perfect!


Question: is colly free to use (for open-source / personal projects)

The website has me sorta confused on the pricing for open source and personal projects

Its open-source and free for everyone to use if you are running Colly on your own machines.  The pricing is in reference to having Colly run as a service for you.

@vosmith Thanks!


adding issue linking to PR template

Hello @ksigler7,Thanks again for the PR! It's HACKTOBERFEST! We want to show our appreciation by sending                                              you some special Hacktoberfest swag. If you have not already, could you please fill out                                              this form so we can send it to you? Thanks!                                             Team SendGrid DX


perf(repeat): in-place binding context update

Looked through the PR, looks good to me. Very impressive!

@martingust thanks for the review!
@EisenbergEffect this is ready to merge


Feature Request: Runtime APIs to get the version of each XRTK module in use

XRTK - Mixed Reality Toolkit Feature Request
Is your feature request related to a problem? Please describe
For testing and debugging as well informative purposes there should be a convenient way for developers to get the version in use for each XRTK module active when the application is running, e.g.
XRTK.Core v0.2.0
XRTK.SDK v0.2.0
...
How would you classify your suggestion

Usability / Configuration
Dev Tools

Describe the solution you'd like
I can imagine this being an API of MixedRealityToolkit itself, e.g.
public string[] MixedRealityToolkit.Versions { get; private set; }

I wonder if there's a way to get this from the Unity package APIs

@FejZa I was doing some research into this. We should be able to set the assembly version based on the asmdef. I'll see if we can automate this somehow.


MSRV check broken

the CI tests on rust 1.63 to ensure MSRV but it doesn't use a Cargo.lock. since not all crates have strict MSRV policies it can happen that a newer version of a dependency is being pulled in which breaks the CI for MSRV.
this is exactly what just happened for #122: error: package tokio-macros v2.4.0 cannot be built because it requires rustc 1.70 or newer, while the currently active rustc version is 1.63.0 (see the full build output)
there are three ways to deal with this:

slacken the MSRV policy (defmt style)
check in Cargo.lock (see the cargo FAQ & blog post)
check in a copy of Cargo.lock specific for the MSRV check (e.g. as Cargo.lock.msrv) and copy it to Cargo.lock as part of the CI script (downside: it has to be manually maintained if dependencies are added/updated by copying over the correct Cargo.lock to Cargo.lock.msrv to commit it)

The strict MSRV policy is still from a time where we had very minimal dependencies. By now we include both eh0 and eh1, and also the whole async jungle, which makes our current MSRV policy unrealistic.
Let's move to a less strict MSRV policy.


useSpring example not working

Hi,
I've used the useSpring example from the documentation but it doesn't seem to work. Am I missing something or is the documentation incorrect? This is my very simple component. I have globally installed vue motion in my app.
When I click the div, I see 'click' appear in the console but no animation is triggered.
I get an error in this codesandbox when triggering the animation that I'm not getting in my local app, I'm not sure if it's related. Cannot read properties of undefined (reading 'apply')
https://codesandbox.io/s/vueuse-motion-forked-i76zv6?file=/src/components/Bar.vue
Can anyone shed some light?
<template>

</template>

@boydenhartog I think the doc might have been changed and us outdated. After looking at useSpring's implementation, I think you can try using it like this: stackblitz demo with Nuxt 3

I updated @didavid61202 's great work to use the reactiveTransform composable from Vue Motion.  That made a bit more sense to me and I'm guessing that's how the authors of this library intended it to be used?
Basically reactiveTransform outputs a state variable which useSpring can animate, which is then tied to a transform reactive variable which can then be bound to the actual element's style.
https://stackblitz.com/edit/nuxt-starter-vujfqb?file=app.vue

The example in the docs is still not working 1.5 years in

Resolved by #181


issue-1246 Truncate commit message to first newline

Hey, I just made a Pull Request!
From Kubecon 2024 SLC Contribfest
This change is to address issue https://github.com/backstage/community-plugins/issues/1246 by truncating the commit message that is displayed at the first newline character and exposes the entire message on hover.
Before:

After:

:heavy_check_mark: Checklist

[X] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[X] Screenshots attached (for UI changes)
[X] All your commits have a Signed-off-by line in the message. (more info)

@awanlin Sorry for all the noise for this simple change.  I think I've dotted all the i's and crossed all the t's this time.


Support Argo Rollout Resources

Goal
The Keptn Lifecycle Toolkit should be able to run pre- and post-deployment evaluations of Argo Rollout Resources
Technical Details

Keptn holds back Deployments using Argo Rollout until Pre- and Post-Deployment Tasks are finished
Keptn runs post-deployment tasks when 100% of the rollout is finished

Nice to have

Keptn runs post-deployment tasks and evaluations when a certain percentage is reached and resumes the Rollout

DoD

[ ] Keptn Pre- and Post-Deployment Tasks and evaluations are working for Argo Rollouts
[ ] Documentation is updated
[ ] Example is provided

I like the idea of better supporting Argo Rollouts. The only thing we need to look into is that a user then doesnt have two ways of evaluating the rollout. Becuase - Argo Rollouts itself does an Analysis after each rollout step. We need to make it as easy for the user to use both the built-in rollout capabilites as well as KLTs options. Wondering if there is therefore an option to also think about providing an analysis step that would then call a KeptnTask or KeptnEvaluation. This would allow a user to use KLT for the Rollout Step Analysis as well as for pre- and post-deployment


update e2e

What this PR does / why we need it:
Special notes for your reviewer:
Does this PR introduce a user-facing change?

Codecov Report

Merging #758 (fb13eba) into main (471faab) will not change coverage.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@           Coverage Diff           @@
##             main     #758   +/-   ##
=======================================
  Coverage   30.59%   30.59%
=======================================
  Files          25       25
  Lines        1556     1556
=======================================
  Hits          476      476
  Misses       1015     1015
  Partials       65       65

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


[docs-infra] Move ads to the @mui/docs package

Followup of #42842
commits

Move files to the package
Use context for configuration of ads
re-export the Ad component to avoid breaking toolpad docs

https://github.com/mui/mui-toolpad/blob/4298328c314621b0533974590284eb70f3dfffd9/docs/src/modules/components/SchemaReference.tsx#L4

I don't know why moving those files to the package results in the following error

src/Ad/ad.styles.ts(95,14): error TS2742: The inferred type of 'adStylesObject' cannot be named without a reference to 'packages/mui-styled-engine/node_modules/csstype'. This is likely not portable. A type annotation is necessary.
buildTypes.mjs

Not proud of my fix: https://github.com/mui/material-ui/pull/42944/commits/0aa6cf43ded245b306772e16a6f4c440cb401fcc
I probably missed something

I probably missed something

Have you tried adding a reference to @mui/styled-engine here?

Have you tried adding a reference to @mui/styled-engine here?

It did not worked (or I don't know how to do it correctly)
After some code commenting, it appears that the issue does not come from the styled(...)(problematicFunction) which infers the typing of the problematicFunction.
It's just the theme.typographe.body1 and other typography that requires the font typing which are in csstypes So I just added the library to the tsconfig


Revert "Add ownership reconciliation based on labels"

This reverts commit 5c2a49a033b9ecda259e4d8d9c0fd5682fb47cde.

/lgtm

Force merging due to stage hotloop.


Add AWS CognitoAuthTokenProvider module

An HttpClient AuthTokenProvider for AWS Cognito

It was missing the <packaging>pom</packaging>

Oh wow, I didn't know we could do <module>aws-cognito/http-client-authtoken</module> ... now I'm thinking we could/should release this independently by itself on its own cadence.  So my thinking here is to move this under test21 so that it isn't released with everything else via -Pcentral central profile.


Add swipe gesture recognizer

Hi,
I have a plan to use the framework in one of my projects, but I'd like to have an option to handle swipe gestures on "cells". That will allow to make a cell of an "image gallery" kind or something simillar.
I'd suggest adding a swipe recognizer to a StackViewCell class. I can do that and it seems to be relatively easy to do. The only thing to concern is the fact that right now I don't see an option to make a cell be both higlightable and swipable, mostly because of overriden touchesBegan, touchesEnded methods.
Would be glad to hear yout thoughts on that. Thank you.

AloeStackView has a cellForRow(_:) method that can be overridden by subclasses, allowing them to provide a custom StackViewCell class, which could add it's own gesture recognizer and override the touches... methods.


[QUESTION] How to add custom lang file without adding it to vendor folder?

Hello,
Not an issue. Right now i am adding a custom language file to the vendor folder and it works, That is until I have to composer install. So how would I add the lang file outside the vendor folder.
Thank you

Hello,
With jenssegers/date 4.0 you can use any of the following language:
https://carbon.nesbot.com/docs/#supported-locales
If you have custom translations to add, you still can use ->setTranslations() as described in https://carbon.nesbot.com/docs/#api-localization and parse/format methods of jenssegers/date will also inherit those custom translations.


Bump instrumentation-all

Bumps minimum gem versions to latest patch releases for everything in -all; and we also add the rake/rspec instrumentations to the gem.

Ugh I can't github today


Meisterplan Connector: Added support for dynamic schema in swagger file

added new internal endpoints for schema and user connection information
added x-ms-dynamic-schema extension to definitions that can have dynamic fields
applied new swagger json file of rest api (added actuals costType and costPerHour)
added x-ms-capabilities testConnection to swagger file
applied new brand color to apiProperties

When submitting a connector, please make sure that you follow the requirements below, otherwise your PR might be rejected. We want to make you have a well-built connector, a smooth certification experience, and your users are happy :)
If this is your first time submitting to GitHub and you need some help, please sign up for this session.

[ ] I attest that the connector doesn't exist on the Power Platform today. I've verified by checking the pull requests in GitHub and by searching for the connector on the platform or in the documentation.
[ ] I attest that the connector works and I verified by deploying and testing all the operations.
[ ] I attest that I have added detailed descriptions for all operations and parameters in the swagger file.
[ ] I attest that I have added response schemas to my actions, unless the response schema is dynamic.
[ ] I validated the swagger file, apiDefinition.swagger.json, by running paconn validate command.
[ ] If this is a certified connector, I confirm that apiProperties.json has a valid brand color and doesn't use an invalid brand color, #007ee5 or #ffffff. If this is an independent publisher connector, I confirm that I am not submitting a connector icon.

If you are an Independent Publisher, you must also attest to the following to ensure a smooth publishing process:

[ ] I have named this PR after the pattern of "Connector Name (Independent Publisher)" ex: HubSpot Marketing (Independent Publisher)
[ ] Within this PR markdown file, I have pasted screenshots that show: 3 unique operations (actions/triggers) working within a Flow. This can be in one flow or part of multiple flows. For each one of those flows, I have pasted in screenshots of the Flow succeeding.
[ ] Within this PR markdown file, I have pasted in a screenshot from the Test operations section within the Custom Connector UI.
[ ] If the connector uses OAuth, I have provided detailed steps on how to create an app in the readme.md.

Hello @itd-sk,
Thank you very much and congratulations on your new submission. Our Certification Engineers will review it within 1-2 weeks.
Please let us know if you have any questions.
Thank you very much again for working with us.

Hello @itd-sk,
I hope you are doing well.
Congratulations, your pull request is approved and merged. Please submit the files to ISV Studio or update your submission using your latest commit ID, please allow us up to 1-2 weeks to review your submission, and our Engineers will notify you in the “Activity Control” area in ISV Studio. Please make sure that the icon meets all the requirements, that it’s size is 230x230, icon background is not white or transparent and it matches the iconBrandColor property in apiProperties.json file.
After making the submission in ISV Studio, please attach an intro.md file in the activity control section. This file is required and it's different from readme.md. You can find an example of intro.md file on this page at step 6.
Please Create an environment in the Preview region. You will use this environment later to test your connector after Microsoft is done with the functional verification for your connector.
We expect all tests to be completed within 1-2 weeks.
If your connector passes all tests, the deployment process begins, and it typically takes up to 3 to 4 weeks to deploy your connector to all of our regions.
Please let me know if you have any questions or run into any problems while creating or updating your submission.
Thank you very much for working with us.


fix the pr #2888

It seems like I forgot that the store should update if the input changes. Thus I reverted the commit, just removed the orEmpty flag, since tolgee.translate does not have this flag. This now works as expected in my environment. Also now the test should work again :)

Hey, I guess you are right. The implementation is not very elegant now as it slips to an infinite loop quite easily. I have a plan to do it similarly as it is in React implementation (https://github.com/tolgee/tolgee-js/blob/main/packages/react/src/useTranslate.ts). But this should be correct for now.