SDK Generation for Microsoft.StorageSync RP created files in Storage folder instead of StorageSync folder

Classes were created in H:\csharpsdk\azure-sdk-for-net\src\SDKs\Storage\Management.StorageSync
Log file is empty : H:\csharpsdk\azure-sdk-for-net\src\SDKs_metadata\storagesync_resource-manager.txt
StorageSyncService class was inherited from TrackedResource class in swagger spec but in generation it was derived from IResource., and hence failed compiling.
Actual : public partial class StorageSyncService : IResource
Expected : public partial class StorageSyncService : TrackedResource

Swagger spec : https://github.com/Azure/azure-rest-api-specs/blob/master/specification/storagesync/resource-manager/Microsoft.StorageSync/stable/2018-04-02/storagesync.json
Sdk fork : https://github.com/ankushbindlish2/azure-sdk-for-net
Branch : https://github.com/ankushbindlish2/azure-sdk-for-net/tree/storagesync-addsdk
Local share :
\ankushb-dt\csharpsdk\azure-rest-api-specs
\ankushb-dt\csharpsdk\azure-sdk-for-net\src\SDKs\StorageSync
"StorageSyncService": {
"type": "object",
"description": "Storage Sync Service object.",
"allOf": [
{
"$ref": "#/definitions/TrackedResource"
},
{
"properties": {
"properties": {
"x-ms-client-flatten": true,
"$ref": "#/definitions/StorageSyncServiceProperties",
"description": "Storage Sync Service properties."
}
}
}
],
"x-ms-azure-resource": true
},
PS H:\csharpsdk\azure-sdk-for-net\src\SDKs\StorageSync> dir
Directory: H:\csharpsdk\azure-sdk-for-net\src\SDKs\StorageSync

Mode                LastWriteTime         Length Name

d-----        8/20/2018  11:54 AM                Management.StorageSync
d-----        8/20/2018  11:55 AM                StorageSync.Tests
PS H:\csharpsdk\azure-sdk-for-net\src\SDKs\StorageSync> cd .\Management.StorageSync
PS H:\csharpsdk\azure-sdk-for-net\src\SDKs\StorageSync\Management.StorageSync> .\generate.ps1
Directory: H:\csharpsdk\azure-sdk-for-net\src\SDKs\_metadata

Mode                LastWriteTime         Length Name

-a----        8/20/2018  11:59 AM              0 storagesync_resource-manager.txt
Installing AutoRest version: latest

<EMAIL_ADDRESS>preinstall C:\Users\ankushb\AppData\Roaming\npm\node_modules\autorest
node ./preinstall-check

C:\Users\ankushb\AppData\Roaming\npm\autorest -> C:\Users\ankushb\AppData\Roaming\npm\node_modules\autorest\dist\app.js

<EMAIL_ADDRESS>updated 1 package in 1.63s

AutoRest installed successfully.
Commencing code generation
Generating CSharp code
Executing AutoRest command
cmd.exe /c autorest.cmd https://github.com/Azure/azure-rest-api-specs/blob/master/specification/storagesync/resource-manager/readme.md --csharp --version=latest --reflect-api-versions --csharp-sdks-folder=H:\csharpsdk\azure-sdk-for-net\src\SDKs
AutoRest code generation utility [version: 2.0.4283; node: v8.11.2]
(C) 2018 Microsoft Corporation.
https://aka.ms/autorest
C:\Users\ankushb.autorest<EMAIL_ADDRESS>-> C:\Users\ankushb.autorest@microsoft.azure_autorest-core<EMAIL_ADDRESS>C:\Users\ankushb.autorest<EMAIL_ADDRESS>-> C:\Users\ankushb.autorest@microsoft.azure_autorest-core<EMAIL_ADDRESS>Loading AutoRest core      'C:\Users\ankushb.autorest@microsoft.azure_autorest-core<EMAIL_ADDRESS>(2.0.4283)
Installing AutoRest extension<EMAIL_ADDRESS>(~2.3.79)
Installing AutoRest extension<EMAIL_ADDRESS>(2.3.55)
2018-08-20 19:00:27 UTC
Azure-rest-api-specs repository information
GitHub fork: Azure
Branch:      master
Commit:      ce519b0f5ae661b74635ed658e0ec684e78bf5a8
AutoRest information
Requested version: latest
Bootstrapper version<EMAIL_ADDRESS>Log file can be found at location H:\csharpsdk\azure-sdk-for-net\src\SDKs_metadata\storagesync_resource-manager.txt
PS H:\csharpsdk\azure-sdk-for-net\src\SDKs\StorageSync\Management.StorageSync>
PS H:\csharpsdk\azure-sdk-for-net\src\SDKs\StorageSync\Management.StorageSync> H:\csharpsdk\azure-sdk-for-net\src\SDKs_metadata\storagesync_resource-manager.txt

@ankushbindlish2 regarding the compiler error you are seeing in the generated code, please model the TrackedResource using the common model definition from this location
https://github.com/Azure/azure-rest-api-specs/blob/master/specification/common-types/resource-management/v1/types.json#L45
Here is one such example of it's usage
https://github.com/Azure/azure-rest-api-specs/blob/ac8857e5386be4f11d7ce84183ec1e686f585af4/specification/automation/resource-manager/Microsoft.Automation/stable/2015-10-31/dscConfiguration.json#L656

Sure, Will try.

What's the problem with underlying swagger spec. I have seen similar spec with other RP.
Did we find out why we are generating it in wrong location. storage instead of storagesync

@ankushbindlish2 Are you planning to create a new directory under src/SDKs/StorageSync or do you wish to generate the code alongside src/SDKs/Storage/Microsoft.Storage?
For case 1, please modify the config file here and modify the output-folder under C# section (replace SDKs/Storage with SDKs/StorageSync)
For case 2, I believe the files should already be generated as expected.
Let us know if there is anything else we can help with

Abhijeet Shah<EMAIL_ADDRESS>has all context on this issue.
yes. StorageSync, Will look at case 1

will fix read me.  output-folder: $(csharp-sdks-folder)/Storage/Management.StorageSync/Generated

thanks !

@ankushbindlish2 merged the REST spec PR. Please try regenerating and close the issue if you're unblocked

Sure. Will try first thing tomorrow morning.

It solved issue 1 , but not 2 and 3

@ankushbindlish2 could you explain what the problem is now? Feel free to ping offline

@ankushbindlish2 dp you still have any issues here

no. I will continue prepare a c# sdk pull request.

Perfect, feel free to open a new issue if anything is off


feat(ai): Add Pursue behavior from gdx-ai

Description
This is the beginning of the work on porting the gdxAI library into dart and integrating it into the Flame engine.
This PR adds the Pursue behavior, and implements some of the basic interface classes such as Steerable, Limiter, Location, SteeringBehavior, and SteeringAcceleration.
I have also made some modifications to the original Pursue algorithm, for comparison the timings of the old and the new algorithm are as follows:

test name
original time
current time

pursuit exact
7.0
7.0

pursuit 1
4.34
4.28

pursuit 2
1000
14.34

pursuit 3
1000
2.6

pursuit 4
12.90
4.8

pursuit 5
20.26
10.84

pursuit 6
1.18
1.18

chase 1
305.6
302.8

chase 2
252.6
250.4

chase 3
17.3
16.2

https://user-images.githubusercontent.com/4231472/147298375-8a5de9b3-7a18-41e9-bf1d-9707963347fd.mov
Checklist

[x] The title of my PR starts with a Conventional Commit prefix (fix:, feat:, docs: etc).
[x] I have read the Contributor Guide and followed the process outlined for submitting PRs.
[x] I have updated/added tests for ALL new/updated/fixed functionality.
[x] I have updated/added relevant documentation in docs and added dartdoc comments with ///.
[x] I have updated/added relevant examples in examples.

Breaking Change

[x] No, this is not a breaking change.

Related Issues
WIP for #1164

Maybe this should be flame_ai? Do we need to include the licence in the header of each file, can it not be in its separate licence file?

Maybe this should be flame_ai bridge package?

Well, there is nothing to bridge to. The gdx-ai library is in Java, so cannot be referenced directly. Plus, this library will eventually be deeply integrated with main Flame; for example all logic for camera motion are the examples of behaviors (seek/pursuit), so we'll refactor them later to make Camera steerable.

Do we need to include the licence in the header of each file, can it not be in its separate licence file?

Here's how I understand the conditions imposed upon us by the Apache-2 license:

"You must give any other recipients of the Work or Derivative Works a copy of this License;" -- this copy is in the readme file;
"You must cause any modified files to carry prominent notices stating that You changed the files;" -- this is why every file has "translated into Dart with modifications" in capital letters;
"You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works" -- this is why every file carries the copy of the boilerplate note taken from the original file;
"If the Work includes a "NOTICE" text file as part of its distribution ..." -- not applicable since they don't have a NOTICE file.

I've also included a line stating that the translated file's copyright really belongs to the Blue Fire project, not to the original gdxAI team.

Porting an AI library should be done in a bridge package, like flame_gdx_ai. Similar to how we do flame_box/forge2d.
If our core Flame code is not flexible enough to allow any couplings we want to be done from the flame_x package side, we should, instead, improve it so it does.

Porting an AI library should be done in a bridge package, like flame_gdx_ai. Similar to how we do flame_box/forge2d.

There is forge2d package, and flame_forge2d serves as a bridge, allowing to easier use forge2d library together with the core Flame. Similarly, there is rive package, and then flame_rive serves as a bridge to bring Rive animations into Flame. But there is no gdx-ai package (not in Dart ecosystem at least). There is nothing to bridge to.
In addition, this functionality does belong to the Flame core. We already have some rudimentary steering behaviors, although they are done in a bespoke non-reusable way. So, this is going to be a massive upgrade of the existing functionality.

Despite the name, the bridge packages don't necessarily need to "bridge" to anything external, even though most do. For example, flame_splash_screen doesn't bridge to a 3rd package; rather, it contains within itself all of its functionality, that we thought to separate from Flame just for separation of concerns. The forge2d package exists because we decided to created it, as a place to port box2d (existing non-dart lib) into dart. Similarly, if we are porting an external library from another language, it would be much more valuable to encapsulate it in a dart package, so that anyone can use it, even if they don't use Flame itself, or even Flutter. Then, the flame bridge package would just bridge that into Flame components and reusable pieces. Similar to how we extracted canvas_test and that package is valuable to anyone testing canvas, idependently of Flame. Regardless of the 3rd package being made (to provide the implementation to the dart community outside of Flame), I think the code should be better separated into its own package. I am not aware of any AI related coded currently inside Flame, sounds like a very extensive set of tools that would be great to have but feel like could be properly separated. I am not sure what you mean by steering behaviors.

