Add basic Makefile and decouple from Momentics

Hey, I'm not sure how you feel about Momentics, but I've done some work to get Term48 building and deploying without using Momentics (just BBNDK).
I have some ideas for improvements to Term48 and plan on tinkering as time allows.
Feel free to reject this PR if you feel that Momentics is the way to go for mainline Term48.
Thanks, Andrew

Oh, I love this direction. Momentics is fine and all, but bootstrapping the build has always been painful. I am traveling this weekend, so might not be able to review this for a couple of days, but if it all works for me then I am happy to do the merge. Thanks!

So I love the way this looks, but it doesn't seem to create a working binary for me?
I added some minor comments on signing/Makefile and on the bar-descriptor.xml for things that caused the deploy-token / build / deploy to fail. Once I fixed those up, then deploying the debug token worked great, and the build / deploy was fine. The resulting binary seemed non-functional though - It would launch, but I couldn't type. I tried swapping in the shared libraries (libconfig, SDL, TCO) from the Term48 release and the binary compiled / linked, but wouldn't launch once installed on the device. Not sure what's going on.
Anyway, if we can fix up the minor things I commented on, and I can get a working binary at the end, then I am happy to merge. I really like this direction!

Hey, I had the same issue (not being able to type) on the master branch code.
It could be related to the shared libraries; I figured I'd get a build system working before debugging issues.
I'll fix up based on your suggestions tonight, thanks.

Adding in the terminfo and such is great. I'll give this another go tomorrow and see where we are. If you are also getting no input I'll see if I can figure out the difference between this build and the release.
Thanks!

So far so good. I love adding in all the assets and stuff. Still doesn't make a working binary for me, but I'm going to merge this, and then we can figure out the making it run thing. :-)
This is great work!


Revamping the Pysxm module architecture

Here it is.
I need your review BTW. These changes seem to be passing the tests.

Hum... what is this ?

Coverage increased (+0.08%) to 93.59% when pulling aca979699f3e4e791447a5cef5d79cf260218540 on RevampingPysxm#6 into<PHONE_NUMBER>085f991e97f99eebf0d2cec25ef939 on master.

Coverage increased (+0.08%) to 93.59% when pulling aca979699f3e4e791447a5cef5d79cf260218540 on RevampingPysxm#6 into<PHONE_NUMBER>085f991e97f99eebf0d2cec25ef939 on master.

Really need a breakfast now ^^

@josuebrunel I merged this pull request not even waiting for you. Sorry for that.
Let me know if the pull request is okay.


chore: bump wasmcloud 0.79.0 wadm 0.8.0

Feature or Problem
This PR bumps wasmcloud to 0.78.0 and wadm to 0.7.1 to bring in the latest and greatest stable things.
Related Issues

Release Information
v0.21.0
Consumer Impact

Testing

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin
[ ] x86_64-windows

Tested on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin
[ ] x86_64-windows

Unit Test(s)

Acceptance or Integration

Manual Verification

Updating this PR to wasmcloud 0.79, wadm 0.8


Please update eslint-scope

Hi,
About an hour a<EMAIL_ADDRESS>has been released. This is a hacked version which steals the npm credentials and sends them to remote server.
Relevant discussion:
https://github.com/eslint/eslint-scope/issues/39
Please update to eslint-scope 4.0.0 or pin the version to 3.7.1 since there is not going to be any patch release.
Cheers,
Andrej

We (the ESLint team) are working on unpublishing 3.7.2 (it was not published by us, some of our credentials must have been compromised).
As @pronebird noted, we don't plan on publishing anything in the 3.7.x line, so you could pin to 3.7.1 if you're not ready to consume 4.0.0.
Apologies for the inconvenience.

I created #656 to expedite the process. Hopefully that helps.
It will still need a package version bump to make the change public though.

@neverendingqs you probably mean #657. Thanks for this! 👍

Dang just woke up, I think we need this for the 8.x branch then as well?

@hzoo not sure if you already use 4.0 in 8.x branch or not. If anything below then yes.

Yeah might as well I guess. Did 8.2.6 and 9.0.0-beta.3

@hzoo fun times 😄

lol, ya I'm tired.
For reference/resolution: https://twitter.com/geteslint/status/1017509669701603328


Add docs about Terraform/OpenTofu plugins cache

Description
Fixes #2892.

TODOs
Read the Gruntwork contribution guidelines.

[x] Update the docs.
[ ] Run the relevant tests successfully, including pre-commit checks.
[ ] Ensure any 3rd party code adheres with our license policy or delete this line if its not applicable.
[ ] Include release notes. If this PR is backward incompatible, include a migration guide.

Release Notes (draft)

Added / Removed / Updated [X].
Migration Guide

@denis256 @levkohimins Could we review this so we can get it merged if it's ready?