Separation of concerns is great when done on the level of methods, or classes, or even sub-packages. But separating things into different libraries is a step too far. Just because effects can, in theory, be torn away and put into a separate library -- doesn't mean they should. Just because particle systems, or collision detection, or some other components like text or parallax can be separated into their own tiny libraries -- doesn't mean they should.
There is very little in terms of benefits that can be achieved there, whereas the cost is quite immediate and real. These costs are: (1) the need to maintain another 2 separate libraries, (2) the need to build a separate documentation system, (3) the need to create a new test harness, (4) the need to build a separate example library, (5) the cost of synchronizing APIs between libraries, (6) separate release schedule, etc.
Taken together, that's a big cost. And I'm not saying this theoretically: from the very practical standpoint, none of the libraries that we released as separate packages achieve the same level of quality as the main Flame library.
In short, I'm not in favor of shooting a project in the foot before it even had a chance to make its first baby steps.

I agree with this, we shouldn't make bridge libraries just because we can, it will be less easy for the user to use too. But I think we need a plan for what should be ported here, if there will be a lot of changes I think this should start off as a separate package (not two) with a version <1.0.0 and then simply move it in when it is done. If this feat is expected to have a fairly stable api within 2 months (next stable release) then I think it can be kept in the main package.

It is difficult to anticipate the amount of change that will be needed. On one hand, the source library is quite stable. On the other, there's been quite a few non-trivial adjustments to their code just in making this PR.
We could simply avoid exporting this into main Flame namespace. Thus, if someone wants to use it, they'd have to access it via package:flame/lib/src/ai/....

I agree with people that this should be a separate package.

We could simply avoid exporting this into main Flame namespace. Thus, if someone wants to use it, they'd have to access it via package:flame/lib/src/ai/....

I think that sounds like a pretty good compromise, until it becomes more stable and we'll export it.

Possibly rename the directory to something else than AI, I think this is much more generic than that?

What do you have in mind?
To me, "AI" sounds generic enough: artificial intelligence -- any functionality that helps make your game more smart. In addition to behaviors, we'll also have reactive actions, movement in formations, path-finding, behavior trees, etc.

We talked in the team yesterday about having this as a separate library or not, since Erick and Luan seem to prefer that.
And I had a more thorough look at gdx-ai today, and it is massive!
The pros and cons I see are the following (please fill in the list with things I miss):
As two packages gdx-ai (maybe named something fitting our "naming convention") and flame_gdx_ai:

The code in gdx-ai can be re-used in any dart project.
It can be released whenever deemed necessary.

More maintenance overhead since two more libraries need to be released.
Possibly docs, but the plan is to have all docs in the flame docs I think.

Inside of Flame:

Easier to use for our users.

Possibly a lot more code in the main package.

If we have a pure Dart gdx-ai port we can have you as the maintainer of that lib, if that is something you'd be interested in @st-pasha?

Here's how I view the breakdown of various factors:
Inside of Flame

+ Easier to use for our users
This is a somewhat weak benefit: sure, it's much easier to depend on a single package than on three different ones, while  also keeping up-to-date with upgrading their versions, etc. But it's not too much work.
+(+) Discoverability
If the code is inside Flame, then it will be documented and the users will know that it's available for use. If the code is outside then it's much harder to discover. This warrants 1 + if we advertise the library on the main page of Flame docs, and 2 +s if we don't.
++ Trust
Any external package that the user might want to use, needs to be vetted. Is it trustworthy? Is it actively maintained? Is it supported by a single developer or a team (bus factor)? Is it well documented? etc. Being inside Flame, all of these qualities are automatic.
o A lot more code in the main package
In some languages, having lots of code in the library is problematic, because the library is compiled into a single executable, and that executable is then used by the downstream users. However, Dart is not such a language. The tree-shaking algorithm ensures that the users who don't use these features will not be burdened by them.
o The code will need to be maintained
I understand how this could be perceived as a -, but in reality the code will need to be maintained anyway -- whether it'll be in Flame or in some other repo. And maintaining it inside Flame is easier, because there will be less temptation to "sweep it under the rug".
+++ Ease of development
This is a huge benefit from the developer standpoint. Flame has existing system for publishing examples/documentation. The Flame engine is needed for running tests. Compared to the alternatives, it's much easier to make changes in one package that are needed in another (this is currently a major pain point with our existing packages mock_canvas and ordered_set).
++ Flame is perceived as a more powerful library
The users will appreciate that Flame can fulfill all or most of their needs for game development, without them having to "shop for extra parts". This is like a difference between renting a fully-furnished apartment, and a bare-walls one. In practice you can think of it like this: in the popularity context between different libraries, people try to use at easily available metrics: stars on github, mentions on StackOverflow, downloads on pub.dev etc -- spreading the functionality across many small packages makes each of them appear small and insignificant, whereas taken together they are much more powerful.

Externally

+ The code can be reused in other Dart projects
This is a weak benefit: the code is useful for games only. And it can be reused when it is inside Flame too, though there could be a perception that it is somehow "too heavy". It is not, because of the tree-shaking.
- Separate release process
I'm putting this as a - because Flame is already committed to regular releases, so compared to the first option there is little to be gained by having a separate release process. However, release process has its costs, and these costs will now have to be paid in full.
-- Documentation
Currently we have a working system for publishing Flame documentation for each version (including examples). There is no comparable system for all other packages (even those in the mono-repo). Until such system is developed, this would be a major drawback.
There could also be different variants for the dependence structure:

Flame depends on this ai library

- Adds an external dependency to Flame
External dependencies should generally be avoided, since they increase perceived size and risk profile of the main library. Say, a user may trust the Flame team, but how sure can they be in our 3rd-party vetting process?

Add a bridge library between flame and the ai library

-- The need to support another library
Supporting a new library has substantial costs. In this scenario we'll be supporting one additional library, so that's extra costs to the maintainers.
--- Code duplication
Since main Flame has the need for some of the ai behaviors (specifically for Camera movement), we'll end up creating the same functionality twice. And because this functionality will leave in separate classes, the end user will have to pay this cost too, as the functions will end up included twice in the final executable.

Summary
In my view, the benefits of including this functionality into Flame far outweigh the alternative of releasing the package separately. Of course, many of these arguments are somewhat speculative -- but many are drawn on the existing examples of packages that we have as externals, and which present significant challenges to the development.
If anything, we should start thinking of how we can bring our many disparate packages under a single umbrella (at least into the mono-repo).

Here's how I view the breakdown of various factors:
Inside of Flame
* **`++` Trust**

The package would live under the same organization, and that would be clear on pub, so I don't think this is an issue.

* **`o` The code will need to be maintained**
  I understand how this could be perceived as a `-`, but in reality the code will need to be maintained anyway -- whether it'll be in Flame or in some other repo. And maintaining it inside Flame is easier, because there will be less temptation to "sweep it under the rug".

If the full gdx-ai library should be ported it is probably close to 10k lines of code, it feels like that deserves its own pipeline, but I agree, the code does still need to be maintained.

* **`+++` Ease of development**
  This is a huge benefit from the developer standpoint. Flame has existing system for publishing examples/documentation. The Flame engine is needed for running tests. Compared to the alternatives, it's much easier to make changes in one package that are needed in another (this is currently a major pain point with our existing packages `mock_canvas` and `ordered_set`).

The plan is to merge all examples and docs, so I don't think this deserves three +. I have not had any pain points regarding this when developing things in ordered_set, quite the opposite, since it is contained in its own repo and doesn't need Flame the pipeline it is ten times faster. Can you elaborate on why you think it is a pain point?

* **`++` Flame is perceived as a more powerful library**
  The users will appreciate that Flame can fulfill all or most of their needs for game development, without them having to "shop for extra parts". This is like a difference between renting a fully-furnished apartment, and a bare-walls one. In practice you can think of it like this: in the popularity context between different libraries, people try to use at easily available metrics: stars on github, mentions on StackOverflow, downloads on pub.dev etc -- spreading the functionality across many small packages makes each of them appear small and insignificant, whereas taken together they are much more powerful.

If we document it well I don't think that Flame will be perceived as less powerful, and I don't think we'd get less stars on github on the monorepo because we have this separation. I mean, we don't even have audio support in the core library.

Externally
* **`+` The code can be reused in other Dart projects**
  This is a weak benefit: the code is useful for games only. And it can be reused when it is inside Flame too, though there could be a perception that it is somehow "too heavy". It is not, because of the tree-shaking.

A lot of people have used Forge2D outside of Flame and I think this would fall under many of the same use cases as Forge2D.
 Even gdx-ai doesn't require libgdx to be used.

* **`-` Separate release process**
  I'm putting this as a `-` because Flame is already committed to regular releases, so compared to the first option there is little to be gained by having a separate release process. However, release process has its costs, and these costs will now have to be paid in full.

It is not hard to do a release to pub, you simply write pub publish (if you don't use melos) and then it is done. With a separate release schedule it can be released faster than we'd do flame releases, so I would definitely put this as a +. It will be much harder to cherry pick patches and do fast releases when it is within the core.

* **`--` Documentation**
  Currently we have a working system for publishing Flame documentation for each version (including examples). There is no comparable system for all other packages (even those in the mono-repo). Until such system is developed, this would be a major drawback.

See reply on "Ease of development".

* There could also be different variants for the dependence structure:

  * **Flame depends on this ai library**

This is not an option for us.

Summary
... which present significant challenges to the development.

What are these significant challenges?

If anything, we should start thinking of how we can bring our many disparate packages under a single umbrella (at least into the mono-repo).

The umbrella is blue-fire and flame-engine, packages that can be used without Flame should not live within the monorepo.
Before I knew that the gdx-ai package was so big I thought it was a pretty good plan to put it within the core, but know I'm leaning towards @erickzanardo's and @luanpotter's standpoint to have it as a separate package.

The package would live under the same organization, and that would be clear on pub, so I don't think this is an issue.

Maybe it's just me. But it took me more than 2 months to realize that ordered_set belongs to BlueFire team; and I just learned yesterday that audioplayers does too.

The plan is to merge all examples and docs,

Obviously this is a great plan, deserves a :+1: or even :+2:. But for now it is still more of an idea than an actual plan. I mean, there is no tracking issue, or a project, or an approximate estimate for how long it would take, or how much effort will be required, or commitment from specific people to do it. Surely, it can all magically materialize before the New Year, but it could also take several months or even quarters.

I have not had any pain points regarding this when developing things in ordered_set, quite the opposite, since it is contained in its own repo and doesn't need Flame the pipeline it is ten times faster. Can you elaborate on why you think it is a pain point?

Here's an actual example from canvas_test that I've encountered. Suppose I'm working on a new Flame feature, adding a test to draw something on a canvas -- and it turns out that there is no MockCanvas.drawCircle method. Ideally, if MockCanvas belonged to the flame_test repository, I would have went in and added the missing method in 5 minutes.
Instead, I'd need to (1) fork the canvas_test repository, (2) set up Android Studio for the new project, (3) implement the drawCircle functionality, including tests, (4) make a PR, (5) wait for the PR to be approved and merged, (6) make another PR for the new release of canvas_test (actually I'm not entirely sure how to do this part), (7) wait for the PR to be approved and merged (optionally: spend some time arguing whether a single function is release-worthy or maybe it should be released later), (8) make a third PR in the main flame repository bumping the version of the canvas_test dependency, (9) wait for that PR to be approved and merged (hopefully quicker than the first two), (10) pull these changes into the feature branch that you were originally working on -- only now I'm finally unblocked to work on my feature.
Note that most of these concerns wouldn't apply if the ai library was inside the mono-repo and flame depended on it via relative import.

A lot of people have used Forge2D outside of Flame and I think this would fall under many of the same use cases as Forge2D.  Even gdx-ai doesn't require libgdx to be used.

I wonder what's their use-case though? Developing game engines alternative to Flame? Do we even want to encourage that?
For gdx-ai I suspect their prime motivator is to make their engine jar files smaller, so that developers who don't need AI capabilities wouldn't have to carry it along. After all, Java doesn't have tree-shaking like Dart.

It is not hard to do a release to pub, you simply write pub publish and then it is done.

There is always some hidden cost of publishing, and in general maintaining the CI infrastructure. Creating release branches and tags, making GitHub release, resolving deprecation events, updating readme, creating changelog, re-building documentation, making public announcements, etc.

The umbrella is blue-fire and flame-engine, packages that can be used without Flame should not live within the monorepo.

We can always design the package in such a way that it cannot be used without Flame. Ultimately, this AI engine is for use in games, it has no external purpose like, say, audioplayers.

Ultimately, though, is the question of scope: is this functionality within the scope of Flame engine?
Suppose, for example, that there was no gdxAI project. I came in and say: look, we have position-components which can be placed anywhere, and we also have move effects that can move them in a predefined way, and even a "speed" parameter that can change the effect based on the initial position of the target. But wouldn't it be nice if we also added more complicated types of behavior, where targets update their trajectory continuously, where they can react to other targets or to the environment?
How do we decide what's in Flame's scope and what's outside?
If the concern is that the code originates from gdxAI -- then we can develop it independently. It would still be easier than maintaining a separate project.
If the concern is code size (and btw, Java is about twice more verbose than Dart), then we can limit the amount of things we are going to implement.
If the concern is that the code can in theory be separated, then I don't understand what's the scope of the Flame library. Because it has plenty of things that could have been in separate packages (like particles, effects, collisions, etc).

For me the reason for this being a package on its own is pretty simple, this is a port of another lib, better keep its code base apart from Flame.

For me the reason for this being a package on its own is pretty simple, this is a port of another lib, better keep its code base apart from Flame.

So, would you be ok with including this (or equivalent) functionality into Flame, if it was developed independently from gdx-ai or any other existing library?

Maybe it's just me. But it took me more than 2 months to realize that ordered_set belongs to BlueFire team; and I just learned yesterday that audioplayers does too.

They were moved over quite recently from Luan's personal account, if anyone is actually concerned about the origin of a package it is very easy to see that they come from us now though.

Obviously this is a great plan, deserves a +1 or even :+2:. But for now it is still more of an idea than an actual plan. I mean, there is no tracking issue, or a project, or an approximate estimate for how long it would take, or how much effort will be required, or commitment from specific people to do it. Surely, it can all magically materialize before the New Year, but it could also take several months or even quarters.

It can be started for new projects already, so all gdx-ai docs would be written just like if they would have been included in the core.

Instead, I'd need to (1) fork the canvas_test repository, (2) set up Android Studio for the new project, (3) implement the drawCircle functionality, including tests, (4) make a PR, (5) wait for the PR to be approved and merged, (6) make another PR for the new release of canvas_test (actually I'm not entirely sure how to do this part), (7) wait for the PR to be approved and merged (optionally: spend some time arguing whether a single function is release-worthy or maybe it should be released later), (8) make a third PR in the main flame repository bumping the version of the canvas_test dependency, (9) wait for that PR to be approved and merged (hopefully quicker than the first two), (10) pull these changes into the feature branch that you were originally working on -- only now I'm finally unblocked to work on my feature.

I can see your point, 6 and 7 doesn't work like that though, we publish a new version and then we do the PR afterwards. And 8-10 could be done in the same PR as where you need the changes and you could have your PR depend on your branch before it is merged. For these kind of libraries which can develop on their own we definitely don't want them inside of the monorepo, these can live completely without flame and if someone wants to continue work on them they can simply fork only the small repo instead of the full monorepo.

I wonder what's their use-case though? Developing game engines alternative to Flame? Do we even want to encourage that?

Of course, anything that gives our users freedom to come up with whatever crazy ideas they have. One person for example created a site with directed graphs and each entity was controlled with a Forge2D body and springs, completely outside of Flutter. We don't want to lock in people to Flame and Flutter when we don't need to, if it isn't making our lives too hard, so that is  what we are really discussing. A pure dart library with gdx-ai could be used with so much more than just Flame, compare with the a-star library for example.

There is always some hidden cost of publishing, and in general maintaining the CI infrastructure. Creating release branches and tags, making GitHub release, resolving deprecation events, updating readme, creating changelog, re-building documentation, making public announcements, etc.

Almost all of that should be automated though, and just as much work outside the monorepo as within it. We have generalized most of the pipeline actions so that they can be used in different repositories.

How do we decide what's in Flame's scope and what's outside?

This is a very good question! I'll make sure that we discuss that on our next meeting!
(Everyone has been a bit off now during the holiday, but we should be having a meeting soon)
It might sound like I'm completely against having this in the mainrepo, but I'm not, I just want to weigh all the pros and cons.

Ok, I surrender. I'll create a new package.


When ng-tags-input is disabled it still displays the message: 'Type here to add tags; end with return.'

The disabled ng-tags-input should not show a message implying that a user can enter new tags.

Made two changes: Set the default display in the home page for disabled to ' ' (if its an empty string then it ignores this value and instead shows the message in the header). I also added css to hide the disabled input box (by turning it white). Otherwise there is an empty grey space.


[Event Request] Table 37 Sales Line - OnValidate "Unit of Measure Code" - OnValidateUnitOfMeasureCodeOnAfterCalcShouldPlanPriceCalc

Please add an Event OnValidateUnitOfMeasureCodeOnAfterCalcShouldPlanPriceCalc in OnValidate "Unit of Measure Code" in Table 37 Sales Line
[Event Request] Table 37 - Sales Line - OnValidate "Unit of Measure Code"
field(5407; "Unit of Measure Code"; Code[10])
{
    trigger OnValidate()
    var
        Item: Record Item;
        UnitOfMeasureTranslation: Record "Unit of Measure Translation";
    begin
        TestJobPlanningLine();
        ...
        case Type of
            Type::Item:
                begin
                    GetItem(Item);
                    GetUnitCost();

                    ShouldPlanPriceCalc := "Unit of Measure Code" <> xRec."Unit of Measure Code"; // <-- NEW VARIABLE
                    OnValidateUnitOfMeasureCodeOnAfterCalcShouldPlanPriceCalc(Rec, ShouldPlanPriceCalc); // <-- NEW EVENT
                    if ShouldPlanPriceCalc then // <-- NEW CONDITION

                            PlanPriceCalcByField(FieldNo("Unit of Measure Code"));

                    CheckItemAvailable(FieldNo("Unit of Measure Code"));
                    "Gross Weight" := Item."Gross Weight" * "Qty. per Unit of Measure";
                    "Net Weight" := Item."Net Weight" * "Qty. per Unit of Measure";
                ...

[IntegrationEvent(false, false)]
local procedure OnValidateUnitOfMeasureCodeOnAfterCalcShouldPlanPriceCalc(SalesLine: Record "Sales Line"; var ShouldPlanPriceCalc: Boolean)
begin
end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 47021.


(WIP) allow to set detail callback (i.e. to display it in modal)

This is conceptual code, that allowed me to use Bootstrap 3 modals for table details with simple settings:
                    detail_callback: function(data, tr){
                       $('.modal-body').html(data, 'details');
                       $('.modal').modal();
                    },

I am not sure how general the implementation of this should be, so I am leaving that for further discussion.
I can implement it to be quite concrete with just modal class to be set, or even more code could be leaved for users to implement.

@PetrDlouhy thanks for contribution;
I merged your PR, but also did a little cleanup to remove some code duplication:
https://github.com/morlandi/django-ajax-datatable/commit/5d05db2e5e488d7f9c8d7585668708f5e5678b8d


feat(setColors): add setColor to override default colors

closes #17

@kentcdodds There was an issue with the snapshots, I'm not sure if I misconfigured something that caused the paths to be different.

Thanks a bunch! Not sure what's up with snapshots. I couldn't reproduce either 🙃


Add ability to ignore calculation of HIX value for certain pages

Short description
Some pages deliberately have a bad HIX value, e.g. bulleted lists or pages that only contain addresses. Expert users should have the possibility to switch off the HIX calculation for a page.
Proposed changes

Add hix_ignore attribute to the page model and "Ignore HIX value" checkbox on the page form
Calculate HIX value only for pages with hix_ignore=false
Change the grayscale for the disabled checkboxes because it was hard to recognize if the checkbox was checked or not.

Side effects
Didn't find any
Resolved issues
Fixes: #2075 (partially)
Will do next:
Pages with hix_ignore=true should not be translatable via DeepL.

Pull Request Review Guidelines

Thank you for the PR 💪
I have two question/suggestion (open for all members).

What about hiding the checkbox and show whether the Hix is activated for the page instead of diactivating and graying out the check box, when the user is not allowed to change it?

Schall we check whether the user is an expert user when any change on hix_ignore is included in a request, just like publishing permission check in draft/public change requests? Though this may be an over kill 😅

@MizukiTemma thanks for the feedback :)
I will comment to the first point, because at first I implemented it that way, and then changed it.
Argument 1:
We already disable other checkboxes when the user does not have edit rights. Such as "Minor edit", for example.
Argument 2:
When the user is not an expert and hix_ignore= true, we could additionally display some text like "HIX calculation is disabled for this page", but then the whole block seems idle to me.
I thought the disabled checkbox looks nicer and clearer.
But I am open to opinions anyway.

@seluianova @JoeyStk
Thank you for input and comments 😃
hmm, to be consistent with the principle "users see only what they can do", should we hide both the ignore_hix check box and the minor edit check box (and others too which are similar to them, if there is any)?

UPD: don't show the checkbox to non-expert users.


Javacript conversion mandatory for checkboxgroups

The getValue of a checkboxgroup returns an array of strings
{"enableBackground":1,"background":65280,"font_size":"2","test":["sushi","burgers"]}