@jcolfej, @josh-padnick Unfortunately, this will not work properly with run-all commands, [https://terragrunt.gruntwork.io/docs/features/provider-cache/#why-terraforms-built-in-provider-caching-doesnt-work](Why Terraform’s built-in provider caching doesn’t work).


Hot-reloading of scripts ("Synchronize Script Changes") doesn't work when using external editor (VSCode)

Godot version
4.0.beta17
System information
MacOS
Issue description
When the "Synchronize Script Changes" option is selected, scripts should hot-reload when changes are saved. However, this does not work when using Godot 4 with an external editor (only tested on VSCode). It does work when using the in-built text editor, or when using Godot 3.
Steps to reproduce

Configure Godot to use VSCode as an external editor.
Enable Synchronize Script Changes.
Edit a script file within VSCode while the game is running.

Minimal reproduction project
N/A

I don't want to turn this into a "me too!" comment stream, but I will say it's not just VS Code. I have this problem with Neovim as well, so it is very likely simply Godot isn't monitoring for inotify events or whatever equivalents on non-Unix systems.
I'm guessing the integrated editor runs some code on save that initiates the reloading, which would certainly be more efficient than monitoring the filesystem when applicable so it is very understandable. But it would be great if it did monitor the filesystem when users work with external editors.

I did some digging into this and I believe I've found the underlying cause as well as a potential fix.
This code in ScriptEditor::_update_modified_scripts_for_external_editor is what's typically responsible for telling the running game that it needs to reload scripts via _trigger_live_script_reload:
https://github.com/godotengine/godot/blob/013a45706897af989703b944c7cd5f4f58a6c060/editor/plugins/script_text_editor.cpp#L728-L739
Separately: When an external editor is connected to the language server, it sends a didSave event when you save a file, which in turn calls GDScriptTextDocument::didSave, which reloads the script using GDScript::load_source_code:
https://github.com/godotengine/godot/blob/550a7798510810d238b733a54f69da71b2a2d152/modules/gdscript/language_server/gdscript_text_document.cpp#L104
This in turn causes the script's last_modified_time to be updated.
Since the didSave callback happens well before _update_modified_scripts_for_external_editor, the date check in ScriptEditor::_update_modified_scripts_for_external_editor will never succeed as the timestamps will always be the same.

I did not have time to investigate fully, but I suspect this issue was introduced by https://github.com/godotengine/godot/pull/66867 as it introduced reloading the script within didSave.

I found that I can fix the issue by calling ScriptEditor::_trigger_live_script_reload from GDScriptTextDocument::didSave. See here: https://github.com/PathogenDavid/godot/commit/210edab910a226a1e8a6a9f1cd391a3ee966b76f
(As an added bonus this also fixes https://github.com/godotengine/godot/issues/73808, but only if you're connected to the language server)
However today is the first time I've ever really used Godot, so it's not immediately clear to me whether this is the most appropriate fix. (If it is, would be more than happy to clean things up and make a PR!)

Thank you so much for the code snippet here @PathogenDavid . I've been using a custom build of Godot 4 with your patch and it has significantly improved my workflow. It would be great to have a PR for this. Maybe this could even only run if Use an external editor is on? If there's any concern on this triggering more than is needed for users who aren't using an external editor?

<C++ Source>   modules/gdscript/gdscript_vm.cpp:697 @ call()

In https://github.com/godotengine/godot/issues/75550 we use the build-in GDScript editor which @dakennedyd thinks relates to this issue. Does it?

Is there any reason for not making the fix @PathogenDavid made into a PR? https://github.com/PathogenDavid/godot/commit/210edab910a226a1e8a6a9f1cd391a3ee966b76f

@Dexterminator I mainly left my comment to share my findings for someone who wishes to investigate this further and to share my quick and dirty fix (and perhaps learn if someone more involved with Godot's development thought it was good enough as-is.)
Based on the quirk @OmarShehata ran into, I suspect the real fix will need to be more complicated.
A lot has changed for me in the past 6 months and I'm no longer using Godot, so I most likely won't be the one to investigate further.

@PathogenDavid Can you make a PR with the change?
That way people can test it easily and maintainers can discuss the implementation.

@PathogenDavid I think it's a good change.
From what I understand, the LanguageServerProtocol will trigger a didSave request, which will be forwarded to the gdscript_text_document, which will trigger a reload.
You should open a PR so that people may test the change easily and maintainers can get a chance to review the change.

From the Godot contribution guidelines:

[...] when contributing bug fixes - it's always best to discuss the implementation in the bug report first if you are not 100% about what would be the best fix.

My understanding is this is the appropriate and preferred place to discuss the change. I don't think my fix will be the whole fix--at the very least the issue Omar ran into needs to be addressed.
Additionally, I don't see how making a PR would make it any easier for people to test the change.

A PR is the best way to discuss a code change in the engine.
Many PRs have limitations that can be discussed with the maintainers.
It is the normal review process to checkout a PR and test a change locally. Checking out a commit that is out of tree is more involved.
The issue of the editor requesting focus after a script error is, IMHO a minor inconvenience VS having not reload.
Anyway, if you want to discuss this change with somebody that knows the in and outs of the engine, you have a better chance with a PR than waiting for one of those people to stumble into a code change mentioned in an issue.

Just to share my 2 cents here: I think it's clear David is no longer able to commit time/resources to this. His snippet posted above is super valuable for anyone wanting to pick this up, and anyone is free to do and open a PR. It makes that whoever opens a PR will likely also be the one to collect feedback from engine maintainer/test it/update it etc.
Anyway, since I do have an interest in seeing this fixed, and have been testing it locally with a patched version of the engine, I'd be happy to open a PR sometime next week if no one gets to it before then.

Just to share my 2 cents here: I think it's clear David is no longer able to commit time/resources to this. His snippet posted above is super valuable for anyone wanting to pick this up, and anyone is free to do so and open a PR. It makes sense that whoever opens a PR will likely also be the one to collect feedback from engine maintainer/test it/update it etc.
Anyway, since I do have an interest in seeing this fixed, and have been testing it locally with a patched version of the engine, I'd be happy to open a PR sometime next week if no one gets to it before then.

Seems like there is already an pr about this？https://github.com/godotengine/godot/pull/82113#issuecomment-1734326593

@eterlan I think that is maybe fixing a slightly different situation?
I just started re-testing this with the latest version of Godot. Had some trouble initially but turns out it was just the language server not properly connecting.
The fix described in the patch above still works. The obvious thing needed before merging would be figuring out a proper way to force reload the script (currently the patch just makes a private function public).
I'm still familiarizing myself with these files, one thing I wanted to try is whether we just need to flip this boolean in the case where an external editor is being used:
ScriptEditor::get_singleton()->reload_scripts(true);

I also wanted to double check what the flow is for updating when you save inside the Godot editor, and if it makes sense to match that when saving with an external editor.
If I can't make progress I'll just open the PR and ask in the engine devs chat for further guidance


\node_modules\face-recognition\cc\facerecognizernet.cc(82): note: No cons   tructor could take the source type, or constructor overload resolution was ambiguous

\node_modules\face-recognition\cc\facerecognizernet.cc(82): note: No cons
tructor could take the source type, or constructor overload resolution was ambiguous


refactor(*-git): use timestamped versioning

This proposed change would solve the issue of Pacstall git packages needing to be downgraded, due to them being versioned only by commit_hash, which is not necessarily incremental and conflicts with how dpkg/apt are meant to function, meaning Pacstall has to force downgrade git packages.
To fix this, the new pkgver() calculation will now produce commit_UNIX_timestamp.commit_hash. As an example:
emacs-git is currently versioned b625ccff, giving the commit hash
the updated versioning of emacs-git would be<PHONE_NUMBER>.b625ccf, giving the UNIX timecode for when the commit was created, with a dot version of the commit hash
This would allow for us to still identify the packages with the hash, but conform to Debian systems and update packages incrementally, properly.

@Zahrun @echometerain @DiegoMagdaleno @kwon37xi @ObsidianPresidium @laniusone @Ruturajn @edward-riley You have (a) Pacstall package(s) that will be affected by this change. Could you reply to this comment, indicating if you give consent to this change? Thank you.

This looks like a lot of repetition of code. Could we instead have this done by pacstall for all -git packages?

@oklopfer I consent.

This looks like a lot of repetition of code. Could we instead have this done by pacstall for all -git packages?

We discussed a backend way of doing this, but realized issues would arise for -git packages that don't use this style versioning. This is the only way we can do it without making a "breaking change"

This looks like a lot of repetition of code. Could we instead have this done by pacstall for all -git packages?

We discussed a backend way of doing this, but realized issues would arise for -git packages that don't use this style versioning. This is the only way we can do it without making a "breaking change"

Ok, go ahead then

I consent to this change.
Thank You

I consent, thanks

?

We discussed a backend way of doing this, but realized issues would arise for -git packages that don't use this style versioning. This is the only way we can do it without making a "breaking change"

This might be turned into a Pacstall function later that people can opt into after this is merged.

Closed in favor of pacstall 4.0.0


Add support to sync other directories from the backup dir

Some add ons will output their backups in the backup dir (e.g: Unifi Controller)
This adds support to pick up those additional dirs and sync them to dropbox.

Any interest in pulling this in?


⚠ Cioos National CKAN has degraded performance

In 11ed0ac, Cioos National CKAN (https://catalogue.cioos.ca/) experienced degraded performance:

HTTP code: 200
Response time: 8425 ms

Resolved: Cioos National CKAN performance has improved in bdee9b0 after 17 minutes.


Gallery 2022-03-03 API release

ARM API Information (Control Plane)
Swagger PR being merged to this branch is: https://github.com/Azure/azure-rest-api-specs/pull/20398
This PR was signed off for the breaking changes in this PR because the functionality was broken for customers so these changes will not hurt customers.
The individual SDK owners have approved this breaking change as well.
.Net changes for this branch are here: https://github.com/Azure/azure-sdk-for-net/pull/29817/files
And the .Net changes for the new features are here: https://github.com/Azure/azure-sdk-for-net/pull/30125
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Azure 1st Party Service can try out the Shift Left experience to initiate API design review from ADO code repo.  If you are interested, may request engineering support by filling in with the form https://aka.ms/ShiftLeftSupportForm.
Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[x] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
By default, Azure SDKs of all languages (.NET/Python/Java/JavaScript for both management-plane SDK and data-plane SDK, Go for management-plane SDK only ) MUST be refreshed with/after swagger of new version is published. If you prefer NOT to refresh any specific SDK language upon swagger updates in the current PR, please leave details with justification here.

Contribution checklist (MS Employees Only):

[x] I commit to follow the Breaking Change Policy of "no breaking changes"
[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[x] Check this box if any of the following apply to the PR so that the label "ARMReview" and "WaitForARMFeedback" will be added by bot to kick off ARM API Review.  Missing to check this box in the following scenario may result in delays to the ARM manifest review and deployment.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you copy the existing version into the new directory structure for first commit and then push new changes, including version updates, in separate commits. You can use OpenAPIHub to initialize the PR for adding a new version. For more details refer to the wiki.

[x] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If you have any breaking changes as defined in the Breaking Change Policy, request approval from the Breaking Change Review Board.
Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Additional details on the process and office hours are on the Breaking Change Wiki.
NOTE: To update API(s) in public preview for over 1 year (refer to Retirement of Previews)
Please follow the link to find more details on PR review process.

"/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/galleries/{galleryName}/images/{galleryImageName}/latestVersionName": {

ARM interpres this as a get on a resource collection not a single resource get .
This API looks like it shoudl be modelled with filters on the collection GET at the version level .. i.e :
subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/galleries/{galleryName}/images/{galleryImageName}/versions?{ODATA FILTER FOR VERSION\LOCATION}
Any reason you are not modelling as such ?

Refers to: specification/compute/resource-manager/Microsoft.Compute/GalleryRP/stable/2022-03-03/gallery.json:528 in 2a2df20. [](commit_id = 2a2df20f2ad8feadd37f9819ffa395fcc6ec5fba, deletion_comment = False)

Hi @raosuhas ,
We actually already have an API: subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/galleries/{galleryName}/images/{galleryImageName}/versions?{ODATA FILTER FOR VERSION\LOCATION}
The reason why this is not the same as that the thing returning from
"/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/galleries/{galleryName}/images/{galleryImageName}/latestVersionName"
is not a artifact 'version', it is versionName instead, that's why we are building a new API for it.
So it is not returning a resource, but a resource name that we need it later.

Hi @raosuhas ,
We actually already have an API: subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/galleries/{galleryName}/images/{galleryImageName}/versions?{ODATA FILTER FOR VERSION\LOCATION}
The reason why this is not the same as that the thing returning from "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/galleries/{galleryName}/images/{galleryImageName}/latestVersionName" is not a artifact 'version', it is versionName instead, that's why we are building a new API for it.
So it is not returning a resource, but a resource name that we need it later.

@Sandido - This is still problematic from ARM perspective. You are creating a new resource type, without full CRUD support. Can you add an OData filter like
subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/galleries/{galleryName}/images/{galleryImageName}/versions?{ODATA FILTER FOR VERSION\Latest}

and have the client read the name from the version resource?
Either way, if you can't support the scenario with filter parameters on the version list request, then the better ARM way of doing this is with a POST action on the gallery image instance, like
/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/galleries/{galleryName}/images/{galleryImageName}/getLatestVersionName

Otherwise the ARM resource model would point to supporting full CRUD on a new versionName resource type and add a filter parameter on the collection GET for latest:
List (Collection GET): /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/galleries/{galleryName}/images/{galleryImageName}/versionNames
Singleton (GET and PUT are required, PATCH and DELETE are optional):
/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/galleries/{galleryName}/images/{galleryImageName}/versionNames/latest

But then, what's the point of getting a version name by giving the version name you want?

Hi @raosuhas ,
We actually already have an API: subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/galleries/{galleryName}/images/{galleryImageName}/versions?{ODATA FILTER FOR VERSION\LOCATION}
The reason why this is not the same as that the thing returning from "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/galleries/{galleryName}/images/{galleryImageName}/latestVersionName" is not a artifact 'version', it is versionName instead, that's why we are building a new API for it.
So it is not returning a resource, but a resource name that we need it later.

@Sandido - This is still problematic from ARM perspective. You are creating a new resource type, without full CRUD support. Can you add an OData filter like
subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/galleries/{galleryName}/images/{galleryImageName}/versions?{ODATA FILTER FOR VERSION\Latest}

and have the client read the name from the version resource?
Either way, if you can't support the scenario with filter parameters on the version list request, then the better ARM way of doing this is with a POST action on the gallery image instance, like
/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/galleries/{galleryName}/images/{galleryImageName}/getLatestVersionName

Otherwise the ARM resource model would point to supporting full CRUD on a new versionName resource type and add a filter parameter on the collection GET for latest:
List (Collection GET): /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/galleries/{galleryName}/images/{galleryImageName}/versionNames
Singleton (GET and PUT are required, PATCH and DELETE are optional):
/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/galleries/{galleryName}/images/{galleryImageName}/versionNames/latest

But then, what's the point of getting a version name by giving the version name you want?

Hey, this ideally needs to be a GET. This shouldn't be a POST imo.
Background:
We have childFanout resource type, and the list versions etc is fanned out to all regions which is not what we want in this case. Also this is not a GET on the versions itself.
Scenario:
Our resource hierarchy has images and images have versions. Versions can be published from different regions, and they can be "replicated" to different target regions. We want to enable the customer to be able to GET the effective latest version name available for use in a particular target region.
I don't see why the ARM is confusing this as a resource type. This is exactly the same case as GET instanceView API on the virtual machine API. Can you check how the below works, and also double check if arm will really get confused? We already tested this out in prod and it was working.
https://docs.microsoft.com/en-us/rest/api/compute/virtual-machines/instance-view?tabs=HTTP

I don't see why the ARM is confusing this as a resource type. ...

ARM isn't confusing this as a resource type: this is a resource type according to the Azure RPC. The resource type/instance tuple is a basic ARM contract. GET is for ARM resources which have a resource envelope with (at minimum) name, id, and type at the top-level and RP-specific properties in a property bag. Ref: https://armwiki.azurewebsites.net/api_contracts/guidelines/rpc.html. GET of the resource type returns a collection of instances, and GET of a resource instance return that resource. Things that aren't ARM resources don't use GET/PUT/PATCH and should use POST instead.
The reason GET "works" is because ARM's behavior when it encounters requests that don't fit the RPC is to route the request to the RP. This allows the request to work, but it means that ARM features often don't work (or work wrong) for those APIs/types.
Your example of instanceView gives a case-in-point for following the RPC instead of replicating existing patterns. InstanceView has caused many issues for ARM because it's a resource type URI/method that's doesn't return a resource type. For example: customers think they should be able to use Azure Policy to manage it but they can't, which leads to customer confusion and frustration.
Note: this comment from @raosuhas https://github.com/Azure/azure-rest-api-specs/pull/20396#issuecomment-1235844513 calling out another RPC anti-pattern also still needs to be addressed.
Tagging @rkmanda (this week's oncall) for visibility.

I don't see why the ARM is confusing this as a resource type. ...

ARM isn't confusing this as a resource type: this is a resource type according to the Azure RPC. The resource type/instance tuple is a basic ARM contract. GET is for ARM resources which have a resource envelope with (at minimum) name, id, and type at the top-level and RP-specific properties in a property bag. Ref: https://armwiki.azurewebsites.net/api_contracts/guidelines/rpc.html. GET of the resource type returns a collection of instances, and GET of a resource instance return that resource. Things that aren't ARM resources don't use GET/PUT/PATCH and should use POST instead.
The reason GET "works" is because ARM's behavior when it encounters requests that don't fit the RPC is to route the request to the RP. This allows the request to work, but it means that ARM features often don't work (or work wrong) for those APIs/types.
Your example of instanceView gives a case-in-point for following the RPC instead of replicating existing patterns. InstanceView has caused many issues for ARM because it's a resource type URI/method that's doesn't return a resource type. For example: customers think they should be able to use Azure Policy to manage it but they can't, which leads to customer confusion and frustration.
Note: this comment from @raosuhas #20396 (comment) calling out another RPC anti-pattern also still needs to be addressed.
Tagging @rkmanda (this week's oncall) for visibility.

Making a GET REST concept POST just because ARM features won't isn't the right solution.
Also, I don't think this is a resource type. Resource types are declared by the RP in the RP manifest according to the RPC. Also, Not all resource types require PUT/DELETE/POST etc according to RPC as RPC allows RPs to have GET only proxy resources also, via various routing types. W can register this as location based GET only proxy-resource if required (not sure if this will work).
But due to above constraints, we can't have it as POST and need to be GET. Also, philosophically and conceptually this is a GET. Today people have to list all versions, filter by replication regions, apply some other filters and find the latest on their own by doing just GETs.

I don't see why the ARM is confusing this as a resource type. ...

ARM isn't confusing this as a resource type: this is a resource type according to the Azure RPC. The resource type/instance tuple is a basic ARM contract. GET is for ARM resources which have a resource envelope with (at minimum) name, id, and type at the top-level and RP-specific properties in a property bag. Ref: https://armwiki.azurewebsites.net/api_contracts/guidelines/rpc.html. GET of the resource type returns a collection of instances, and GET of a resource instance return that resource. Things that aren't ARM resources don't use GET/PUT/PATCH and should use POST instead.
The reason GET "works" is because ARM's behavior when it encounters requests that don't fit the RPC is to route the request to the RP. This allows the request to work, but it means that ARM features often don't work (or work wrong) for those APIs/types.
Your example of instanceView gives a case-in-point for following the RPC instead of replicating existing patterns. InstanceView has caused many issues for ARM because it's a resource type URI/method that's doesn't return a resource type. For example: customers think they should be able to use Azure Policy to manage it but they can't, which leads to customer confusion and frustration.
Note: this comment from @raosuhas #20396 (comment) calling out another RPC anti-pattern also still needs to be addressed.
Tagging @rkmanda (this week's oncall) for visibility.

Making a GET REST concept POST just because ARM features won't isn't the right solution.
Also, I don't think this is a resource type. Resource types are declared by the RP in the RP manifest according to the RPC. Also, Not all resource types require PUT/DELETE/POST etc according to RPC as RPC allows RPs to have GET only proxy resources also, via various routing types. W can register this as location based GET only proxy-resource if required (not sure if this will work).
But due to above constraints, we can't have it as POST and need to be GET. Also, philosophically and conceptually this is a GET. Today people have to list all versions, filter by replication regions, apply some other filters and find the latest on their own by doing just GETs.

OK, thank-you. I appreciate you providing the context and reasoning on this API. @rkmanda will follow this up. Just a few final comments from me to clarify points on the ARM ask/contract:

Readers can be given access to POST in the manifest (action method).
I agree that sometimes there might be a tradeoff/tension between core ARM features and RP features, but I'm not seeing that in this case. There is an RPC-consistent way of doing what you want.
Only tracked resource types and top-level proxy resources are required to be declared in the manifest. Child proxy resource types are not required in the manifest but are still resource types.
PUT and DELETE are not required for proxy resource types, but they are required to have name, type, and id in their top-level properties. And they are required to have both a single and collection GET API.
Making versionName a new location-based proxy resource type should work (as I mentioned previously), but to follow the RPC it would still need to adopt the proxy resource envelope with RP specific properties in a property bag and implement both point and collection GET endpoints. This is probably more work than using POST.
Regarding the solution/philosophy/concepts and ARM/POST vs RP/GET tradeoff: you are saying that versionName should be retrieved by GET because version is retrieved by GET, but versionName is not a real resource type, whereas version is. This distinction matters to the platform you are adding APIs to. GET to an Azure management endpoint with resource-formatted URI is supposed to return an Azure resource (or resource collection in this case), not just any JSON that's useful for the RP and its clients. Customers and platform features depend on this basic RP behavior. The Azure RPC provides POST for APIs that don't follow that pattern: it's an action on a single resource (or at tenant level) that can take any payload and return any payload.

All of that notwithstanding, you can probably make this API work in ARM, even though it will be an outlier from the perspective of expected Azure consistency and behavior.

I don't see why the ARM is confusing this as a resource type. ...

ARM isn't confusing this as a resource type: this is a resource type according to the Azure RPC. The resource type/instance tuple is a basic ARM contract. GET is for ARM resources which have a resource envelope with (at minimum) name, id, and type at the top-level and RP-specific properties in a property bag. Ref: https://armwiki.azurewebsites.net/api_contracts/guidelines/rpc.html. GET of the resource type returns a collection of instances, and GET of a resource instance return that resource. Things that aren't ARM resources don't use GET/PUT/PATCH and should use POST instead.
The reason GET "works" is because ARM's behavior when it encounters requests that don't fit the RPC is to route the request to the RP. This allows the request to work, but it means that ARM features often don't work (or work wrong) for those APIs/types.
Your example of instanceView gives a case-in-point for following the RPC instead of replicating existing patterns. InstanceView has caused many issues for ARM because it's a resource type URI/method that's doesn't return a resource type. For example: customers think they should be able to use Azure Policy to manage it but they can't, which leads to customer confusion and frustration.
Note: this comment from @raosuhas #20396 (comment) calling out another RPC anti-pattern also still needs to be addressed.
Tagging @rkmanda (this week's oncall) for visibility.

Making a GET REST concept POST just because ARM features won't isn't the right solution.
Also, I don't think this is a resource type. Resource types are declared by the RP in the RP manifest according to the RPC. Also, Not all resource types require PUT/DELETE/POST etc according to RPC as RPC allows RPs to have GET only proxy resources also, via various routing types. W can register this as location based GET only proxy-resource if required (not sure if this will work).
But due to above constraints, we can't have it as POST and need to be GET. Also, philosophically and conceptually this is a GET. Today people have to list all versions, filter by replication regions, apply some other filters and find the latest on their own by doing just GETs.

OK, thank-you. I appreciate you providing the context and reasoning on this API. @rkmanda will follow this up. Just a few final comments from me to clarify points on the ARM ask/contract:

Readers can be given access to POST in the manifest (action method).
I agree that sometimes there might be a tradeoff/tension between core ARM features and RP features, but I'm not seeing that in this case. There is an RPC-consistent way of doing what you want.
Only tracked resource types and top-level proxy resources are required to be declared in the manifest. Child proxy resource types are not required in the manifest but are still resource types.
PUT and DELETE are not required for proxy resource types, but they are required to have name, type, and id in their top-level properties. And they are required to have both a single and collection GET API.
Making versionName a new location-based proxy resource type should work (as I mentioned previously), but to follow the RPC it would still need to adopt the proxy resource envelope with RP specific properties in a property bag and implement both point and collection GET endpoints. This is probably more work than using POST.
Regarding the solution/philosophy/concepts and ARM/POST vs RP/GET tradeoff: you are saying that versionName should be retrieved by GET because version is retrieved by GET, but versionName is not a real resource type, whereas version is. This distinction matters to the platform you are adding APIs to. GET to an Azure management endpoint with resource-formatted URI is supposed to return an Azure resource (or resource collection in this case), not just any JSON that's useful for the RP and its clients. Customers and platform features depend on this basic RP behavior. The Azure RPC provides POST for APIs that don't follow that pattern: it's an action on a single resource (or at tenant level) that can take any payload and return any payload.

All of that notwithstanding, you can probably make this API work in ARM, even though it will be an outlier from the perspective of expected Azure consistency and behavior.

Thanks for sharing your opinion! I can see where you are coming from. The ground truths are the following, I think we agree on this:

This is a "read"/GET API scenario
POST actions are "write" by-default (as confirmed byt the default permissions too)
Given that POST itself is outlier in rest concepts, it is possible to virtually replace all APIs with just POST-style API design.

So, the tension here is, IMHO, not between RPC and RP, but RPC and Rest-over-HTTP principles in my opinion.
But either way, you do bring a good point of RPC providing a consistency and being the reality of azure.
By making this a post, we will have to model a read as a write, and then workaround permissions/throttling etc issues which arise later.
Can you help us point to how to make the POST Api accessible to readers?
Since, now we are operating in less than ideal world, the reality is also that the API release (march 2023) is late by >6months due to various red-tape and process issues we encountered, and we have an internal service already implementing/waiting on this API contract to deliver the final product by 09/30. So we will do whatever can get us unblocked fast.
So I would suggest to do the following:

Maybe we can continue as GET but back it out of swagger and keep the API exposed to the internal service as GET to avoid missing 9/30 deadline.
ARM team will help us to allow readers get access to the POST, and provide guarantees that this would not cause any throttling issues etc by being a POST/write api. Are POSTs treated different in throttling as compared to GETs?
Once we have this - we can support POST, move the internal team to use POST and deprecate the GET.
Insert this API in next swagger with POST.

Does this sound good to you, or could you please suggest a better way?
Also, Other than this API, do you see any other blockers to let the API-release go forward?
Thanks again for your help!

          "$ref": "../../../common-types/v1/common.json#/definitions/CloudError"

change all these to v3

Refers to: specification/compute/resource-manager/Microsoft.Compute/GalleryRP/stable/2022-03-03/gallery.json:1160 in 77e5c9c. [](commit_id = 77e5c9cd13c9b850f440ea042b790554437a1311, deletion_comment = False)

"GalleryArtifactVersionSource": {

removing uri is a breaking change. Please revert this or get a breakingchanges approval

Refers to: specification/compute/resource-manager/Microsoft.Compute/GalleryRP/stable/2022-03-03/gallery.json:2753 in 77e5c9c. [](commit_id = 77e5c9cd13c9b850f440ea042b790554437a1311, deletion_comment = False)


Add map, mMap combinators

Proposed in https://github.com/ds300/derivablejs/pull/89 map and mMap methods.
Not overloaded versions are 25% faster as you can find in added benchmarks
"mapper": {
  "derive": {
    "hz": 7.157623587567227,
    "rme": 6.148182799800633,
    "samples": 22
  },
  "map": {
    "hz": 9.601906213218516,
    "rme": 6.922336536128435,
    "samples": 28
  }
}

/cc @ds300 @andreypopp

Derivable with derive method is functor in terms of fp, so it won't confuse and conflict with different types (types + namespace). Also derive method will conflict with lightweight derive function, since they'll have different functionality.

Ok, go for it! :+1:


[tw] Localize Kubernetes for Traditional Chinese

Describe your changes
Origin content from https://glossary.cncf.io/kubernetes/
Related issue number or link (ex: resolves #issue-number)
resolves #2297
Checklist before opening this PR (put x in the checkboxes)

[x] This PR does not contain plagiarism

don’t copy other people’s work unless you are quoting and contributing it to them.

[x] I have signed off on all commits

signing off (ex: git commit -s) is to affirm that commits comply DCO. If you are working locally, you could add an alias to your gitconfig by running git config --global alias.ci "commit -s".

@hwchiu 我有更新我的 pr 了，再麻煩你看看，謝謝。


Bug report: Error 128 in recent activity

Checks

[X] I use a supported version of Recent Activity.
[X] I searched the issues page for already existing bug reports.

Description

Steps to reproduce
Re-run the action from here
Configuration
name: Update README

on:
  schedule:
    - cron: '*/30 * * * *' # Update every 30 minutes
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    name: Update Profile README

    steps:
      - uses: actions/checkout@v3
      - uses: Readme-Workflows/recent-activity@main
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          CONFIG_FILE: "./.github/activity-recent.config.yml"

settings:
  username: "ahmaddyd"
  commit_msg: "Update Readme"
  max_lines: 0
  readme_file: "README.md"
  disabled_events: [event1, event2, event3]
  url_text: "{REPO}{ID}"
  date:
    timezone: "GMT+07:00"
    text: "Last Update : {DATE}"
    format: "dddd, mmmm dS, yyyy, h:MM:ss TT"
  commit_name: "ahmaddyd"
  commit_email<EMAIL_ADDRESS>
Expected behaviour
It however worked on the official repo. but it doesn't work on mine
Actual behaviour
{ hello: 'readme-workflows.glitch.me' }
⬤  debug     Something went wrong
✖  fatal     Error: Invalid status code: 128
at ChildProcess. (/home/runner/work/_actions/Readme-Workflows/recent-activity/main/dist/index.js:20:171504)
at ChildProcess.emit (node:events:390:28)
at maybeClose (node:internal/child_process:1064:16)
at Socket. (node:internal/child_process:450:11)
at Socket.emit (node:events:390:28)
at Pipe. (node:net:687:12)
Failed runs
https://github.com/ahmaddyd/ahmaddyd/actions/runs/3917485373/jobs/6697296142

halo anyone can help me for my issue?

I will have a look on the working day.

Thank you for your reply sir!
Can you opened up a PR fixing the my issue, please

Same problem here

Try changing your commit email to your registered github email.

Same, still not running for workflows

Refer this
Cause and solution:

It's probably because your SSH key has been removed/revoked. Make a new one and add it to your GitHub account.

i have tried it but it doesn't work

Solved my problems Sir, Thank You

Hi @ahmaddyd, could you please explain exactly what you did to solve the problem? I'm currently having this same issue and I just can find the reason.

Solved my problems Sir, Thank You

Hi @ahmaddyd, could you please explain exactly what you did to solve the problem? I'm currently having this same issue and I just can't find the reason.

Hi everyone! After a huge search, I found this issue related to the 128 code error problem and the solutions provided from @realnikolaj worked for me:


Special chars in window titel

If you use special chars in blog names like Sheogorath's Blog the ' is placed as ' in the title.
I guess this also happens by other special chars.

I don't think we've rolled the fix into the built version of Ghost-Desktop, but #86 should fix this, and has been merged into master.
Thanks!

Yep, fixed in #86. Closing.


node.js v4 support

Hi!
In the latest release published ('0.1.17': '2017-05-30T11:07:09.749Z') it seems to have broken compatibility with node.js 4.X. The module make use of Buffer.from, but this is not supported in node.js v4.
Would you be open to making a new patch release of 0.1.18 that removes reliance on Buffer.from, or perhaps is simply 0.1.16 code again? After this then publish a 1.0.0? The reason I suggest this is because copy-webpack-plugin relies on this module as a ^ dependency, so even if you release 0.2.0 with Buffer.from it will still potentially break many people making builds with node.js 4.X.
In a 1.0.0 it would make sense to set "engines" in package.json to `>=5.x.

Closing since this is a duplicate


Commit 0b84619b82fe1ccb366c89fa55d69657516605b3 breaks our local application.

Hey,
The commit 0b84619b82fe1ccb366c89fa55d69657516605b3 breaks my system (viur-core-logs below) when running it locally on my Arch Linux machine.
The problem is, that the module cloud, (import in /deploy/viur/core/modules/) does not exist. May I miss something while initializing of the project or the development environment?

[2021-02-12 13:16:29 +0100] [97405] [INFO] Starting gunicorn 20.0.0
[2021-02-12 13:16:29 +0100] [97405] [INFO] Listening at: http://<IP_ADDRESS>:23908 (97405)
[2021-02-12 13:16:29 +0100] [97405] [INFO] Using worker: threads
[2021-02-12 13:16:29 +0100] [97408] [INFO] Booting worker with pid: 97408
WARNING  2021-02-12 13:16:30,273 tasks.py:58] Taskqueue disabled, tasks will run inline!
DEBUG    2021-02-12 13:16:30,273 _default.py:180] Checking store_credentials.json for explicit credentials as part of auth process...
[2021-02-12 13:16:30 +0100] [97408] [ERROR] Exception in worker process
Traceback (most recent call last):
  File "/tmp/tmpccI_eR/lib/python3.9/site-packages/gunicorn/arbiter.py", line 583, in spawn_worker
    worker.init_process()
  File "/tmp/tmpccI_eR/lib/python3.9/site-packages/gunicorn/workers/gthread.py", line 92, in init_process
    super().init_process()
  File "/tmp/tmpccI_eR/lib/python3.9/site-packages/gunicorn/workers/base.py", line 133, in init_process
    self.load_wsgi()
  File "/tmp/tmpccI_eR/lib/python3.9/site-packages/gunicorn/workers/base.py", line 142, in load_wsgi
    self.wsgi = self.app.wsgi()
  File "/tmp/tmpccI_eR/lib/python3.9/site-packages/gunicorn/app/base.py", line 67, in wsgi
    self.callable = self.load()
  File "/tmp/tmpccI_eR/lib/python3.9/site-packages/gunicorn/app/wsgiapp.py", line 49, in load
    return self.load_wsgiapp()
  File "/tmp/tmpccI_eR/lib/python3.9/site-packages/gunicorn/app/wsgiapp.py", line 39, in load_wsgiapp
    return util.import_app(self.app_uri)
  File "/tmp/tmpccI_eR/lib/python3.9/site-packages/gunicorn/util.py", line 331, in import_app
    mod = importlib.import_module(module)
  File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 790, in exec_module
  File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
  File "<censored>/deploy/main.py", line 28, in <module>
    from viur.core.modules.file import thumbnailer
  File "<censored>/deploy/viur/core/modules/file.py", line 30, in <module>
    from google.cloud import iam_credentials_v1
ImportError: cannot import name 'iam_credentials_v1' from 'google.cloud' (unknown location)
[2021-02-12 13:16:30 +0100] [97408] [INFO] Worker exiting (pid: 97408)
Waiting up to 5 seconds.
DEBUG    2021-02-12 13:16:30,429 requests.py:181] Making request: POST https://oauth2.googleapis.com/token
DEBUG    2021-02-12 13:16:30,430 connectionpool.py:971] Starting new HTTPS connection (1): oauth2.googleapis.com:443
DEBUG    2021-02-12 13:16:30,543 connectionpool.py:452] https://oauth2.googleapis.com:443 "POST /token HTTP/1.1" 200 None
DEBUG    2021-02-12 13:16:30,625 background_thread.py:123] Submitted 1 logs
DEBUG    2021-02-12 13:16:30,721 background_thread.py:123] Submitted 2 logs
DEBUG    2021-02-12 13:16:30,721 background_thread.py:160] Background thread exited gracefully.
Sent all pending logs.
[2021-02-12 13:16:30 +0100] [97405] [INFO] Shutting down: Master
[2021-02-12 13:16:30 +0100] [97405] [INFO] Reason: Worker failed to boot.

Hey @klaus-thorres,
I just had the same problem.
After using the same dependencies as in the base, the core worked again. Check which versions you are using.
Best regards, Sven

Hey @sveneberth,
thanks for the hint. I had to update my local requirements.txt file, so that the needed modules are loaded on startup.
Cheers,
Klaus

Resolved by updating requirements.txt


fix: Call_RESERVE_RESOURCES -> Call_UNRESERVE_RESOURCES

Coverage remained the same at 73.177% when pulling 8c720f8521936cff7a1efb04ba426d6199b3f22b on zhizuqiu:master into 18c4db1064bc94de2fe655a590ae5d6f69cdc7ab on miroswan:master.

Thanks for your contribution. Would you mind opening this PR against the dev branch? I'll update README.md to include this.

Thanks for your contribution. Would you mind opening this PR against the dev branch? I'll update README.md to include this.

ok!


Feature/adding all values in images enum

Add an array in the images enum so we can iterate over them.

I think that feature is very rarely useful (I never had to iterate over all the images in my Assets Catalog, and don't think most of people do), so I think that'll make the generated file quite long (like when people have 100+ images in their assets catalog)
So here's what I suggest:

Keep the existing template unchanged (and revert the examples in README & Playground)
Create a separate template that adds what you did so we can have this allValues entry, but as an opt-in option. People wanting to have this could simply use your template instead of the default one.
I'll then include your template alongside mine when SwiftGen is installed. Once #42 is merged, which would allow people to use --templateName to specify a template by name instead of by full path, this would make it easier for people to choose the default template without allValues or your template with it

Merged via d430f568a7cf98abfa58c94b3bf029db2853362d

Thank you very much to accept this MR :-) :+1:

Now that #50 is merged, you'll be able to use swiftgen images -t allvalues PATH in order to use this specific template which will be bundled with SwiftGen in the next release.


Deferred values don't seem to work for postgres_password (aka admin password)

Describe the Bug
When passing a Deferred value to the postgres_password parameter I get the following error message:
Failed on [...]:
  Apply failed to compile for [...]: 'postgresql::postgresql_escape' parameter 'input_string' expects a String value, got Deferred (file: /[...]/.modules/postgresql/manifests/server/passwd.pp, line: 28, column: 16)

Expected Behavior
Expected deferred values to work, that is simply setting the value to the deferred value.
Steps to Reproduce
Setup a default instance and run something similar to the below:
class { '::postgresql::server':
    postgres_password => Deferred('unwrap', [$admin_password_vault]),
}

Environment

Version: 8.2.1 (also with 10.0.2)
Platform: CentOS 7

Additional Context

This seems to have been implemented for role passwords, but not the root password.


Adds tests for ShipmentLineItem methods

Description
I was helping Mikena debug FetchApprovedPreapprovalRequestsByShipment, so I wrote a test for it. Then I wrote tests for all the other untested functions in that model.
Code Review Verification Steps

[ ] Code follows the guidelines for Logging
[ ] The requirements listed in
Querying the Database Safely
have been satisfied.
Any new migrations/schema changes:

[ ] Follow our guidelines for zero-downtime deploys (see Zero-Downtime Deploys)
[ ] Have been communicated to #dp3-engineering

[ ] There are no aXe warnings for UI.
[ ] This works in IE.
Any new client dependencies (Google Analytics, hosted libraries, CDNs, etc) have been:

[ ] Communicated to @willowbl00
[ ] Added to the list of network dependencies

[ ] Tested in the Experimental environment (for changes to containers, app startup, or connection to data stores)
[ ] Request review from a member of a different team.
[ ] Have the Pivotal acceptance criteria been met for this change?

I'll take a look on Monday. Thanks for doing this! 🙌


Factories cannot randomly generate missing parameters for child factories if all params passed on higher level

When at least one field doesn't passed in nested objects all child objects created right way:
from pydantic_factories import ModelFactory
from pydantic import BaseModel

class A(BaseModel):
    name: str
    age: int

class B(BaseModel):
    a: A
    name: str  # THIS LINE DIFFERENT TO NEXT EXAMPLE

class C(BaseModel):
    b: B
    name: str

class CFactory(ModelFactory):
    __model__ = C

CFactory.build(**{'b': {'a': {'name': 'test'}}})
# C(b=B(a=A(name='test', age=8345), name='dLiQxkFuLvlMINwbCkbp'), name='uWGxEDUWlAejTgMePGXZ')

However if we pass all fields in nested objects then nested objects creation ignored:
from pydantic_factories import ModelFactory
from pydantic import BaseModel

class A(BaseModel):
    name: str
    age: int

class B(BaseModel):
    a: A
    # name: str  # THIS LINE DIFFERENT TO PREV EXAMPLE

class C(BaseModel):
    b: B
    name: str

class CFactory(ModelFactory):
    __model__ = C

CFactory.build(**{'b': {'a': {'name': 'test'}}})

---------------------------------------------------------------------------
ValidationError                           Traceback (most recent call last)
Cell In [19], line 1
----> 1 CFactory.build(**{'b': {'a': {'name': 'test'}}})

File ./venv/lib/python3.10/site-packages/pydantic_factories/factory.py:724, in ModelFactory.build(cls, factory_use_construct, **kwargs)
    721         return cast("T", cls.__model__.construct(**kwargs))
    722     raise ConfigurationError("factory_use_construct requires a pydantic model as the factory's __model__")
--> 724 return cast("T", cls.__model__(**kwargs))

File ./venv/lib/python3.10/site-packages/pydantic/main.py:342, in BaseModel.__init__(__pydantic_self__, **data)
    340 values, fields_set, validation_error = validate_model(__pydantic_self__.__class__, data)
    341 if validation_error:
--> 342     raise validation_error
    343 try:
    344     object_setattr(__pydantic_self__, '__dict__', values)

ValidationError: 1 validation error for C
b -> a -> age
  field required (type=value_error.missing)

that explained by next logic https://github.com/starlite-api/pydantic-factories/blob/main/pydantic_factories/factory.py#L200
expected that child objects created in both cases

it does appear to be a bug.
@jtraub - feel like picking this one up as well?

@Goldziher Sure, I'll take into this either tonight or tomorrow.


Lacks project-aware context

Very bad in understanding the context of the code - GitHub Copilot doing better job than this

@ulugbekna I think your question already answers it.
Basically would be important when using Chat to be able to specify in the interface without having to text, what is the context.
Open (current one) / Workspace Project specific / Current open file.

@ulugbekna Not understanding the libraries and NuGet packages we are using, sample codes popping with totally irrelevant NuGet packages

I've tried to given direct absolute path to help copilot to understand the context but no effect at all:
By exemple:
In the current workspace project (/home/my/project): Can you implement the missing method "method1" in the file "/home/my/project/MyClass.php".

Please refer to "/home/my/project/MyReferenceClass.php" to match with expected behavior.

But copilot generated basic non contextualized code without any relevant code, in terms of project context or even regarding the ReferenceClass

Yes it gives errors sometimes while chatting as well and cant understand longer boilerplate code so it should be improved

duplicate of #14

Sharing from #14: @workspace with "Used references" landed in Copilot Chat 0.10 as part of VS Code's October release

Please give it a try and file new issues for any follow-up feedback!


read.maf fails due to 'Hugo_Symbol' not found in input

I get this error trying to load a maf file downloaded from https://github.com/mcfrith/last-genome-alignments
Is the MAF mis-formated somehow?
> x = read.maf('~/Downloads/hg38-mm10-2.maf.gz')
-Reading
Error in data.table::fread(cmd = paste("zcat <", maf), sep = "\t", stringsAsFactors = FALSE,  :
  skip='Hugo_Symbol' not found in input (it is case sensitive and literal; i.e., no patterns, wildcards or regex)

Hi,
I am afraid that the file you are trying to read is Multiple Alignment Format. This tool is intended to process Mutation Annotation Format files. Sorry for the acronym discrepancies.


Upgrade OpenSSH to 9.8p1 to resolve the Regresshion CVE

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

[x] The toolchain has been rebuilt successfully (or no changes were made to it)
[x] The toolchain/worker package manifests are up-to-date
[x] Any updated packages successfully build (or no packages were changed)
[x] Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
[x] Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
[x] All package sources are available
[x] cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
[x] LICENSE-MAP files are up-to-date (./SPECS/LICENSES-AND-NOTICES/data/licenses.json, ./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md, ./SPECS/LICENSES-AND-NOTICES/LICENSE-EXCEPTIONS.PHOTON)
[x] All source files have up-to-date hashes in the *.signatures.json files
[x] sudo make go-tidy-all and sudo make go-test-coverage pass
[x] Documentation has been updated to match any changes to the build system
[x] If you are adding/removing a .spec file that has multiple-versions supported, please add @microsoft/cbl-mariner-multi-package-reviewers team as reviewer (Eg. golang has 2 versions 1.18, 1.21+)
[x] Ready to merge

Summary
This upgrade resolves Critical CVE-2024-6387 which is a regression for CVE-2006-5051.  Note that this version of openssh splits the server into two binaries, so there is a packaging difference from the previous version.  The server/listener (sshd) and a separate binary that hosts the session (sshd-session).
Does this affect the toolchain?

NO
Links to CVEs

https://nvd.nist.gov/vuln/detail/CVE-2024-6387

Test Methodology

Buddy build and manually installed the client and server package.  Verified that I could connect to the server and verified that the ssh client functioned.
Note that the pTest currently fails for ssh because the Azure Linux version of openssh does not include the secure-key (libraries).  A separate bug is tracking to resolve post GA.

Fixes:

#9555


Patched for php7

Please make sure to create a new branch, this is NOT compatible with php5.x!

Thank you for your contribution. I'll probably merge a slightly different version but that doesn't matter.

I just needed it to work and to my surprise I succeeded in achieving that... Tested in production since about a week after php7 was released... But I don't actually know C, and I'm pretty sure my 5 lines ought to be 1, so no offense taken if you clean up a bit before merging ;)

Closes #2

Merged via d8f0304d9f8b72c55422991ff863ef60df3b9157.


[bug] (node:41354) UnhandledPromiseRejectionWarning: Error: failed to run cargo: No such file or directory (os error 2)

Describe the bug
When I add vue-cli-plugin-tauri to an existing vue project and run npm run tauri:serve throws an error (node:41354) UnhandledPromiseRejectionWarning: Error: failed to run cargo: No such file or directory (os error 2)
Reproduction
No response
Expected behavior
No response
Platform and versions
Version:
    "vue-cli-plugin-tauri": "~1.0.0-rc.1"
    "vue": "^3.2.31",

Stack trace
No response
Additional context
No response

Did you follow the installation instructions for your OS?


Promoting request and severity metadata fields

These fields will soon be mandatory. This commit will likely require us to make the next release v0.8.0 ;-)
(PR #1840)

I am actually renaming request to proposal as it seems to be a better fitting term. (we even have a "New Check Proposal" tag in the issue tracker)