If we let Clay handle 'showConfiguration' and 'webviewclosed' events, an array of bytes is sent to the watchapp for the test key containing :
['s','u','s','h','i','b','u','r','g','e','r','s']
So without javascript convertion, it is really not easy to use this in the C code.
Clay should also return \0 character like that :
{"enableBackground":1,"background":65280,"font_size":"2","test":["sushi",0,"burgers",0]}

so the string delimiter will permit to split the result in C.

For the context, I wrote a simple tool to generate the C getters for the Clay settings (from the config.json).
checkboxgroup is the only type not yet supported
If you want to look at the tool : https://github.com/gregoiresage/enamel


add some documentation on module design

hope nothing is too far off -- referenced a lot of the issues we've been talking in for the past few months
hopefully nothing broken on the org mode side -- I can now edit org mode as fast as markdown, did take me a while to figure out how links worked though...
now I just need to learn all the keybindings so I'm actually getting benefit out of org

Hmm
Seems some of my links dont work, not sure how github renders these...
https://github.com/seanbreckenridge/HPI-fork/blob/doc-updates/doc/SETUP.org#L467
See [[file:MODULE_DESIGN.org::#addingmodules][MODULE_DESIGN/adding modules]] for more information
Thought this was how you did it... perhaps I have to follow the markdown id-like structure and link to a slugified version like #adding-new-modules?
* Adding new modules
:PROPERTIES:
:CUSTOM_ID: addingmodules
:END:

Ah - well. the latest commit just removed the link altogether... o_o

I think the ::* links definitely won't work properly on Github because they are using header search -- so they are inherently dynamic.
So the ::# syntax is the right way in org-mode, and used to work on Github, but got broken at some point :( https://github.com/novoid/github-orgmode-tests/commit/952a8cb973084d19887e90f02bc2827ebdc928d8
Also did another check now and it seems that [[file:MODULE_DESIGN.org#addingmodules][MODULE_DESIGN/adding modules]]  works on github! But org-mode doesn't understand this and assumes # is just a part of a filename. Ugh. But maybe it's a fair compromise in the meantime considering people would likely be reading github docs (rather than browsing them in emacs)?
Also CUSTOM_ID / ID properties don't seem to work either -- it seems that haven't for a while considering I have this hack in readme https://github.com/karlicoss/HPI/blame/master/README.org#L279
Opened PR with these findings so at least I remember it next time: https://github.com/novoid/github-orgmode-tests/pull/4/files
Also seems related to https://github.com/alphapapa/org-make-toc#known-issues

Ok, that seems to work, at least in githubs rendering. left a comment to this PR there
Link at the bottom of
https://github.com/seanbreckenridge/HPI-fork/blob/doc-updates/doc/SETUP.org#addingmodifying-modules
correctly links

lots of small changes T__T
hard to know whats going to work -- is almost easier just editing in in the browser so I get the live preview

hard to know whats going to work -- is almost easier just editing in in the browser so I get the live preview

yep, it's definitely easier, I do that as well

The doc looks great, thanks for assembling!

Alright, finished going over everything again just to make sure there were no broken links/indentation
Probably missed something, but this is probably good enough to merge


K8s objects not included in the resources above

When using Tilt instead of the vanilla way to apply/create your kubernetes files I get errors of K8s objects not being included.
For example ./frontend/configmap.yml:
apiVersion: v1
kind: ConfigMap
metadata:
  name: frontend-configmap

./frontend/deployment.yml:
...
      env:
        - name: FRONTEND_CONFIG
          valueFrom:
            configMapKeyRef:
              name: frontend-configmap

Above example will throw out the following error:
     K8s objects not included in the resources above:
      k8sConfigMap-frontend-configmap

Is this a bug or can I resolve this by configuration?

Oh, I think this is fine? I assume you're seeing something like this:

It's not an error message. It's just trying to inform you that k8s_yaml includes something that it couldn't figure out how to group on the other lines. I agree it's kind of cryptic looking
@yuindustries what do you think?

@nicks Already had the feeling this was a feature and not a bug. So it just means it won't display as the  tilt-frontend-demo ------ Running... line in your screenshot.
My English isn't all that great but maybe it's an idea to change the line to something like:
K8s objects not shown in the resource list above.

Some copy ideas:

"All other k8s objects"
"Other k8s objects (those not included in resources above)"


one line run FEDOT.web implemention

I want to make a implementation to one line run for this repo in local environment. If anyone interested in this direction please let me know. It is very good for user onboarding.
this can be done by combinign all the commands in the documentaion of advanced use in the FEDOT.web

I think it is good idea to implement such a script.


Configure MultiProject Dependencies

Find out how to have a sub project depend on another sub project with gradle.
ie: CarTracker.Web needs CarTracker.Data as a dependency

Done.
Referenced:
https://docs.gradle.org/current/userguide/multi_project_builds.html
https://docs.gradle.org/current/userguide/intro_multi_project_builds.html


Wifi sometimes stop working - not hardware installed

Hello all! I'm working with internal dw1560 in my notebook pro and everything is OK, I'm using original antennas and speed is great. But sometimes, after sleep, the laptop says that there is not hardware installed, and I have to reboot to fix it.
Sometimes (less times), when I reboot, after boot, the systems says too there is not wifi hardware installed, and I have to reboot again. Any clue?

@alexmenn you have this issue since you updated your EFI recently?
Anyone with internal BMC having this same issue?

No, I have had this problem since HS :)

@alexmenn Hi, since it’s a problem related to third party hardware, you can send trouble shooting to tonymacx86.com to get professional help.

@stevezhengshiqi Ok, I will ask. Can you give me link to buy your BCM943602CS to check it?

@alexmenn I think that is wrong adaptor,... you need key m or b, the link you provided is key a/e so it won't fit, also about the antenna I'm sure you can connect wifi one to original port and Bluetooth one under trackpad, but, you may want keep original intel wifi card as the apple one don't work well on linux and windows(need driver), as discussed on steve repo, go check them.

You're right. Key m or b, ok, but what kind of connection uses the chip BCM943602CS? I cant find any on ebay.

@alexmenn I think it's apple own one connection,12+6 pin, and that port to key m is pretty rare... But I found one on aliexpress for you.
Only adaptor .Bluetooth should work if you solder usb bus.
https://m.aliexpress.com/item/32949190082.html?pid=808_0000_0101&spm=a2g0n.search-amp.list.32949190082&aff_trace_key=&aff_platform=msite&m_page_id=1488amp-N9L0BcBVwnB6p_6y_KarrQ1541246198851

Hmm seems to be perfect. When I cut it, will it fit in the m2 slot?

@alexmenn I don't own that adaptor, but it should fit without problem, as the m.2 size that we have is pretty standard.(designed to fit a ssd, with is longer than wifi card.)

@alexmenn you also need antenna.... 3 antenna or two wire to connect to original one (I think you already have it.)plus a antenna for Bluetooth. Also usb wire,normal wire that you can find on local shop? Not sure about USB wire is equal than a normal wire....  and it's seem that adaptor have a usb socket maybe you should search more about it..

I have few wires to connect original antenna to chip right now. I just need one more antenna for BT, but I think I wont use BT with this chip. I just need a stable wifi which works after sleep :)

@alexmenn well it's up to you, but Bluetooth is powered.. so wasted power. (You also have paid for a card that have native Bluetooth,  so no more harassment kext)

Hmm ok, bluetooth will be nice, but how can I "connect it"? Im sure I will have to solder some wires...


Remove IDs

There's no need for IDs anymore. All of our data sets have their own identifiers (like deployments have a URL or a domain and the same for aliases).
This was suggested by @nkzawa.

Not all of them – credit cards for example 👌

I think @jamo suggested another data set that need IDs 🤔 Can't recall

Nah, completely... 😊

E.g removing DNS records will become pita.
now dns rm zeit.ninja @ A <IP_ADDRESS> would be the minimal syntax to remove a single DNS record...

For domains (not DNS), aliases, and deploymets this would be ok. For the rest, well, not so much

We could introduce something like:
now dns rm zeit.ninja

Which DNS record for zeit.ninja would you like to remove?

A (<IP_ADDRESS>)
CNAME (test.tld)

The user could cycle through these with the up and down arrows.

How would one possibly automate this?
IMO That could be ok for web but not for a cli
cc @rauchg

Does "automate" mean running now inside a CI env? In this case, the program could still specify the whole value list like you stated it here.

It seems we fixed all sub-commands with https://github.com/zeit/now-cli/pull/665, except ones which has no identifiable values .

I disagree with removing the IDs from the DNS. If the point is to make it easier it doesn't, instead it makes it harder to use. The only viable option to remove a record is to type the whole record which isn't nice. The reason: It's rather complicated which parts of the record are unique and I'd hate to see an interactive list. If you really want to make it better, I'd suggest a dns.json interface but IMO that can't be the only interface.
Then again it's absolutely necessary to have IDs for certificates because a single certificate can contain multiple common names and in theory there could be multiple certs for the same domain.

Completely agreed, @OlliV! We just removed them from now secrets, which is fine. Are there any other commands left now where we should remove them (now dns and now certs definitely not)?


Update http4s-client, http4s-dsl to 0.23.21

About this PR
📦 Updates

org.http4s:http4s-client
org.http4s:http4s-dsl

from 0.23.16 to 0.23.21
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.http4s" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.http4s" }
}]

labels: library-update, early-semver-minor, semver-spec-patch, version-scheme:early-semver, commit-count:1

Superseded by #496.


wr.s3.list_objects not able to limit results by setting s3_additional_kwargs={"MaxKeys": num}

Describe the bug
It's not possible to limit the number of keys returned by wr.s3.list_objects using the MaxKeys keyword from list_objects_v2 or the MaxItems keyword from the ListObjectsV2 paginator. It's getting passed through but I think isn't compatible with the paginator implementation:
https://github.com/awslabs/aws-data-wrangler/blob/066b81a5778cca7ce5ea8d889a2fec9824d8996a/awswrangler/s3/_list.py#L97
You might consider making "PaginationConfig" configurable to the caller so that MaxItems can be set there, and/or maybe adding a flag to skip the paginator entirely if s3_additional_kwargs["MaxKeys"] < args["PaginationConfig"]["PageSize"].
P.S. Thanks for this great resource :)
Environment
Using wrangler version 2.11.0 in a Python 3.8 Lambda.
To Reproduce
This returns more than MaxKeys results:
wr.s3.list_objects(data_prefix, s3_additional_kwargs={"MaxKeys": 1})

This returns MaxKeys results:
client = boto3.client('s3')
client.list_objects_v2(Bucket=bucket, Prefix=prefix, MaxKeys=1)

Steps to reproduce the behavior.
P.S. Please do not attach files as it's considered a security risk. Add code snippets directly in the message body as much as possible.

Awesome, thanks!


ML-training-cost-calculator/docs/comms-guidelines.md fix

https://github.com/aipaca-mlops/ML-training-cost-calculator/blob/d3a51ba4543dbcecfa27bfc8f67b5801199393e7/docs/comms-guidelines.md?plain=1#L15
<INTERNAL TOOL> does not show up

This was a redundant item. I just deleted it. We don't have such a tool


Use env to wait for lame duck to complete after signal

Enables the /gnatsd -signal feature to use a LAME_DUCK_DURATION environment variable to optionally wait for some time after sending USR2 to the server.
Signed-off-by: Waldemar Quevedo<EMAIL_ADDRESS>
[ ] Documentation added (if applicable)
[X] Tests added
[X] Branch rebased on top of current master (git pull --rebase origin master)
[X] Changes squashed to a single commit (described here)
[X] Build is green in Travis CI
[X] You have certified that the contribution is your original work and that you license the work to the project under the Apache 2 license

Changes proposed in this pull request:

Add LAME_DUCK_DURATION environment variable to make /gnatsd -signal=ldm=<pid> wait before exiting after signaling

/cc @nats-io/core

Coverage decreased (-0.1%) to 90.846% when pulling 5bdcb5b6896ac87f6f842e4b35288561a8b80695 on ldm-wait-signal into 8fe0fa7057dcfc2faef0077dee968f071d7463da on master.

This does not feel like the right approach to me. The process has a specific role, to send the signal to the running server. We may add in checks for config etc, but waiting just feels incorrect here. If we feel strongly, I would suggest have it wait for the process it signaled to exit instead of loosely tying it to an environment variable that may have no bearing on reality.

Agreed that this does not feel right. I understand now that what you need to block is the process sending the signal, not the one actually processing it. Would it make sense then to have a script that invoke gnatsd -sl and sleep and have exec invoke that script instead?

Thanks for the review, agree as well would be better to wait for target process to exit to block, but instead will close this one and look into making it possible to hook into a sleep command detached from the gnatsd process.


Import if not in database

//Not an issue but rather a help request//
Hello.
I was wondering if your package allows for importing the user, if he tries to sign in but the record is not synced into the database yet. Sort of "autoimporting".
The situation is the following: I have a set of about 800 users from our school. Of course it is possible that the school gets a new student, who should be able to use the website as soon as the recives a windows account, whithout the need for the admin to sync the database first.
Is this possible?
Thx in advance for helping me out and a super big thank you for creating and maintaining the package! It's super great!

Hi @3Descape, this is actually one of the main features of Adldap2-Laravel.
With the default configuration, a user record will be automatically created upon sign in.
You can prevent this from un-commenting the OnlyImported rule inside the stock configuration:
https://github.com/Adldap2/Adldap2-Laravel/blob/65f55f426d9407c794fe7b107ba902e586b00fd2/src/Config/auth.php#L55-L63

Also thanks for your kind words! :smile:
If you encounter issues just give me a shout and I'll help you out.

Thank you very much for the quick anwer!
While I was explaining how I tested it, because it didn't work, I found the solution: I implemented a custom login method in the LoginController, because I need to do some other checks for user permissions ans such, and there I validate whether or not the user exists. So it was my fault ;D
Thank you very much again and keep up the great work! I really appreciate it!


Signed Cicero Template Archives

Add support for signed template archives.
References:
https://docs.oracle.com/javase/tutorial/deployment/jar/signindex.html
https://medium.com/ios-os-x-development/ios-code-signing-provisioning-in-a-nutshell-d5b247760bef

Hello,
I have started to investigate this issue and I would like your feedback before I go too far in one direction or another.
Given the current archive format being zip and to avoid a separate signature file I think a solution similar to JAR signing makes sense.

create a simple manifest containing a collection of file paths and hashes in the archive
digitally sign that manifest and place the signature in a separate file
place both manifest and signature in the zip in special locations

I am planning to use PKCS#7 digital signatures.  This gives signers the option of using the global PKI allowing for easy verification of signatures while not precluding the use of self-signed certificates if a firm is unable or unwilling to purchase a code signing certificate.
Your thoughts?

That sounds great. FYI we already have a method in the template that computes a content-based hash which might be useful:
https://github.com/accordproject/cicero/blob/master/packages/cicero-core/src/template.js#L143

I ended up creating a manifest with individual file hashes to more easily detect what file changed, if any.  I'm finishing up the verification bits now; although I've used node-forge in the past, I didn't notice PKCS#7 verification was missing so I had to add it.

I reviewed the code in the fork - it looks great. Looking forward to the pull request!

Thanks @roysjosh, great work! Some thoughts on your comments above...

Linux platforms are assumed with the CA list I grabbed from Go

Can you explain the platform limitation a little more, please? What does this mean in practice?

an invalid signature aborts processing; is this acceptable?

Yes, IMO. We can handle this gracefully higher up the stack

as signing is optional there is no way to prevent a malicious MitM from removing the signature and manifest

So, we rely upon tools to alert users to the use of unsigned templates/templates that were previously signed? Analogous to TLS and HSTS in browsers?

it isn't possible to use the signing half of this PR with an EV code-signing certificate as those are required to be stored in hardware

If I understand this correctly, the use of EV certificates in browsers has lost traction recently. I assume that the same criticisms of EV certificates for domains are also relevant to us. In this case, I'm comfortable with this limitation.

the subject of the signer certificate is displayed during verification but users could be tricked by a malicious actor incorporating an identically named entity in a different legal jurisdiction

Analogous to a malicious website choosing a similar domain name , i.e. accordproject.us rather than accordproject.org? I wonder what lessons we can learn from other domains to reduce the risk of this. Regardless, this sounds like a reasonable limitation to begin with.

@roysjosh Any update on this? Last time I had seen an update it looked almost completed?

I'll go ahead and open a PR here so it can be reviewed.  I'm waiting to hear back on my latest changes for digitalbazaar/forge#706.

I'll go ahead and open a PR here so it can be reviewed. I'm waiting to hear back on my latest changes for digitalbazaar/forge#706.

Sounds great!

It looks like forge has now implemented PKCS#7 - but not merged your PR @roysjosh. Can you re-implement the PR on top of their implementation?
https://github.com/digitalbazaar/forge#pkcs7


Merged ONNX decoder next steps

Feature request
The PR https://github.com/huggingface/optimum/pull/647 was merged that adds support for merged without/with past decoder as a single ONNX file, along with inference in ORTModelForCausalLM.
Some key steps are still remaining:

[ ] Support IO Binding
[ ] Find a way to hide the prints 2023-02-10 16:29:24.868007832 [W:onnxruntime:, graph.cc:3487 CleanUnusedInitializersAndNodeArgs] Removing initializer '/transformer/h.4/attn/Constant_18_output_0'. It is not used by any node and should be removed from the model., tracked in https://github.com/microsoft/onnxruntime/issues/14694
[ ] Fix the generation of dummy past key values for bloom that is currently ugly
[ ] Investigate why codegen does not support -with-past in tasks.py
[ ] Support the merge for Seq2Seq model

Motivation
Reduce memory usage
Your contribution
/

Hi @fxmarty
I am looking for a solution to reduce GPU-CPU communication when running text generation with past_key_values. Is IO Binding here targeted for the problem?
Also I wonder if the caches are perserved on GPU, will it potentially cause a memory explosion? When the QPS is high and sequences are long, there will be a lot of intermediate tensors. I'm not sure if this could lead to OOM.

Hi @un-certainty , yes if you are using CUDAExecutionProvider, using IO Binding is probably helpful. I don't have a proper benchmark at hand though.

Also I wonder if the caches are perserved on GPU, will it potentially cause a memory explosion? When the QPS is high and sequences are long, there will be a lot of intermediate tensors. I'm not sure if this could lead to OOM.

I would say it could, yes.


[Story] Explore how to scrap challenge website with Python

What product(s) is this story for?
OpenChallenges
As a user, I want
NA
Description
The goal of this ticket is to explore how to scrap the page targeted by challenge.websiteUrl. The text collected could be used for the challenge description or generating headlines (currently explored in #2280).
Acceptance criteria
No response
Tasks
No response
Anything else?
No response
Have you linked this story to a GitHub Project?

[X] I have linked this story to a GitHub Project and set its metadata.

I tried to scrap in a naive way a pFDA challenge for the sake of generating challenge headlines. The website does not use SSR so we can't get the entire page with the following code:
import requests
from bs4 import BeautifulSoup as bs

challenge = challenges[0]
website_url = challenge.website_url

print(f"Get challenge page {website_url}")
response = requests.get(website_url)
soup = bs(response.content, features="html.parser")
# retriving all h1 and h2 tags and extracting text from each of them
first_headers = [html.text for html in soup.find_all(["h1", "h2", "p", "span"])]

pprint(first_headers)

For CSR websites
See Scrapy - Pre-rendering JavaScript

Added to Backlog


feat: add event loop lag to metrics middleware

Add the event loop delay at the start of a Momento call to the metrics middleware. It measures this by calling setTimeout with no delay that executes a function that subtracts the start time of the call from the current time. If there is no lag, it executes immediately and there is no difference. I didn't use the node performance measurement APIs because its event loop delay is a histogram that measures on a regular interval, and that doesn't fit well with per-request metrics.

I spent way too long thinking about how to make the histogram work before switching to the current strategy. It may still be useful to add mean or p99 event loop lag as measured by the histogram since the start of the program, or event loop utilization since the start. I can add those in if desired.

@nand4011 This is an interesting idea!
My first thought when seeing it though is: I'm not sure we want to add another event to the event loop by calling the setTimeout, it might compound the problem? Were you able to use this in a program and have it show you interesting results?
I was thinking that with the performance measurement API, we wouldn't necessarily have to emit metrics that were per-request. We could either:
(a) emit a separate set of metrics on a different cadence, that just told us things about the event loop. As long as there are timestamps we can correlate with the per-request metrics then it still serves our purpose. or
(b) we could include a few fields with the latest percentile metrics from the histogram in each request metrics log. those metrics wouldn't correlate with that specific request, and there'd be a bunch of requests that had the same values until the next time the histogram was updated, but it'd still at least give us a correlation with the load of the system.
I'd be curious to hear your thoughts on tradeoffs between these approaches vs what you have in this PR. We can discuss it on a call Monday if that's easier though!

I think that using a timer to determine lag is the way it is done internally in the performance observer: https://nodejs.org/api/perf_hooks.html#perf_hooksmonitoreventloopdelayoptions "Using a timer to detect approximate event loop delay works because the execution of timers is tied specifically to the lifecycle of the libuv event loop. That is, a delay in the loop will cause a delay in the execution of the timer, and those delays are specifically what this API is intended to detect."
The difference is that the performance observer will make a new timer every 20 ms or whatever interval we choose instead of at the start of each call.
I did see ~120ms of lag in the first call on a new lambda, so it does show something. The intermittent higher latency calls aren't always associated with a noticeable lag, however.
I have no problem with introducing outputting metrics on an interval. I avoided it because the middleware is specific to per-call metrics at the moment.

We're going to switch to logging event loop lag on a regular cadence instead of per request.


Configure non-nullable types as required

Closes #2036

Seems like the build pipeline is broken but this should have nothing to do with my changes.

@blouflashdb there’s one more thing to consider: default values
public string Prop { get; init; } = "default value";

It’s non-nullable, yet it shoudn’t be required as it has a default value.
See how ASP validation is working as a result of this issue

You are right, I should take a look at the implementation in AspNetCore to match the behavior in Swashbuckle.

Hi, this feature would help a lot, especially with generating APIs from swagger documents :) Is there a way to help this move forward?

Thanks for contributing - if you'd like to continue with this pull request, please rebase against the default branch to pick up our new CI.

Contributes to #2793.

https://github.com/domaindrivendev/Swashbuckle.AspNetCore/issues/2036#issuecomment-2054039124


[cxx-interop] Add snake_case to CXXMethodBridging

Update CxxMethodBridging to transform snake_case names.
Also fixed some typos unkown -> unknown
related: #40842
@bro4all

@zoecarver @hyp Everything is working correctly on my local machine 🙌

@swift-ci please test.

@zoecarver is this good to merge?

Sorry a few more comments.

@zoecarver made the suggested changes discussed today

@bro4all could you review this when you get a chance?

@swift-ci please test.

@swift-ci please test windows.

This looks good to me. Thanks for your patience.

No worries! Thanks for checking everything, I think everything should pass now

@zoecarver could you run CI for me when you get a chance?

@swift-ci please test.

Since this failed, do i need to rebase with main?

@swift-ci please test.

@swift-ci please test.

@zoecarver any ideas on why this would only fail on linux? Locally everything is working correctly with utils/build-script --test and utils/build-script --validation-test

@swift-ci please test.

@zoecarver should hopefully pass linux now, imported llvm/ADT/STLExtras.h to expose llvm::any_of

@swift-ci please test

@swift-ci please test Linux

@swift-ci please test macOS

Could you add a few more test cases where the symbols aren't all ASCII? Some of the cases I think worth including are:

Grapheme clusters that contain combining characters
CJK characters
Turkic mapping (I guess just "ı" → "I" for snake_case-to-CamelCase transformation)

If the existing logic doesn't handle some of the cases, then they probably can be a future PR instead.

Could you add a few more test cases where the symbols aren't all ASCII? Some of the cases I think worth including are:

Grapheme clusters that contain combining characters
Characters that don't have uppercase or lowercase forms (such as CJK characters)
Turkic mapping (I guess just "ı" → "I" for snake_case-to-CamelCase transformation)

If the existing logic doesn't handle some of the cases, then they probably can be a future PR instead.

For sure! Im planning on expanding this more to be like how we transform C and Objc, which should cover the case you've described

@zoecarver

@xwu could you run CI for me when you get a chance?

@swift-ci please test

@xwu okay, i think this should work now

@swift-ci please test Linux

@xwu i added the check for os now

@cabmeurer Are you testing these changes locally?

@xwu could you do CI ?

If all tests pass when you run the build script on Linux, then that should be fine...

@swift-ci test

@zoecarver is this good to merge?

@zoecarver i think this should work now

@swift-ci please test Linux

@zoecarver could you look this over and run CI when you get a chance?

@xwu could you run CI for me when you get a chance? Thank you!

@swift-ci test

@swift-ci please test

@xwu could you run CI for me when you get a chance?

@swift-ci test

@swift-ci please test

@swift-ci please test.

@zoecarver I think this should be good to go!

@zoecarver fixed!

@swift-ci please test and merge.

@swift-ci please test Windows

Thank you!


When students post that they've finished step, how do teachers review?

I think we need students to add the url to their project before they say they're done a step, otherwise teachers won't have anything to review.

I added a project URL field to the untutorial page after checkout.... but beginners can't really be expected to know how to use this.


[Feature][docker] Push docker image to docker hub

Search before asking

[X] I had searched in the feature and found no similar feature requirement.

Description
The docker command use https://registry.hub.docker.com/ by default, we can add github action which can push docker image to docker hub.
Refer to:
https://registry.hub.docker.com/r/apache/kyuubi
https://github.com/apache/incubator-kyuubi/blob/master/.github/workflows/docker-image.yml
Other
We can also push docker image to private repository like apache flink project.

Are you willing to submit a PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

cc @garyelephant @CalvinKirs this requires the permission of the maintainer, may ppmc or committers can help to continue to finish this work.

cc @garyelephant @CalvinKirs this requires the permission of the maintainer, may ppmc or committers can help to continue to finish this work.

SGTM, here are some reference articles that might be helpful.
https://cwiki.apache.org/confluence/display/INFRA/Github+Actions+to+DockerHub


Expanded Elements feat breaks apart Expanded Elements kineticist feature

Disclaimer: I'm using Kinecisit Elements Expanded mod, but I saw you posting on mod's github page, so I decided to post about this here.
That's how it looks without patch enabled:

That's how it looks with the patch enabled:

It's like on the first screenshot when you pick your first element, but every other is like the second screenshot and I'm not talking about the extra feat that your patch adds, just the feature that is already implemented in kinecisist.

This patch removes unnecessary complexity from the base implementation. So instead of picking "elemental focus", you just pick what blast you want. This doesn't go well, when another mod injects new foci again. I need to see what I can do.

Well I don't think it's unnecessary complexity, it's just implementing it so it's like tabletop in how it works, since you first choose the element and then you choose blast associated with the element

And then the wild talents check if you have the first earth focus, the second earth focus, the third earth focus, the first air focus, the second air focus, or the third air focus.
Checking for metal alone becomes "first earth focus && second earth focus || first earth focus && third earth focus".
It's also just one example. Every blast has it's own progression line granting that element's specific element feature every other level. Even tho that feature rank level is never used.

fixed


Adding Clojure executable options

What does this implement/fix? Explain your changes.
Per #1488, #1544 and #2329, there is a bug where windows can't fin the cljfmt executable.  This update doesn't fix any of the errors there, but does allow the user to either use a globally installed cljfmt or to fix the path name manually in the settings.
Does this close any currently open issues?
Yes, it should close #1488 and #2329 as well as finish the closed and abandoned PR #1544.
Any other comments?
Checklist
Check all those that are applicable and complete.

[x] Merged with latest master branch
[x] Regenerate documentation with npm run docs
[x] Add change details to CHANGELOG.md under "Next" section - There was no next section
[x] Added examples for testing to examples/ directory - N/A as I didn't change any beautifying, just options.
[x] Travis CI passes (Mac support)
[x] AppVeyor passes (Windows support)

More than willing to make other changes as directed, so just let me know if anything isn't quite right.  It's working on my system :)

Note that failure notes seem to be from other parsers, which is outside the scope of this PR.

I know you are all busy, but any chance we can take a look to get this merged in?

This fixed the problem when I applied it manually, though the default path setting could probably be better. Really hope this change doesn't get killed for a third time.

Yeah...I'm really hoping somebody merges it.  It works great for me.

The AppVeyor failure looks to be unrelated to the Clojure side, it's complaining about Javascript (looks like a React/JSX formatter bug) and SQL, not Clojure/CLJS. Really hope they aren't ignoring because of that, because your patch doesn't touch those things.

Thank you for contributing! 🎉 Please let me know if you have any questions or need assistance with this Pull Request. 😃


Can use log_stream when default-features is disabled

Current and expected behavior
I expect the following code to compile:
use k8s_openapi::{api::batch::v1::Job};
use kube::{Api, api::LogParams};
use futures::{StreamExt, TryStreamExt};

use super::K8sClient;

impl K8sClient {
    pub async fn watch_logs(&self, job_name: &str, namespace: &str, follow: bool, tail_lines: Option<u32>) -> anyhow::Result<()>
    {
        let api = Api::<Job>::namespaced(self.client.clone(), namespace);
        let log_params = LogParams { follow, tail_lines, ..LogParams::default() };
        let log_stream = api.log_stream(job_name, &log_params).await?.boxed();

        while let Some(line) = log_stream.try_next().await? {
            let parsed_line = String::from_utf8_lossy(&line);
            log::info!("{parsed_line}");
        }

        Ok(())
    }
}

But I am receiving the following error message:
error[E0599]: the method `log_stream` exists for struct `kube::Api<Job>`, but its trait bounds were not satisfied
  --> server/src/kuberentes_client/watch.rs:13:30
   |
13 |         let log_stream = api.log_stream(job_name, &log_params).await?.boxed();
   |                              ^^^^^^^^^^ method cannot be called on `kube::Api<Job>` due to unsatisfied trait bounds
   |
  ::: /home/claudino/.cargo/registry/src/github.com-1ecc6299db9ec823/k8s-openapi-0.17.0/src/v1_24/api/batch/v1/job.rs:5:1
   |
5  | pub struct Job {
   | -------------- doesn't satisfy `Job: kube::api::Log`
   |
   = note: the following trait bounds were not satisfied:
           `Job: kube::api::Log`

It is copied from the an example in github repository, but api.log_stream is not found.
The function become available if I remove default-features=false from Cargo.toml, but I want to use rustls-tls instead of openssl. The current entry in Cargo,toml is the following:
k8s-openapi = { version = "0.17.0", features = ["v1_24"] }
kube = { version = "0.79.0", default-features = false, features = ["client", "runtime", "rustls-tls"] }

Possible solution
The availability of this function should be independent of the default features, or the correct feature to enable should be correct documented.
Additional context
No response
Environment
I am running a microk8s cluster, but the problem happens at compile time.
Configuration and features
[package]
name = "server"
version = "0.1.0"
edition = "2021"
See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
shared = { path = "../shared" }
log = "0.4.17"
env_logger = "0.10.0"
anyhow = "1.0.58"
clap = { version = "4.1.7", features = ["derive", "color", "suggestions", "env", "unicode"] }
k8s-openapi = { version = "0.17.0", features = ["v1_24"] }
kube = { version = "0.79.0", default-features = false, features = ["client", "runtime", "rustls-tls"] }
tokio = { version = "1", defaulr-features=false, features = ["macros"] }
actix-web = { version = "4", features = ["rustls"] }
tera = { version = "1", default-features = false }
serde_yaml = "0.9.1"
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0.93"
futures = "0.3.26"
Affected crates
No response
Would you like to work on fixing this bug?
None

I just discovered that kube-rs cant show logs for Jobs. I will open a feature request for that.


Ambiguous Error Message for TDVT Failures

About You:
Name: Ravjot Brar
Company: Dremio
I have two tests failing (lod.10_As in-out Set  and BUGS.B14080 ) that have the following error message:
Attempting to run query...
TableauException: Tableau cannot evaluate the query that results from this calculation.

Error running query

There's no SQL generated and I couldn't find anything useful in the logs. Based on my research I'm assuming this query tries to use a function that isn't defined in the dialect file. How do I find out which function exactly?
The rest of the ~60 failures have the following error message, which tells me they're a consequence of the two test failures above:
Error. Previous error message is: Attempting to run query...
TableauException: Tableau cannot evaluate the query that results from this calculation.

Error running query

Happy to provide any other info if needed.

Can you attach your test_results_combined.csv file to start.

test_results_combined.csv

I'd recommend looking at the datetime functions generally. For example from looking at the definition of BUGS.B14080, the function below is used here:
    <function group='operator' name='-' return-type='real'>
      <formula>...</formula>
      <argument type='datetime' />
      <argument type='datetime' />
    </function>

You can also attach your full artifacts here, or link to your repo. Please also include the version of TDVT you are running to see if the repeated error message is a known issue or not.

TDVT Version:  2.7.5
tableau-sdk-connector.zip
TDVT Logs.zip

TDVT Version: 2.7.5
tableau-sdk-connector.zip
TDVTLogs.zip

Works for me after modifying the class tag and renaming the dialect file (to the dialect.tdd).
dremio_jdbc.zip

@yurifal Were you able to repro before the file name changes? I'm still getting an error in the tests.

@rosswbrown We did find the following in the tab_query logs for the two tests:
"FederatedQueryOptimizerImpl::DetermineConnForExecution: Could not find connection for evaluating all LogicalExps"
Not sure if this helps.

@yurifal Were you able to repro before the file name changes? I'm still getting an error in the tests.

My bad, I've replied with the total nonsense.
Please ignore my reply and move on.
Best of luck!

Just to follow up on the other comment, based on the logs you've provided I don't believe there is any need to rename the connector. My guess is this is your in development connector loading as expected:
{...k":"connector-plugin","v":"Successfully loaded connector for class dremio, plugin-version:4.0.0 from connector plugin C:\\Program Files\\Tableau\\Connectors\\dremio.taco"}

Looking at your test_results_combined.csv file I believe there is an issue in the results file after BUGS.B641638 test fails. Viewing the file manually you can see this query:
SELECT DATE_TRUNC('DAY', CAST(""Calcs"".""date0"" AS DATE)) AS ""tdy:Calculation_2683863928708153344:ok""
FROM<EMAIL_ADDRESS>""Calcs""
WHERE (DATE_TRUNC('DAY', CAST(""Calcs"".""date0"" AS DATE)) IN ((TIMESTAMP '1972-07-04 00:00:00.000'), (TIMESTAMP '1975-11-12 00:00:00.000')))
GROUP BY DATE_TRUNC('DAY', CAST(""Calcs"".""date0"" AS DATE))

There are additional logs in the tabquery_logs.zip\logical_calcs_dremio\ folder.

It is possible the lack of time field handling into a DateTime type might be impacting the ability to run some tests like BUGS.B641638. Consider skipping with this and see if that unblocks better error messages in the subsequent tests:
[StandardTests]
LogicalExclusions_Calcs = BUGS.B641638

The No such function $IN_SET$ that takes arguments of type (str, datetime, datetime, datetime, datetime) failure is trying to test these are in the [time0] field:
21:07:32
22:42:43
1900-01-01 04:57:51
1900-01-01 18:51:48

Tried excluding that test and got the same ambiguous error messages unfortunately.

I think the best starting point may be to get the calcs_data.time to pass and match the expected file. This column is the basis for at least a few of the failing tests.
A connector's Date Literal Support is described in that link and some additional details within this previous answer. Since the connector attached above is using PostgreSQL90Dialect as a base it is likely this is the current implementation:
  <function-map>
    <function group='system' name='TIME1899' return-type='datetime'>
      <formula>(CAST('1899-12-30' AS DATE) + %1)</formula>
      <argument type='datetime' />
    </function>
...
  <sql-format>
    <format-date-literal formula="(DATE '%1')"  format='yyyy-MM-dd' />
    <format-datetime-literal formula="(TIMESTAMP '%1')" format='yyyy-MM-dd HH:mm:ss.SSS' />

If you're still seeing a large number of failures try using more general skips and reducing the number of test suites used as a starting point. For example:
[StandardTests]
LogicalExclusions_Staples = BUGS.*,Filter.*
LogicalExclusions_Calcs = BUGS.*,Filter.*

You can also remove suites entirely like [LODTests] and [UnionTest] from the ini file to help narrow the issue.

As you identified originally I think this a situation where one of the logical Staples tests is causing a cascading failure, similar to what is reported in #1123. My best guess is still to start with the suggestions above.
Previously we'd established if you can skip the failing test then the others will succeed. You are also able to run tests individually in this style, which may help:
Run one expression test:
tdvt.tdvt run-pattern <your_connector> --exp exprtests/standard/setup.date.datepart.second*.txt --tdp cast_calcs.<your_connector>.tds

Run one logical query test:
tdvt.tdvt run-pattern <your_connector> --logp logicaltests/setup/staples/setup.BUGS.B14080.<your_logical_config_name>.xml --tdp Staples.<your_connector>.tds

I've tried the suggestion of skipping the tests failing with the following error message:
Attempting to run query...
TableauException: Tableau cannot evaluate the query that results from this calculation.

Error running query

I noticed if I skipped the tests with that error, a new test in the same suite would then fail with that error. I repeated the cycle until no tests were left in the logical staples test. Based on that assumption, there doesn't seem to be one single culprit, but the entire logical staples test suite

One thing I've determined is that certain exceptions during query formation, like the one you're seeing above, will cause the rest of the tests in the suite to be skipped. Currently this is by design, though we're exploring changing that in a future release to make this easier to develop with.
I see the connector attached is an update to an existing one, which I believe passed these same tests previously. I'm not sure what else to suggest in isolation. Perhaps you can verify the previous version and/or driver to help eliminate some variables.
In general four independent factors could cause a test to fail:

the test endpoint does not contain the correct column type and data values
the connector implementation
the driver used by the connector
the Tableau product version of tabquerytool.exe

Let us know if you need this issue reopened or feel free to open another as well. Thanks.

Thanks for your help Ross. It seems that the test data was being loaded incorrectly into our data source. I've loaded it into a postgres source within Dremio and noticed all those errors went away.


Models, derived parameters and BIDS suffixes

I think there is a higher-level discussion going on in the @bids-standard/derivatives core. Let's see what they have to say and then address https://github.com/bids-standard/bids-bep016/pull/5#discussion_r314205390
Shout out to @effigies, in case he can point us to other threads about this models/suffixes discussion.

Computational model derivatives:

Parameter estimates
Internal variables

Statistical model derivatives: Main place there was any discussion was in https://github.com/poldracklab/fitlins/issues/125

Seems like the shared documents require some access permissions.

Made a copy and updated the links. I don't have permissions to change permissions on the original.

This is still, of course, relevant. However, there are more up-to-date iterations of this (e.g., under #69). Closing.


314 setup rate limit rules in cloudflare and backend api

Currently no rate limit for plot function

Something about versioning frontend is wrong, needs to be corrected before merge


Find the descriptor vector for any point

We can find the matched lines between 2 different images following this notebook: https://github.com/cvg/SOLD2/blob/main/notebooks/match_lines.ipynb
But how can we find the corresponding descriptor vector?

I am doing the following:
outputs = line_matcher([torch_img1, torch_img2])
line_seg1 = outputs["line_segments"][0]
line_seg2 = outputs["line_segments"][1]
line_desc1 = line_matcher.line_detection(torch_img1)["descriptor"]
line_desc2 = line_matcher.line_detection(torch_img2)["descriptor"]

print("Input image shape", torch_img1.shape, torch_img2.shape)
print("Line seq shape", line_seg1.shape, line_seg2.shape)
print("Descriptor shape", line_desc1.shape, line_desc2.shape)

I am getting the response
Input image shape torch.Size([1, 1, 1133, 827]) torch.Size([1, 1, 1753, 1275])
Line seq shape (387, 2, 2) (300, 2, 2)
Descriptor shape torch.Size([1, 128, 283, 207]) torch.Size([1, 128, 438, 319])

Question:

How can I find the endpoint descriptor for the 387 line segment detected for the 1st image?

Sorry for the lack of details, here are more explanations on how to use the descriptor vectors.
The output of your line_desc1 and line_desc2 are dense descriptor maps that have the resolution of the original image x 0.25. So you need to extract the descriptor in these two maps at the location of the endpoints of your line segments. You can use the torch grid_sample function for that.
You could actually mimic this piece of code: https://github.com/cvg/SOLD2/blob/3fe359bfbb0e8d133451e2d32b4c0afb212cbaec/sold2/model/line_matching.py#L60-L63
In your case, line_points1 would be the list of endpoints in the image 1, i.e. line_seg1.reshape(-1, 2) (and similarly for line_points2). So to get the descriptors of line segments of image 1, you can do the following:
from sold2.misc.geometry_utils import keypoints_to_grid

grid1 = keypoints_to_grid(line_seg1.reshape(-1, 2), img_size1)
desc1 = F.normalize(F.grid_sample(line_desc1, grid1)[0, :, :, 0], dim=0).reshape(128, -1, 2).permute(1, 2, 0)

After this, desc1 will be a [num_lines, 2, 128] tensor containing the descriptors of the endpoints of the lines in image 1.

Yeah, it works. Thank you :)


MSID: 91304 Version: 1 DOI: 2<IP_ADDRESS>2131

"msas": "Cancer Biology", "Computational and Systems Biology"
"msid": "91304"
"preprintDoi": "10.1101/2<IP_ADDRESS>2131"
"Reviewed Preprint posted": "2023-10-24"
"Sent for peer review": "2023-08-05"
"Posted to bioRxiv": "2023-08-06" (link: "Go to bioRxiv": "https://www.biorxiv.org/content/10.1101/2<IP_ADDRESS>2131v1/")
[PLACE PDF URL HERE WHEN AVAILABLE] See step 7
Step 1. Inform bioRxiv
Who can help: @QueenKraken, @nlisgo, @scottaubrey

[x] Manuscript is in data hub index (https://data-hub-api.elifesciences.org/enhanced-preprints/docmaps/v2/by-publisher/elife/get-by-manuscript-id?manuscript_id=91304)

Step 2. Create preview of manuscript
Who can help: @fred-atherden, @nlisgo, @scottaubrey

[ ] Manuscript is available for preview (https://prod--epp.elifesciences.org/preview/91304/v1)

[ ] Trigger import for staging: https://prod--epp.elifesciences.org/import
[ ] Sync data folder with s3://prod-elife-epp-data/data
[ ] Trigger import for staging: https://staging--epp.elifesciences.org/import
[ ] Sync data folder with s3://staging-elife-epp-data/data
[ ] Pull request created to enhanced-preprint-data
[ ] Post link to pull request below

Pull request: [PLACE LINK TO PULL REQUEST HERE]
Detailed instructions: https://github.com/elifesciences/enhanced-preprints-data#add-a-manuscript
Step 3: Awaiting public reviews and QC
Who can help: Production team

[ ] QC passed or QC not needed

Who can help: Editorial team

[x] Public reviews available on sciety (https://sciety.org/articles/activity/10.1101/2<IP_ADDRESS>2131)
[x] Manuscript and editor details at the top of this issue (Supplied by Editorial team)
[ ] Reviews returned by EPP - https://prod--epp.elifesciences.org/api/reviewed-preprints/91304/v1/reviews

Example
"msas": "Genetics and Genomics", "Neuroscience"
"msid": "84628"
"version": "1"
"preprintDoi": "10.1101/2<IP_ADDRESS>4241"
"articleType": "Reviewed Preprint"
"status": "Published from the original preprint after peer review and assessment by eLife."

"Reviewed Preprint posted": "2023-01-02"
"Sent for peer review": "2022-10-28"
"Posted to bioRxiv": "2022-11-21" (link: "Go to bioRxiv": "https://www.biorxiv.org/content/10.1101/2<IP_ADDRESS>4241v1")

Editors:
Reviewing Editor
Michael B Eisen
University of California, Berkeley, United States
Senior Editor
Michael B Eisen
University of California, Berkeley, United States

Step 4: Modify manuscripts.json (no PDF)

[ ] Reviewed preprint is published to EPP (https://elifesciences.org/reviewed-preprints/91304)

[ ] Pull request created to enhanced-preprint-client
[ ] Pull request switched to "Ready for review"
[ ] Post link to pull request below

[ ] Request that a doi be registered

[ ] Post link to #enhanced-preprint comment below

Pull request: [PLACE LINK TO PULL REQUEST HERE]
#enhanced-preprint comment thread: [PLACE LINK TO COMMENT HERE]

Instructions to modify manuscripts.json

Visit: https://github.com/elifesciences/enhanced-preprints-client/actions/workflows/publish-manuscript.yaml
Click: Run workflow
Complete the form and click "Run workflow"
A successful run should result in a new pull request at https://github.com/elifesciences/enhanced-preprints-client/pulls
Open the pull request and click the "Ready for review" button to trigger tests
Once the tests pass and you are happy with the changes the PR can be merged

Example pull request: https://github.com/elifesciences/enhanced-preprints-client/pull/334/files
Once the pull request is merged in it should be available a few minutes later.

Request that a doi
Post the following in #enhanced-preprint:
@Fred can you register a doi for https://elifesciences.org/reviewed-preprints/91304

Step 5: Awaiting search reindex

[ ] Reviewed preprint is avaliable on journal homepage (https://elifesciences.org)

The search reindex is triggered once an hour. We need the reviewed preprint to be indexed as the search application serves the journal homepage.

Additional info
If needed, the jenkins pipeline to reindex search can be triggered sooner.
https://alfred.elifesciences.org/job/process/job/process-reindex-reviewed-preprints/

Step 6: Published! Request PDF generation

[ ] Post the link to the PDF url at the top of the issue

[ ] Post link to #enhanced-preprint comment below

#enhanced-preprint comment thread: [PLACE LINK TO COMMENT HERE]
Post the following to the #enhanced-preprint on slack:
@Ryan Dix-Peek please can you generate a PDF for https://elifesciences.org/reviewed-preprints/91304

Step 7: Introduce PDF to data folder and git repo

[ ] PDF is avaliable at https://github.com/elifesciences/enhanced-preprints-data/raw/master/data/91304/v1/91304-v1.pdf

Detailed instructions: https://github.com/elifesciences/enhanced-preprints-data#add-a-pdf
Step 8: Add PDF url to manuscripts.json

[ ] Reviewed preprint PDF is available for download (https://prod--epp.elifesciences.org/reviewed-preprints/91304)

[ ] Pull request created to enhanced-preprint-client
[ ] Pull request switched to "Ready for review"
[ ] Post link to pull request below

[PLACE LINK TO PULL REQUEST HERE]

Instructions to add PDF url to manuscripts.json

Visit: https://github.com/elifesciences/enhanced-preprints-client/actions/workflows/add-pdf-url-to-manuscript.yaml
Click: Run workflow
Complete the form and click "Run workflow"
A successful run should result in a new pull request at https://github.com/elifesciences/enhanced-preprints-client/pulls
Open the pull request and click the "Ready for review" button to trigger tests
Once the tests pass and you are happy with the changes the PR can be merged

Example pull request: https://github.com/elifesciences/enhanced-preprints-client/pull/397/files
Once the pull request is merged in it should be available a few minutes later.

Step 9: Done!

[ ] Kettle is on!

Jiri Bartek should have email address<EMAIL_ADDRESS>elocations missing from reference list.

Email issue is fixed. Going to mark as QC OK, but shout if there are other reasons this one should be blocked @JGilbert-eLife.


Select box "Stub senders" | "Never" | "Always" not handled properly

In the debug tab
You can change the selection without entering edit mode, but then the value is not saved. This is confusing. Changing the selection should not be possible without edit mode.
Test tab
I edit my report and enter edit mode when I see my report. Then I change the selection, from Stub al Senders to Never. I get a confirmation dialog and press save. But I see the old value again, Stub all Senders.
When I do the above WITHOUT entering edit mode, I manage to change the selected value.

This is also how it works in the old ladybug, the stub strategy can be changed even if edit is not enabled.

@jacodg, can you decide?

This has always been unclear in the old GUI. We didn't rethink and copy from old GUI but it would be nicer to change this in the new GUI.


Replace [dev_dependencies] with newer [dev-dependencies] syntax.

It seems that dev_dependencies is older syntax that has been deprecated in favor of the variant with the hyphen, and some newer cargo utilities don't support it:
$ cargo add once_cell
error: Deprecated dependency sections are unsupported: dev_dependencies

This PR replaces it everywhere in the repository.

Thank you! We'll never catch up with all the latest conventions for Cargo ;-)

Maybe one day cargo-semver-checks can have a peer project: cargo-config-checks :)


enhance(workspace): Move engineClient to v3

This change moves engineClient to v3 for the following methods

getNote
getNoteMeta
bulkGetNotes
bulkGetNotesMeta

Similar to the backend, this will be under a dev flag enableEngineV3

Can we also do it for queryNotes()?

Can we also do it for queryNotes()?
Existing changes look good.

Right now its tied with SQLiteMetadataStore which is different from how we implement queryNotes in the engine v3. I'll put this under a flag once we clean up the QueryStore/SQLite logic in v3 first


Update Supported Chains

Updated the supported chains table to reflect new Service IDs and correct names. Old chains were removed.

LGTM!


Integrate Stale bot with PR template and fixed typos

Description
The objective is to add a Stale bot and a PR template to streamline the contribution process. Additionally, fixed a few typos and grammatical mistakes in README.
Partially Resolves: #94
cc: @PaulTR

LGTM


Change AirPlayRoutePickerView icon?

This is excellent! Would it be possible to have the ability to set the icon. At the moment the default seems to be the 'airplayaudio' icon. Thanks.

@nimisis Thank you for using this package.
It's not a custom icon, but it is something that Apple provides with the AVRoutePickerView. I was looking into some native solution but looks like Apple doesn't let you customize this icon. As discussed in this thread,
Setting AVRoutePickerView icon
I will keep looking for some possibility, otherwise I will implement some workaround over the weekend.

I did check it out. As I confirmed Apple doesn't let you change the AVRoutePickerView Icon, but what you can do is, you can use the Stack widget to place any Icon on AVRoutePickerView and set AVRoutePickerView colors to transparent. Please see the example,
Container(               width: 44.0,               height: 44.0,               child: Stack(                 alignment: Alignment.center,                 children: [                   Icon(                     Icons.play_circle_filled,                   ),                   AirPlayRoutePickerView(                     tintColor: Colors.transparent,                     activeTintColor: Colors.transparent,                     backgroundColor: Colors.transparent,                   ),                 ],               ),             ),
It will change Airplay Icon to Play Icon, but will still perform the required functionality.

Please feel free to comment if this is what you were looking for or if you need something else?

This is a very helpful solution. Thanks!


include feeds in results when using main search bar - low priority

when using the default search, feeds do not show up
The ideal situation is when searching for something, example: hurricanes
currently the search feed does not include feeds in its search, it would be nice to bring them closer together
(understandably this is a lower priority as the entire search needs to get an update at some point, to prioritize followers, mutuals, etc)
posts that mention the word hurricanes show up, and if a feed has the name hurricanes, that would show up in an additional tab
so it looks like  this

Guess I'll also include a media tab to also be included in results (photos)


network.trr.mode 0 is now ~enabled

This line: https://github.com/yokoffing/Betterfox/blob/0334bea9721fa734506160f0770515817c094972/Securefox.js#L647
Says the setting at 0 means disabled. In FF117 (unsure when this changed), 0 means "default" which is "sometimes enabled":

Only mildly related, but maybe there should be a note recommending people use something other than CloudFlare for their DOH.

@alana-glitch Says the setting at 0 means disabled. In FF117 (unsure when this changed), 0 means "default" which is "sometimes enabled

You are correct. This will be updated in v.118 documentation. https://github.com/yokoffing/Betterfox/commit/2e03ce1ad06c92b2c2f19f0db11b75e03d99d132

@iam-py-test maybe there should be a note recommending people use something other than CloudFlare for their DOH.

Added a note. https://github.com/yokoffing/Betterfox/commit/873cc4476f40614189b3a8cbbaa5ff70baa1c88a


Chat GPT API key set error

while saving the api key i have ths error
UnityException: Creating asset at path Assets/Resources/.asset failed.
ChatdollKit.ChatdollEditor.OnInspectorGUI () (at Assets/ChatdollKit/Editor/ChatdollKitEditor.cs:230)
UnityEditor.UIElements.InspectorElement+<>c__DisplayClass72_0.b__0 () (at <53ddbed73faf4fe3b980a493ab4e6639>:0)
UnityEngine.GUIUtility:ProcessEvent(Int32, IntPtr, Boolean&)

fixed it.


Refactor/dir structure

refactor kmir-pyk tool implementation.
flatten project directory structure

@sskeirik sounds great!! Thank you.


Setting more effective livenessProbe

I have tried the livenessProbe indicated in this repository and if one consul node is unhealthy, the pod is not restarted. With this change the pod will be restarted because it checks if the consul node is healthy.

Tnx @Towmeykaw I will close this pull and re-open new one.