Not able to build in Release mode

I just lost so many hours of debugging and searching where the error might be and why the application is not starting in Release mode. I was getting the following error:
C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(254,5): error MSB8066: Custom build for 'C:\Users\Switchez\Desktop\shadcn_flutter-master\example\build\windows\x64\CMakeFiles\cc5b1f2978dc4c4cf393f05d54f85060\flutter_windows.dll.rule;C:\Users\Switchez\Desktop\shadcn_flutter-master\example\build\windows\x64\CMakeFiles\5a50716fe7f2cd22566f40ea0e4f1539\flutter_assemble.rule' exited with code 1. [C:\Users\Switchez\Desktop\shadcn_flutter-master\example\build\windows\x64\flutter\flutter_assemble.vcxproj]
After some debugging i found out the the widget that was causing all of the mess was "showDropdown". This is the one i found, but there might be more. And this if happening with the new version, with the old like 2-3 weeks before there wasnt any problems.
here is example code to reproduce:
             showDropdown(
                  context: context,
                  modal: true,
                  builder: (BuildContext dropdownContext) {
                    return DropdownMenu(
                      children: [
                        const MenuLabel(child: Text('Select')),
                        const MenuDivider(),
                      ],
                    );
                  },
                );

This is the commit that cause the issue: 1bda585 - Removed unnecessary animated container

Wrapping back OverlayManagerLayer on line 510 with:
MultiModel(
      data: [
        Model(#shadcn_flutter_smooth_animation, enableThemeAnimation),
      ],
child: OverlayManagerLayer
)

With this change i am able to build again in release


[CTFE] compile time parsing of hex floats

ellery-newcomer reported this on 2012-08-08T12:55:19Z
Transfered from https://issues.dlang.org/show_bug.cgi?id=8523
CC List

andrei (@andralex)
clem (@legrosbuffle)
peter.alexander.au (@Poita)

Description
doesn't work, but should.

enum string s = "0x9.D70A3D70A3D70A4p-3";
enum d2 = to!real(s);
pragma(msg, d2);

gives me:

/usr/include/dmd-d/std/conv.d(2305): Error: Cannot convert &real to long* at compile time
/usr/include/dmd-d/std/conv.d(1592):        called from here: parse(value)
/usr/include/dmd-d/std/conv.d(268):        called from here: toImpl(_param_0)
test.d(14):        called from here: to("0x9.D70A3D70A3D70A4p-3")
/usr/include/dmd-d/std/conv.d(2305): Error: Cannot convert &real to long* at compile time
/usr/include/dmd-d/std/conv.d(1592):        called from here: parse(value)
/usr/include/dmd-d/std/conv.d(268):        called from here: toImpl(_param_0)
test.d(15):        called from here: to("0x9.D70A3D70A3D70A4p-3")
to("0x9.D70A3D70A3D70A4p-3")

however,

double d = to!real(s);
writeln(d);

compiles and prints

1.23

peter.alexander.au (@Poita) commented on 2013-01-05T12:03:21Z
Added CTFE tag. I don't think there's any sane way to do this without CTFE support for the pointer cast, or at least unions.

dbugz commented on 2018-08-07T05:18:05Z
Got rid of all the hex bit-packing in `std.conv.parse`, only missing bit is the call to C's `ldexp`, which still causes this to fail at compile-time. You can replace that with manual exponentiation if wanted to fix this, just as done for decimal strings now.

clem (@legrosbuffle) commented on 2015-05-22T13:05:03Z
pull:
https://github.com/D-Programming-Language/dmd/pull/4674


Fix max tokens for embedding models

Based on other documentation, the max tokens for embedding models should be 8,192 but not 8,191. Reference: https://learn.microsoft.com/en-us/azure/ai-services/openai/how-to/embeddings?tabs=console

@mrbullwinkle
Can you review the proposed changes?
IMPORTANT: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

Thank you for contributing to this Azure documentation. Unfortunately, changes to AI Services content can't be accepted this week. The Skilling Content group is migrating this content to a new repository: azure-ai-docs.
In the meantime, we are closing this PR and tagging it so that when the content is available in the new repo, we can follow up with new location information.
#label:"migrate-followup"
#please-close

@nkgami We’re happy to share that contributions to machine-learning, ai-studio, ai-services, genomics, open-datasets, search are once again possible at azure-ai-docs. We appreciated your patience during this migration.
Find your article in the new repository and make the changes there (or copy/paste the raw markdown from your changed file) and open a new PR.
#remove-label:"migrate-followup"


Support for Angular 14

🐞 Bug report
Description
The platform-server library doesn't support Angular v14. Updating the packages.json should fix it.
Sorry for not following the template

for now you can also just --force the installation. Works fine for me.

That's what I'm doing, but it can't be considered a solution for this issue
Em sex., 21 de out. de 2022 04:18, Ralph Küpper @.***>
escreveu:

for now you can also just --force the installation. Works fine for me.
—
Reply to this email directly, view it on GitHub
https://github.com/scullyio/scully/issues/1625#issuecomment-1286559150,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGQMEKZ6LPAI5UNJVA7ONXTWEI7T7ANCNFSM6AAAAAARDTL3EY
.
You are receiving this because you authored the thread.Message ID:
@.***>

this is causing some issues, a blank angular install and running the installation steps for scully fails
`    setTimeout(function () { throw err; }, 0);
^
TypeError: entry.message.split is not a function
at MapSubscriber.project (/Users/jamesclaridge/Code/smash/node_modules/@angular-devkit/core/src/logger/indent.js:35:58)
at MapSubscriber._next (/Users/jamesclaridge/Code/smash/node_modules/rxjs/internal/operators/map.js:49:35)
at MapSubscriber.Subscriber.next (/Users/jamesclaridge/Code/smash/node_modules/rxjs/internal/Subscriber.js:66:18)
at Subject.next (/Users/jamesclaridge/Code/smash/node_modules/rxjs/internal/Subject.js:60:25)
at IndentLogger.log (/Users/jamesclaridge/Code/smash/node_modules/@angular-devkit/core/src/logger/logger.js:83:23)
at IndentLogger.error (/Users/jamesclaridge/Code/smash/node_modules/@angular-devkit/core/src/logger/logger.js:98:21)
at /Users/jamesclaridge/Code/smash/node_modules/@scullyio/init/src/ng-add/index.js:89:24
at MergeMapSubscriber.project (/Users/jamesclaridge/Code/smash/node_modules/@angular-devkit/schematics/src/rules/call.js:75:24)
at MergeMapSubscriber._tryNext (/Users/jamesclaridge/Code/smash/node_modules/rxjs/internal/operators/mergeMap.js:67:27)
at MergeMapSubscriber._next (/Users/jamesclaridge/Code/smash/node_modules/rxjs/internal/operators/mergeMap.js:57:18)`

Note sure if this is the same issue.
I'm using angular 14.2.12.
when running ng add @scullyio/init, after renderer selection it just terminates without warnings or errors. only modified files are the package.json and package-lock.json
ℹ Using package manager: npm
✔ Found compatible package version<EMAIL_ADDRESS>✔ Package information loaded.

The package<EMAIL_ADDRESS>will be installed and executed.
Would you like to proceed? Yes
✔ Packages successfully installed.
? Which route renderer would you like to use? Puppeteer

Update following another issues advice from @nelsongutidev , adding "defaultProject": "client" to angular.json fixed installing scully for angular 14 for me.

^solution above not working for angular 15 T__T

@Deliana90 What error are you seeing?

@nelsongutidev
node v18.13.0
<EMAIL_ADDRESS>create fresh project angular then add defaultProject like above solution, then...

show nothing

@Deliana90 Did you try installing the platform-server library package with the --force flag?

^solution above not working for angular 15 T__T

Sharing my Angular v15.2.6 remediation steps below. They can probably be cleaned up by removing a redundant/unnecessary step or two - but this worked for me!

Ensure you have a least one route defined in app-routing
Add Scully (this will terminate w/o errors after selecting a route renderer): ng add @scullyio/init
Install Scully puppeteer: npm install @scullyio/scully-plugin-puppeteer
Build your angular project: ng build
Create a ScullyConfig file: scully..config.ts (replace all instances of projectName with your project name defined in angular.json within "projects")
import { ScullyConfig } from '@scullyio/scully';

export const config: ScullyConfig = {
  projectRoot: './src',
  projectName: 'projectName',
  outDir: './dist/static',
  routes: {},
};

Build Scully app, specifying your project name: npx scully --project <projectName>
Start the Scully server: npx scully serve
Navigate to http://localhost:1668 - view page source to ensure that Scully is working properly

Hope this helps! KH

Been trying out the ideas for Angular 15 (Thank you Kalia Hayes).  My notes are in this SO question here:
https://stackoverflow.com/questions/76067189/running-scully-in-an-angular-15-project

https://link.medium.com/oyxABoBQezb
Can you try the steps on this post?
This goes through the manual installation process in detail

Worked for Angular 16 as well! Thanks! :)


Allure report generation issues due to change in listener order after github 2588

TestNG Version
7.5 onwards
Expected behavior
The Allure report listener would be triggered at the end of the list of listeners for runTestListeners()

Actual behavior
Since 7.5 onwards, the list of listeners is reversed for onFinish test listeners.
List<ITestListener> listeners = isFinished ? Lists.newReversedArrayList(this.m_notifier.getTestListeners()) : this.m_notifier.getTestListeners();

By reversing this order, the allure listener is triggered first stopping the reporting before any screenshots / end of test data can be captured and attached.
There is no way to stop this reversing of listener order.
Is the issue reproducible on runner?

[ ] Shell
[x] Maven
[ ] Gradle
[ ] Ant
[ ] Eclipse
[x] IntelliJ
[ ] NetBeans

Maybe you could refer to this blog post of mine and see if that helps: https://rationaleemotions.com/listener_order/ You can always build your decorated listener which can inject the listeners in the order you would like. Can you please try that?

Hi @krmahadevan I'll try and get an implementation going today to resolve this. Does this approach work with mixing 3rd and 1st party libraries like io.qameta.allure.testng + my own listeners?

Does this approach work with mixing 3rd and 1st party libraries like io.qameta.allure.testng + my own listeners?

Yes it should. But if the 3rd party libraries are being wired in via service loaders, then there's not much that you can do, because TestNG will find them as well and i am not sure as to what is the order of that because that's the JVM working.

@krmahadevan Thanks for this article, using the META-INF of the parent dependency project main>resources>META-INF>services>org.testng.ITestNGListener I could specify the order that the listeners were picked up

So can we close this issue @emersonbaillie ?


{Quantum][DRAFT -- Do not merge] Correct provider case

When creating a workspace with the CLI, if a provider ID's case is not correct, that provider will not appear in the portal.  To ensure that the provider ID case is correct, this PR substitutes the provider ID from the offerings API for the provider ID specified in the az quantum create workspace command.
During testing with multiple providers specified in a single command, a timeout occurred, so the workspace-creation timeout has been increased.

This checklist is used to make sure that common guidelines for a pull request are followed.

Quantum

Changes were made in the Quantum portal extension.  No changes are required in the Quantum CLI extension.


Fix locked project roles

Summary
Fixes #5952

User should not be able to use Disabled/Locked Project Roles after the upgrade
How to test

Go to users and auth, > roles and cluster roles.
Pick a role e.g. Manage Cluster Backups and select Edit Config from the action menu for it. Set 'Locked` to yes
Go to the Cluster and Project Members and click Add > custom you'll get a list of custom roles
Manage Cluster Backups should be disabled

@bisht-richa There are two comments on this PR not marked as resolved - have they been? I see its been approved, but we need to resolve conversations so it is clear, if that is the case.

@bisht-richa There are two comments on this PR not marked as resolved - have they been? I see its been approved, but we need to resolve conversations so it is clear, if that is the case.

@bisht-richa There are two comments on this PR not marked as resolved - have they been? I see its been approved, but we need to resolve conversations so it is clear, if that is the case.

Yes those are resolved.


feat(python): use new ruff instead of ruff_lsp

Use the new builtin rust-based ruff server instead of the python-based ruff_lsp wrapper.
Ruff_lsp is not deprecated (yet) but the new rust-based server is faster and is (almost?) feature complete.
Though it's still in beta, it has been highlighted in the latest ruff release and it has worked well for me for a while.

Thanks!

Is this a replacement for all three: black/flake8/pyright (or basedpyright)?

After updating I've lost the ability for ruff to correctly format imports and for ruff to complain about non formatted import block I001


Optimize self perservation

Coverage decreased (-0.05%) to 70.135% when pulling af086c00387ac438805536171aad48a4a7d8296b on little-cui:little-cui into ab7acef2b3ed074760a3cd47647cb3b2b3ddeed0 on ServiceComb:master.

Codecov Report

Merging #136 into master will decrease coverage by 0.06%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #136      +/-   ##
==========================================
- Coverage   65.85%   65.78%   -0.07%
==========================================
  Files          18       18
  Lines        4288     4288
==========================================
- Hits         2824     2821       -3
- Misses       1290     1292       +2
- Partials      174      175       +1

Impacted Files
Coverage Δ

server/service/governservice.go
64.07% <0%> (-1.46%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ab7acef...af086c0. Read the comment docs.


Multiple Icon Update

Update for YouTube vanced and OnePlus 12 dialer

#574 already adds an icon for YouTube ReVanced

Thanks for your contribution, as @Chefski said the changes had been merged in #574, I'll close this one.


set default published contact recruiter

This is not an issue. It's a feature request. I manage all my recruiter and prefer the default published contact recruiter be set to my user profile in Bullhorn. More specifically, don't allow recruiters to touch this drop down menu when in the published job page.

As this is a potential feature for the Bullhorn core platform, I have submitted this as feedback to them.  For now I am closing this as this isn't a feature for the career portal frontend


InfluxDB query with time format anything other than "ms" is not working

Hi,
I am doing a POC on Trickster where I am using it as a proxy to an InfluxDB. I noticed that it is not returning any value when the query has a time format anything other than "ms". Below are few examples.
Example 1: (with timestamp returned in string format)
Request:
http://trickster-example:8480/query?db=influx&q=select count("sample_field") from "sample_metric" where time > now() - 1h
Expected Response:
{"results":[{"statement_id":0,"series":[{"name":"sample_metric","columns":["time","count"],"values":[["2020-10-13T21:46:00-04:00",0],["2020-10-13T21:45:00-04:00",10]]}]}]}
Actual Response:
{"results":[{"statement_id":0,"series":[{"name":"sample_metric","columns":["time","count"],"values":[["2020-10-13T21:46:00-04:00"0],["2020-10-13T21:45:00-04:00"10]]}]}]}
The response JSON is not properly built in this case. It is missing a "," between the time part and the actual value.
Example 2: (with timestamp returned in epoch ms format)
Request:
http://trickster-example:8480/query?db=influx&epoch=ms&q=select count("sample_field") from "sample_metric" where time > now() - 1h
Expected Response:
{"results":[{"statement_id":0,"series":[{"name":"sample_metric","columns":["time","count"],"values":[[16026403800000,0],[160264032000010,10]]}]}]}
Actual Response:
{"results":[{"statement_id":0,"series":[{"name":"sample_metric","columns":["time","count"],"values":[[16026403800000],[160264032000010]]}]}]}
The response JSON is not properly built in this case. It is missing the value and returning only the timestamp.

@anuprout are you building and running from main? If so, i think at least one of these issues was fixed via PR merged about 24 hours ago, and you need to repull.
For doing any POC work, I would recommend downloading and running one of the stable releases from the releases section, or building against the 1.1.x branch, which is stable. main is dedicated to the 2.0 release; since that development is ongoing, changes are frequent, and we've not yet cut the first pre-release, things may not work. This is indicated in the main README.
If you are seeing these issues w/ 1.1.3 then let us know and we'll take a look.

Hi @jranson , yeah I am running from main. I will re-pull and see if it is fixed. I will also try the 1.1.x and get back. Just had a look at the code. I think it would be better to use Influx provided query parser for future releases  instead of using regex and own logic to parse them.

In the 2.0 release, we are making a lot of changes to the parsers. Since we want to support many SQL-based providers (e.g., MySQL via Grafana), and already support ClickHouse and InfluxQL (which are t-sql variants), 2.0 will implement its own extensible lexer and parser for SQL-like languages, and we actually already have that framework done and implemented for ClickHouse. This approach will hopefully facilitate and accelerate additional provider integrations without being locked into someone else's libraries that may or may not meet our needs.


Enable reflector success tracking in database to prevent re-attempting a recent upload

ManagedStream.upload_to_reflector should be updated to call SQLiteStorage.update_reflected_stream upon successfully uploading or the server indicating it has the stream by refusing the sd blob.
StreamManager.reflect_streams should only reflect streams returned by SQLiteStorage.get_streams_to_re_reflect. Additionally, reflect_streams is currently not called anywhere. It should be called ~periodically using the auto re reflect interval setting in Config~ up to once per 5 minutes upon startup of the StreamManager.

https://github.com/lbryio/lbry/commit/3589cc9977e4229348753e2dd8035d18af928733 and https://github.com/lbryio/lbry/commit/05915c540aace84a6cb5cf43a9264a983862e358 save reflected/not needed streams to the database
https://github.com/lbryio/lbry/commit/262b9a624bf4e0be4f91b117e87f1562cebb5a8e updates file_reflect


Only outputting warning about docformatter failing if returncode is n…

…ot 3, which is used to indicate that files would be formatted.
Signed-off-by: Alexander Xydes<EMAIL_ADDRESS>Fixes #333

Codecov Report

Merging #334 (9b7afc3) into master (1ac53c4) will decrease coverage by 4.87%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##            master     #334      +/-   ##
===========================================
- Coverage   100.00%   95.12%   -4.88%
===========================================
  Files           51       51
  Lines         2894     2895       +1
===========================================
- Hits          2894     2754     -140
- Misses           0      141     +141

Impacted Files
Coverage Δ

...tick_tool/plugins/tool/docformatter_tool_plugin.py
100.00% <100.00%> (ø)

...tatick_tool/plugins/tool/shellcheck_tool_plugin.py
53.33% <0.00%> (-46.67%)
:arrow_down:

...tatick_tool/plugins/tool/uncrustify_tool_plugin.py
66.66% <0.00%> (-33.34%)
:arrow_down:

statick_tool/plugins/tool/cppcheck_tool_plugin.py
85.10% <0.00%> (-14.90%)
:arrow_down:

...tatick_tool/plugins/tool/perlcritic_tool_plugin.py
87.03% <0.00%> (-12.97%)
:arrow_down:

...tatick_tool/plugins/tool/clang_tidy_tool_plugin.py
87.32% <0.00%> (-12.68%)
:arrow_down:

...tick_tool/plugins/tool/clang_format_tool_plugin.py
90.26% <0.00%> (-9.74%)
:arrow_down:

statick_tool/plugins/tool/cpplint_tool_plugin.py
90.32% <0.00%> (-9.68%)
:arrow_down:

...tatick_tool/plugins/tool/flawfinder_tool_plugin.py
91.11% <0.00%> (-8.89%)
:arrow_down:

statick_tool/plugins/tool/spotbugs_tool_plugin.py
91.56% <0.00%> (-8.44%)
:arrow_down:

... and 6 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1ac53c4...9b7afc3. Read the comment docs.

Codecov Report

Merging #334 (9b7afc3) into master (1ac53c4) will decrease coverage by 4.87%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##            master     #334      +/-   ##
===========================================
- Coverage   100.00%   95.12%   -4.88%
===========================================
  Files           51       51
  Lines         2894     2895       +1
===========================================
- Hits          2894     2754     -140
- Misses           0      141     +141

Impacted Files
Coverage Δ

...tick_tool/plugins/tool/docformatter_tool_plugin.py
100.00% <100.00%> (ø)

...tatick_tool/plugins/tool/shellcheck_tool_plugin.py
53.33% <0.00%> (-46.67%)
:arrow_down:

...tatick_tool/plugins/tool/uncrustify_tool_plugin.py
66.66% <0.00%> (-33.34%)
:arrow_down:

statick_tool/plugins/tool/cppcheck_tool_plugin.py
85.10% <0.00%> (-14.90%)
:arrow_down:

...tatick_tool/plugins/tool/perlcritic_tool_plugin.py
87.03% <0.00%> (-12.97%)
:arrow_down:

...tatick_tool/plugins/tool/clang_tidy_tool_plugin.py
87.32% <0.00%> (-12.68%)
:arrow_down:

...tick_tool/plugins/tool/clang_format_tool_plugin.py
90.26% <0.00%> (-9.74%)
:arrow_down:

statick_tool/plugins/tool/cpplint_tool_plugin.py
90.32% <0.00%> (-9.68%)
:arrow_down:

...tatick_tool/plugins/tool/flawfinder_tool_plugin.py
91.11% <0.00%> (-8.89%)
:arrow_down:

statick_tool/plugins/tool/spotbugs_tool_plugin.py
91.56% <0.00%> (-8.44%)
:arrow_down:

... and 6 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1ac53c4...9b7afc3. Read the comment docs.


database

Which database does your original data come from?

Have you generated your own data? If not, which dataset is used?


[PE-D][Tester B] Able to add multiple tags with same word but different letter cases

Command Involved
add
Observation:
The content for the tag is case-sensitive and multiple tags with same word but different letter cases are considered different tags.
Steps to reproduce:
￼
Rationale behind:
Since the case difference doesn't affect the meaning of the tag, would it be more reasonable to prevent multiple tags with same word but different letter cases to be added to the system?

Labels: severity.Low type.FeatureFlaw
original: Ella-e/ped#7

This is valid, however the tagging functionality still works as intended and it is okay if user assigns tags with same names but different cases.
Fix: State in UG that tags are case-sensitive.

Addressed by #238


Flex Line does not display legend

@ssunkara1 , can you provide details of this issue or close it?

2010-12-17 verified issue still present.


entry type:layer to replace mvt_clone

The mvt_clone type entry had several bugs and applied an unnecessary complex logic.
The mvt_clone module has been removed and the mvt_clone entry method has been deprecated. The mvt_clone method will warn and return the new layer entry method.
A layer.featureSet filter has been to the featureStyle method. Feature not included in the featureSet will not be styled.
The layer/format/mvt module documentation has been revised. The clone logic has been removed.
The type:layer entry method assigns a Key property which is the orignal layer key required to get a location.
The highlight interaction getFeature method has been updated to recognise the layer.Key property.
related fixes:
Removed layer/featureStyle module function params.
Added missing @requires to /ui/locations/entries module.
Fixed /ui/locations/entries/numeric declaration.
Fixed /layer/changeEnd declaration.
Removed deprecated ui/locations/entries/default module.

To see the specific tasks where the Asana app for GitHub is being used, see below:

https://app.asana.com/0/0/1206602587669819

The featureSet and lookupFeature logic has now been merged in the showLayer method of the layer entry and the featureProperties method of the featureStyle module.
The layer decoration in the layer entry has been moved to the decorateLayer method in the layer entry module.
A changeEnd event listener for zoom restricted layer has been added to the  decorateLayer to disable the entry checkbox if the entry layer is out of range.
https://github.com/GEOLYTIX/xyz/issues/1543 must be completed before the layer entry PR can be resolved.

a4edfd93aaf4288ee3220343281cad8f58107fd0
// Request the location fields from layer json & id.
  const response = await mapp.utils.xhr(`${mapp.host}/api/query?` + mapp.utils.paramString({
    template: location.getTemplate,
    locale: location.locale,
    layer: location.layer.key,
    table: location.table,
    id: location.id,
  }));

I noticed that the layer property on the getInfoj() method in the lib/location/get.mjs module will be set by a unique layer name from the layer entry, which wouldn't work. I am going to add in the location.layer.Key as a first option when querying the data.
  // Request the location fields from layer json & id.
  const response = await mapp.utils.xhr(`${mapp.host}/api/query?` + mapp.utils.paramString({
    template: location.getTemplate,
    locale: location.locale,
    layer: location.layer.Key || location.layer.key,
    table: location.table,
    id: location.id,
  }));

An infoj entry layer with multiple thematics is not working correctly.
the theme is swapped correctly on the mapview, but the legend is not updated and the legend styling is just lost.
To swap an mvt_clone to type layer - is it supposed to be as simple as just changing the type? I did this but I crash here on layer.style.theme.title

Yes, the layer entry type will replace the mvt_clone entry type method.

https://github.com/GEOLYTIX/xyz/pull/1386/commits/b81cd41c394527d5355cb572246fb3b01aadac0f
@simon-leech The layer entry method will now assign the layer.style.panel and the dropdown callback will replace the children in the style.panel.


add: allow fetch request from worker scope.

Attempt to resolve #23 again.

@extraymond Sorry for the delay on this! Was the reformatting in cargo.toml something vscode did automatically? Is there a way to turn it off?

@extraymond Sorry for the delay on this! Was the reformatting in cargo.toml something vscode did automatically? Is there a way to turn it off?

Ah! Didn't notice that. Will try to fix that.

@jbr Cargo.toml is checkout against the current main and added the needed feature flag.

Thanks!

Am I correct that this is semver-minor? Existing features continue to work as before?


fix(version): include the updated root package-lock.json file in commits

Fixes #146.
Ideally, a corresponding test should also be added, but I don't have enough knowledge about the internals and how tests are written for lerna-lite to be able to write such a test myself.

@ghost91-
The test is here, do you want to give a quick look and see if you can add a test before I merge this?

The problem is related to how the different promise calls were orchestrated, and when files were being added to be committed. I don't think it's easily possible to adjust this particular test, since it does the orchestration itself (in a different way, by the way). And it doesn't even commit anything, so it's not possible to check for the problem.
So even with this, I have absolutely no clue how to test this. I think it would probably fit better in https://github.com/ghiscoding/lerna-lite/blob/main/packages/version/src/tests/version-command.spec.ts, since the bug occurred in the version command itself (not one of the helper functions). Probably https://github.com/ghiscoding/lerna-lite/blob/main/packages/version/src/tests/version-command.spec.ts#L807 is the right test case. But I have no clue how I would test if there are any uncommitted files (the package-lock.json)

@ghost91-
as long as you have at least tested it locally and it fixed the issue you detected then I'm fine with accepting it as is, and all the unit test are still passing so it should be fine for now.

Yeah, I tested it thoroughly. With this change, all is good. Thanks for merging it so quickly. The files not being commuted created quite a bit of noise in our automated release process. With this, it will be smooth sailing :)
Thanks a lot on general for picking this project up. I understand it’s a lot of work, and you can also only do so much. But it’s really helping us! If I find the time, I’ll try to contribute back a little (if there is something that’s easy enough for me to handle).

Thanks a lot in general for picking this project up. I understand it’s a lot of work, and you can also only do so much. But it’s really helping us! If I find the time, I’ll try to contribute back a little (if there is something that’s easy enough for me to handle).

Yeah it's a challenge for sure, I also don't understand all of the code and I made sure to mention that in a few places in the readme so that people don't get their expectation too high. 😉. Anyway I think my main goal was achieve by updating all dependencies and I also more it more modular by having some commands as optional, so I think it's a win win 😃
The code that you modified was actually my own contribution to deal with the lock file in this very own repo so apart from this little bug it's nice to see that it works for others too
Thanks for the contribution & feedback, I'm not exactly sure when I'll release this but it should within the next few days.
Cheers

released under 1.2.0


Add for BigQuery, since they now support FK & PK

You can now define Foreign and Primary keys on table columns in BigQuery.  Would love to see this implemented 🙏 ❤
Google docs regarding adding FK and PK constraints.
https://cloud.google.com/bigquery/docs/reference/standard-sql/data-definition-language#alter_table_add_constraint_statement
Queries to pull the information off the schema about FK & PK.
https://cloud.google.com/bigquery/docs/information-schema-constraint-column-usage
SELECT *
FROM <PROJECT_ID>.<DATASET>.INFORMATION_SCHEMA.CONSTRAINT_COLUMN_USAGE;

https://cloud.google.com/bigquery/docs/information-schema-key-column-usage
SELECT *
FROM <PROJECT_ID>.<DATASET>.INFORMATION_SCHEMA.KEY_COLUMN_USAGE;

https://cloud.google.com/bigquery/docs/information-schema-table-constraints
SELECT *
FROM <PROJECT_ID>.<DATASET>.INFORMATION_SCHEMA.TABLE_CONSTRAINTS;

General spot for BQ schema information: https://cloud.google.com/bigquery/docs/information-schema-intro

Plus 1 to the above. This would be an awesome addition!

Ditto - BigQuery support would be a game changer!

Hey everyone - I've got a PR ready for BQ. https://github.com/Snowflake-Labs/dbt_constraints/pull/73


[Bug]: Autopilot "Lowest Fee" and manual coin selection "Use smallest UTXO's first" both use more UTxOs than needed

Describe the bug
When using either the default coin selection setting of Autopilot with "Lowest Fee' OR when using manual coin selection that automatically uses "Use smallest UTXO's first" the result is the same for both: more UTxOs are selected for input to a transaction than required to satisfy the output and fee. This results in paying a higher fee than could have been achieved with less inputs.
Reproduce

Have two of more UTxOs in the wallet
Make a transaction with an output amount plus fee significantly lower than at least one of your UTxOs
If using Manual coin selection, the 'Auto' option will show you which UTxOs are being selected (to use smallest UTXO first) but it actually uses more UTxOs than needed, including the largest.
If using Autopilot coin selection, it isn't possible to immediately see the selected UTxOs. You can either check the proposed fee against your expectations (compare with manual coin selection) or you can submit the transaction and check what inputs were actually used.
Either way, the wallet uses more inputs than necessary when trying to optimise for low fee or use smallest UTxO first.

Screenshots / Recording
This screengrab shows manual coin selection for a transaction on regtest. Either of the two UTxOs are large enough to satisfy the total requires yet the Auto insists on using both. The same two UTxOs are selected when using Autopilot (default).
https://github.com/synonymdev/bitkit/assets/74595920/83ebc5e1-b5d1-4305-9c52-8b03abc71d60
Operating system
Android 13 TKQ1.220829.002
Bitkit version
c55c045f58b7e76ee82acdc1419bccf9db8490ae
Log output
No response

Manual Coin Selection is a feature we have to temporarily remove from the UI until a later date (after we come out of beta) where we can enable it and thoroughly test it. We were meant to remove/comment out this setting earlier to avoid confusion, but never got around to it.

This problem is partly hidden by https://github.com/synonymdev/bitkit/pull/1761 because now the user doesn't know what type of autopilot is being used. However, in manual mode there is still an Auto option that is 'use smallest utxo' and that doesn't work correctly.

The simplest fix here is to remove the text "Small: uses smallest UTxO's first"

Should start with implementation in beignet and add tests there. Then integrate into Bitkit.

User can select coin selection method:

Manual
Autopilot

Autopilot mode options:

Consolidate
Maximum Privacy
Minimum UTXOs


Dhirajmishra98 dsa(java)

Contains DSA notes and programs

Accepted as hacktoberfest PR.
Won't be merging this to the repository for the following reasons:

The programs lack command line argument based input. (Please refer existing programs in the repository to know more).
The programs don't have README file, the READMEs help any user to know about the program including logic, concept and even how to run the program. (Again, please refer the same from the existing programs available in the repository to know more).

If possible, please ensure that the program and it's readme is in a sub-folder under the name of the program.


using src directory

Related Issue

Information about the related issue

Closes: #392
Describe the changes you've made
Incorporating the feature of Next.js 13, which allows for the addition of an "src" folder, could significantly improve the code organization within our project.

Type of change
Improving Code Organization
What sort of change have you made:
using src directory to separate the application code from the project configuration files.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[x] Code style update (formatting, local variables)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation update.
[ ] This change requires a documentation update

How Has This Been Tested?

Checklist

[x] My code follows the guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented on my code, particularly wherever it was hard to understand.
[x] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.
[x] I have added tests that prove my fix is effective or that my feature works.
[ ] Any dependent changes have been merged and published in downstream modules.

Screenshots (if applicable)

Original
Updated

original screenshot
updated screenshot

Code of Conduct

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

Hey @darkterminal @vinzvinci @siddhi-244 @mkubdev
Please check this PR.

It looks good to me, and I don't see any problems.
You changed components and app directories into a src directory within the project's folder structure, and it is visible from the paths.
I have a small suggestion: please avoid changing the styling of the code because it can make the review process more challenging when there are minor styling changes throughout the files. Perhaps consider disabling the default code formatting extension.

Hey, I will take care of that in future.

Hey @vinzvinci
If everything is okay, please merge this PR.

There are conflicting files in this, can't merge yet.  Can anyone fix?

Hey @vinzvinci
I'm not able to resolve conflicts.
It shows me that you don't have write access.

@s2sharpit
You can resolve conflict using command line or GitHub Desktop

Image

Or, you can directly compare the code from your branch to the code in the existing repository.
The description of the conflict already specifies the files that you need to check.

Image

Sometimes, it's best to create a new pull request as solving the merge conflicts (especially when there are folder changes and such) might take more time than making a new, fresh pull request.

@s2sharpit  You better should sync latest change from this PR in order to resolve merge conflicts!
Waiting for the resolution, let me know if you need help. :wave:

Closing this PR. You can create new pr if u want!


Custom command prefix

I need to start command without prefix "/". Add possibility to api change CommandPrefix.

The default prefix gives auto-completion, but you must declare the commands statically with BotFather.
Do you need to support several prefixes, or just change the default prefix?
For the record, Could you provide more detailed information about your use case?

Thanks for your reply. I think i want support several prefixes.
In my case i have keyboard with two buttons "Office" and "Metro". When user push the "Office" button, telegram-client send text to bot "Office" and in your implementation of commands, bot not understand this command. I want have user-friendly buttons.
You can see it on my github: https://github.com/NKozlov/lanit-bus-bot/blob/master/src/main/scala/pro/nkozlov/telegram/bots/lanitbus/LanitBusBot.scala

The Commands interface is designed to support Telegram commands. Other libraries support different command prefixes but no prefix-less commands.
Prefix-less commands have a few disadvantages, e.g. if user types "Office" or "Metro" out of context, getting unexpected responses.
Prefix-less commands would make sense in an stateful workflow (e.g. BotFather) where the bot expect answers depending on the current state. This can be achieved using FSM actors.
Another way would be to use Inline buttons, which are part of a message (not a special keyboard).
Is possible to trigger commands from inline buttons. Since it's possible to edit messages, you can create interactive interfaces (try command /beers in EpflBot for an example).
Your solution is perfectly fine for your use case and I'm glad you could extend the library to fit your needs.

Don't close issue please =)
Thanks for your reply and suggestions about resolve of my case.
As i understand you right, in your client impossible create bot keyboard with user-friendly names? This is very strange, don't? I only ask to be given the opportunity to change default command prefix, if i want (one way is extend of class, another way is providing client-api).
Ok if i won't create inline buttons, i can extend your api and added my realisation. But in version 3.0.9 you change scope of method to private[telegrambot4s] and my code don't work with new version of client.

KeyboardButton allows to send custom keyboards but with the limitation that clicking the button is equivalent to write the button label/text as a message, this is a limitation of the Telegram API not the library. These buttons are more like a shortcut for canned predefined responses. e.g. Yes, No, 👍 👎, 1 to 5 star rating selection.
To create buttons with user-friendly labels use inline buttons which are more flexible, including callbacks (e.g. onClick handler). I've seen Sudokus and Tic-Tac-Toe games are implemented using inline buttons + EditMessage.
My point is that your use case is rather specific and can be achieved by implementing your own handler (maybe is not uber clean, but is doable). I would consider to support more prefixes (eg. % and #) alongside "/" but refuse to go prefix-less.
This is my attempt for your use case:
class TextBot(token: String) extends ExampleBot(token) with Polling with Commands {

  // Prefix-less commands.
  def onTextCommand(textCommand: String)(action: Action[Message]): Unit = {
    onMessage { implicit msg =>
      using(textTokens) {
        case Seq(cmd) if textCommand.equalsIgnoreCase(cmd) => action(msg)
        case _ =>
      }
    }
  }

  // Regular /command + prefix-less variant.
  def onTextCommand[T: ToCommand](command: T, textCommand: String)(action: Action[Message]): Unit = {
    onCommand(command)(action)
    onTextCommand(textCommand)(action)
  }

  // Common handler.
  def helloHandler(msg: Message): Unit = {
    reply("Hello World!")(msg)
  }

  // Separate.
  onTextCommand("Hello")(helloHandler)
  onCommand('hello)(helloHandler)

  // Combined.
  onTextCommand('beer, "Beer") {
    implicit msg =>
      reply("Beer!")
  }
}

thanks, man, for your opinion.
I know, that this is a limitation of the Telegram API not the library, i just talk about possibility of changing this behavior at the library level.
You suggest me the way to realise this feature in my project. It one of the way and i have it. Thank you for the proposed implementation. U can close issue, thanks man!


ads.txt

ads.txt is not act
https://eksiup.com/p/rx198851s4ju

Hi @D4rkkking
You got a 404 error because the current .htaccess bans the non-allowed txt files (and ads.txt wasn't allowed).
In order to avoid this kind of problem with txt files, I would suggest you to remove the |txt at the end. https://github.com/pH7Software/pH7-Social-Dating-CMS/blob/master/.htaccess#L46
Sorry for any inconveniences about it :)


feat: edit profile data

The ability to edit profile data should be implemented. The UI for this already exists in https://github.com/stephancill/opencast/blob/main/src/components/user/user-edit-profile.tsx
The appropriate message generation functionality needs to be implemented in this file https://github.com/stephancill/opencast/blob/f4e251fe4de7d1183fa8540f055029f4b5cf0aee/src/lib/farcaster/utils.ts
There is an example implementation of registering an fname here: https://github.com/wojtekwtf/farcaster-signup-demo
User data that should be editable:

Display name
Profile image
Bio
Username (fname/ENS)

Updating my profile picture does not work for me currently. I was expecting more when I paid for using the app, tbh.

@Michael-A-Heuer sorry you feel that way, contributions always welcome!


Error when using DATEPART function in a query

Example:
Extracting the week from a DATE field.
SELECT CAST(DATEPART(WEEK,[AN_DATE_FIELD]) AS VARCHAR) AS TEST FROM ANY_TABLE
Its causes error when is executed.
Here a JS solution for extract the week (but could be YEAR, etc):
Date.prototype.getWeek = function() {
   var onejan = new Date(this.getFullYear(), 0, 1);
   return Math.ceil((((this - onejan) / 86400000) + onejan.getDay() + 1) / 7);
}
Using:
(new Date()).getWeek()
Source: http://stackoverflow.com/questions/7765767/show-week-number-with-javascript

On msnodesqlv8 driver it works.
Tks and congrats!


Invariant Violation: Modal.render(): A valid React element (or null) must be returned. You may have returned undefined, an array or some other invalid object.

Summary:
Error occurred while returning Modal tag in React.
Steps to reproduce:

OptionModal.js
import React, { useEffect } from "react";
import Modal from "react-modal";

const OptionModal = (props) => {
return (

{/*
GeeksforGeeks
Modal Component in ReactJS? */}

GFG

);
};
export default OptionModal;

Call OptionModal from parent component

Dependencies:
"dependencies": {
"babel-cli": "6.24.1",
"babel-core": "6.25.0",
"babel-loader": "7.1.1",
"babel-plugin-transform-class-properties": "6.24.1",
"babel-preset-env": "1.5.2",
"babel-preset-react": "6.24.1",
"css-loader": "0.28.4",
"live-server": "^1.2.2",
"react": "18.3.1",
"react-dom": "18.3.1",
"react-modal": "^3.16.1",
"sass-loader": "10.1.1",
"style-loader": "0.18.2",
"validator": "13.12.0",
"webpack": "3.1.0",
"webpack-dev-server": "2.5.1"
}

Exception:
react-dom.js:17859  Uncaught Invariant Violation: Modal.render(): A valid React element (or null) must be returned. You may have returned undefined, an array or some other invalid object.
at invariant (https://unpkg.com/react-dom@15/dist/react-dom.js:17859:15)
at ReactCompositeComponentWrapper._renderValidatedComponent (https://unpkg.com/react-dom@15/dist/react-dom.js:5234:136)
at ReactCompositeComponentWrapper.performInitialMount (https://unpkg.com/react-dom@15/dist/react-dom.js:4765:30)
at ReactCompositeComponentWrapper.mountComponent (https://unpkg.com/react-dom@15/dist/react-dom.js:4661:21)
at Object.mountComponent (https://unpkg.com/react-dom@15/dist/react-dom.js:11409:35)
Could you please help here. Thanks in advance.
Expected behavior:
Link to example of issue:

Additional notes:

your code seems incomplete, can you please elaborate the issue


Update resource.cc

resolve memory leak.

Thanks for contribution! I have added you to https://github.com/dmlc/mxnet/blob/master/CONTRIBUTORS.md
Please feel free to make further changes about the information, and help everyone to make mxnet more usable and reliable


The docs site does not seem to be up to date

The docs site on https://sveltequery.vercel.app/ does not seem to be up to date. It seems that the content of the last three commits (since April 5, 2021) is not yet available on https://sveltequery.vercel.app/.
I have cleared the cache and also tried it with different browsers. Am I doing something wrong or does the documentation need to be released separately?

What are you specifically referring to?
This project is not a 1 == 1 porting from React.

I am aware that this is not a 1 == 1 porting from React. This issue is actually not referring to the React version. I just stumbled upon the fact that there are three commits in this repository in the docs folder since April 5, 2021 that are not yet visible on the docs site. Although there have been some releases since then. Two of the commits are actually from you (edaafe0 and 4c5971c). And the other (4417065) was about enabling/disabling queries reactively.
I just thought that these changes to the docs would be of interest to other people.

I'm sorry. I misunderstood.
I can't answer this question.


chore: Rename ObjectModel -> DocumentModel

Current dependencies on/for this PR:

main

PR #2442   👈

This comment was auto-generated by Graphite.


MessageBoxMessage should perform the callback

The HandleWith*() method for MessageBoxMessage is not performing the callback. It should behavior similar to other dialog type messages.

for 1.3.9


[FLINK-5624] Support tumbling window on streaming tables in the SQL API.

This is a POC to add tumbling window support for streaming tables in SQL.
Essentially it recognizes the LogicalWindow construct in Calcite and transform it to the LogicalWindowAggregate in flink.
Feedbacks are highly appreciated.

Hi @haohui, thanks for your contribution!
The referenced JIRA is about adding support for group windows to SQL, not OVER (or row) windows. It should enable queries such as:
SELECT a, sum(b) as sumB, TUMBLE_END(rowtime(), INTERVAL '1' HOUR) AS t,
  FROM myT
GROUP BY TUMBLE(rowtime(), INTERVAL '1' HOUR), a;

I saw that you contributed TUMBLE just very recently to Calcite, so this feature is not yet available in a Calcite release that we could link against. Until then, we could add support for the more manual version of SQL tumbling windows:
SELECT a, SUM(b) AS sumB, CEIL(rowtime() TO HOUR) AS t,
  FROM myT
GROUP BY CEIL(rowtime() TO HOUR), a

We would also need to find a way to reference the rowtime. We do not want to expose this as an actual attribute in Flink's SQL (internally, Flink treats record timestamps as metadata which may not be modified by a query). The current approach would be to implement a built-in function which serves as a marker and is replaced during the translation.
Best, Fabian

Updated the PR to recognize the GROUP BY clause instead of the OVER clause.

Adding ROWTIME() as an expression to enable users to specify event time windows.
After trying multiple approaches at the end I settled down with translating LogicalAggregate directly to DataStreamAggregate. The translation removes the group-by expression from the aggregate and adds the same expression as a window.
Note that ROWTIME() is actually translated to a call to the local timestamp. The expression has to be executable because Calcite creates a new project operator to compute the group-by expression, where the expression has to be executed. For example, the following query
SELECT COUNT(*) FROM table GROUP BY FLOOR(ROWTIME() TO HOUR)

will be translated to:
LogicalAggregate(group={$0}, agg={COUNT(*)})
  LogicalProject($0=FLOOR(ROWTIME() TO HOUR))
  ...

It's tempting to remove the group-by expression from the logical plan. However, it cannot be done using the optimization frameworks in Calcite. These frameworks expect the output types of the operators stay the same before and after the transformations. Removing the field actually changes the types thus Calcite will complain.
The down side of this approach is that it might be difficult for Flink to catch malformed queries such as SELECT COUNT(*) FROM table GROUP BY FLOOR(ROWTIME() / 2 TO HOUR) at compile-time. Any ideas to improve the situation?

The v3 PR gets the best from both of the worlds -- the code generator will throw exceptions if the queries actually execute the rowtime().
Essentially it rewrites the project and the aggregate operators before passing the operators into the Volcano planner. @fhueske please take another look.

Discussed with @fhueske offline. Thanks a lot for the comments. The V4 PR implements the following:

Rebased on top of #3101
LogicalWindowAggregateRule implements RelOptRule instead of the ConvertRule.
Instead of adding a new field in LogicalWindowAggregate, the implementation now transforms the original LogicalAggregate(LogicalProject()) expression to LogicalProject(LogicalWindowAggregate(LogicalProject(...))). The outermost projection ensures that the operators have the same row types before and after the transformation.

Please take another look.

Thanks for the update @haohui.
PR is good to merge.

Merging


halo should only be allowed for output axes with a size reference

we define halo on output axes, denoting the border region that may suffer from artifacts.
When tiling an input image and cropping the halo from the output it is essential to know how the output halo maps to the input tile stride (overlap). This is only possible if the output axis with halo has a SizeReference size to an input axis.
cc @k-dominik @buglakova @josh-talks

Not sure I get what the overlap would do here... All tiles should have the same halo to crop (or mask out for that matter). If you want to do any smoothing/blending (hence the lower than tile size stride) you have to do it yourself?
Halo: possibly invalid/erroneous region, should be removed (masked out, cropped).
Overlap: all valid, how to deal with stride smaller than tile, up to creativity of the user.

I really mean "stride" here. (I added "(overlap)" as an output tensor's halo that is cropped can only be stitched without gaps if input tiles overlap. (but I'm not considering overlapping inner output blocks here))

Hello. I'm still not sure what's the question but from my experience with different libraries I'd expect the following without checking the documentation:

tile shape: the size of the image that will be run through the network. Doesn't matter if it's all data or padded or filled in with some other values
overlap: value between 0 and 1 (or a vector if different overlap for different axes) meaning the percentage of the tile shape that will be predicted twice
stride: value in pixels meaning distance between centers of consecutive tiles
halo: value in pixels meaning part of the prediction within tile that will be zeroed out to remove edge artifacts

So overlap and stride are somewhat interchangeable while tile shape/stride/halo can be independent
Now I looked up and this is how Constantine explained what happens in this library:
ttttttttttttttttttttttttttttttttttttttttttttt
hhhh-------------------------------------hhhh
tttttttttttttt
----------hhhh
ssssssssssss
hhhh----------
So the overlap corresponds to 2 * halo, and the part of the halo that is closer to the tile is left.
So currently there's no averaging of predictions. Is that what you want to change?
Here is the sliding window prediction in Monai that I mentioned: https://docs.monai.io/en/stable/inferers.html#sliding-window-inference-function  It's a bit of a mess but it is an example of a much more flexible implementation

Thanks @Buglakova for this overview!
Adding tile averaging (and overlapping tiles) is left for the future (new issue in core: https://github.com/bioimage-io/core-bioimage-io-python/issues/373)


PyCharm autocompletion for properties

Due to the fact that the classes have dynamically generated fields for the AWS resource properties, IDEs like PyCharm doesn't suggest those fields during autocompletion.
For example:
from troposphere import Template, apigateway

t = Template()

apiResource = apigateway.Resource("contactcloud")
apiResource.ParentId #<-- won't be suggested by autocompletion!

This could be remedied in two ways:
1. Add type hints to the beginning of classes, e.g.:
class Resource(AWSObject):
    ParentId: basestring    # Python 3 type hints for fields
    PathPart: basestring
    RestApiId: basestring

    resource_type = "AWS::ApiGateway::Resource"

    props = {
        "ParentId": (basestring, True),
        "PathPart": (basestring, True),
        "RestApiId": (basestring, True)
    }

2. Generate stub files
This is outlined by PEP 484#stub-files

I've tried to implement alternative 1, which outputs classes like this:
class Resource(AWSObject):
    resource_type = "AWS::ApiGateway::Resource"

    ParentId = None # type: basestring
    PathPart = None # type: basestring
    RestApiId = None # type: basestring

    props = {
        'ParentId': (basestring, True),
        'PathPart': (basestring, True),
        'RestApiId': (basestring, True),
    }

The Problem now is that 2to3 completely ignores the type hints.
Maybe a better course of action would be to directly generate python 3 code and have that converted down to python 2?

Does the stub file approach work for both python2 and python3? Those likely could be autogenerated similar to the way I'm generating code from the resource specifications.

@markpeek The problem is that p2 and p3 have different syntax for type hinting (as in p2 doesn't really have one at all), so you can't use the exact same file for both. Conversion also seems to be out of the question.
Would having two extra scripts for generating p2/p3 stubs be an acceptable solution?

I've created a PR #1079

Any further comments on this? Does the PR need more work?

Sorry for the delay, I've been contemplating the right way to handle it. Here are some thoughts:

The main issue around python 2/3 is the use of basetype in troposphere. I'm debating making that more uniform by introducing a string_type based on the version of Python (similar to how six deals with it). This would be a broad change touching all of the files (best done by me in a single commit).
Really there should only be 1 generator script for both troposphere code and the autocompletion.
The autocompletion code should output both 2 and 3 into the same file since type checkers are supposed to honor version and platform checking. Question: does PyCharm support this?
The autocompletion code could be emitted during packaging rather than checking in these files. Need to think more about which is better.

This is tricky. Using an abstraction class like that would in my opinion be counter intuitive, as it would show up as 'string_type' in the method signature. This is just a beauty-problem though.
I'll try to get that done by sunday.
Neat, I didn't know that. Pycharm does support it. (Also just tested it)
You could argue that the code should also be emitted during packaging then. I think it's more obvious where it came from if it's also committed.

Cheers for the feedback!

Changes are done. See PR #1079

Any update on this?
Would really love avoiding the cmd click for props everytime.

I looked at it today and I think we need to make a few changes. I'll follow up in PR #1079. But I hope to get it merged and then fix it up real soon to get it out.

I saw the pr has already been merged, but I don't get autocompletion. Do I need to do something else? I tried searching the docs but couldn't find anything. Thanks!

The generator was merged, but sadly the generated files never were added to the repo/package.

Are there any plans to add those files to the package? In the meantime I'll see if I can generate them myself and have PyCharm detect the stub files. Thanks!

That is up to @markpeek ! I'd love to see my labour bear fruit :)

@DrLuke , @xyvark , @grkking, @markpeek
Please take a look at my project https://github.com/MacHu-GWU/troposphere_mate-project
It built a thin wrapper layer on top of troposphere using attrs. It is exactly the pythonic implementation with nicer API. And type hint is enabled with type hint markup described https://www.jetbrains.com/help/pycharm/type-hinting-in-product.html.
And it comes with a feature called auto-reference/associate. You don't need to remember the detailed properties and the reference syntax to reference each other, you just use this, it automatically does the work for you:
associate(lambda_func, iam_role)
associate(lambda_func, subnet1)
associate(lambda_func, subnet2)
associate(lambda_func, security_group)

So it gives you auto suggestions on type and properties name.

If my works are helpful, I am happy to see you star my project :)

Thank you @MacHu-GWU

Check how Pydantic does this. It does validation with type hints alone. Also, you get autocomplete in constructor keyword arguments with "pydantic" PyCharm plugin
https://pydantic-docs.helpmanual.io/usage/models/

So Troposphere no longer supports Python 2, this makes this problem easier right now.

I have a bit of time through the end of this year that I can put towards some work on implementing this if we can decide on a path forward.
I put together a PoC rewriting troposphere.__init__ to use pydantic models as the base class for Template and BaseAWSObject with the goal of making as few changes as possible. I rewrote 2 simple cloudformation resource classes to use this new format to give an idea of how they will look/function. The project can be found here: https://github.com/ITProKyle/troposphere-pydantic. It also includes an example template to show usage.
So far, the biggest breaking change I see for this route would be title & template arguments are no longer positional and must be provided as keyword arguments.
The least effort path forward if this route is chosen would likely be to manually update all classes to use the new format. We can then look to automatically build the classes using jinjia as a future step unless someone else has some time in the next few weeks to get that started as it may burn too much of the time I have available right now to figure out.
Open to any suggestions/feedback on my PoC. I'll hold off on working on it further until a maintainer chimes on.

@ITProKyle there's spec files that AWS maintain that regularly with all resource, property information. I joined AWS and create a AWS internal open source project that automatically keep the Resource model class up-to-date along with the spec file.
https://cottonformation.readthedocs.io/en/latest/
You can easily access "Required Property", "Optional Property", "Return Value" with built-in type hint.

@ITProKyle Yeah, this is neat (cottonformation) and will be useful to pull the schemas with it.
User feedback though on cottonformation->  the problem and typically the reason why I really dislike CDK as well is, you renamed every single attribute from the CFN properties -> rp_AssumeRolePolicyDocument instead of simply AssumeRolePolicyDocument breaks the integration that is in Troposphere today which makes it so easy to import CFN resources and get them as pyhon objects. Is there a particular reason for the properties to have been renamed and have rp_ prefixed to it?

@JohnPreston yes.

@JohnPreston yes.
In my experience, it fully leverages the power of modern IDE, this free you from looking up documents and allow you to focus on logic.

I get that. But my point is one cannot then just import property name for propety name. The renaming of the attributes although with sense. With troposphere following the names of properties strictly and yes still be able to define validation and required/optional works just fine.
And as a CFN engineer you should know that the required / not required is not enough at all to illustrate whether or not two options are compatible.
In my experience, reading the docs saves kittens. And there is no shortcut for it, however hard you try

@JohnPreston I totally agree with you. Type prefix like rp_ and `p_`` are really annoying to CFN engineer. But Python is a dynamic type language. This enables before-runtime check in IDE if you write the wrong code.
My initiative is to allow low experienced engineer to be able to develop CFT easier with less learning curve. And the trade off is to use magic prefix _ to trigger the auto complete and hint. I have to admit that it is not perfect though :)

You don't need those prefixes for IDE support, see e.g. PyCharm Pydantic plugin

@MacHu-GWU - Just want to echo the feedback that everyone else has provided. Changing the names of the properties kills its usability for me and my teams. I get that you are trying to differentiate required vs optional parameters but the appropriate way to do that would be by making the type annotation of the property Optional[type] not by changing the documented names of the properties. This is something that all modern IDEs display and provide feedback for before runtime (type checkers like pyright can also be used). I my opinion and that of other I work with, changing the names of the properties adds more complexity especially for the "low experience engineers" you are targeting.
That's not to say cottonformation isn't a nice library. It's just not a replacement for Troposphere for a company with hundreds of Troposphere templates (which would take a significant amount of time to update EVERY property) and is not a solution to this problem.

I've been busy but keeping an eye on this thread. Here's some comments:

First off, I will be making a series of changes to the layout of troposphere to keep backward compatibility but move the validators into a separate directory. This is needed to allow better code generation from the resource specification file.
With the generator changes for the above, I will get the stub files generated (thanks @DrLuke) alongside the code files.
In looking at the stub files it appears to allow for matching the parameters but not the types. This appears due to the use of kwargs in troposphere and there isn't a great solution for typing on each kwarg.
In this I want to move incrementally and preserve as much backward compatibly as possible, given the amount of existing code in production, while improving the ease of use.
I will have to look harder at pydantic but initially I'm not a fan of the "title" change. Also, it seems PyCharms has a pydantic module but I don't believe VS Code has one so there is still a gap.

Anyway, wanted to provide a quick update from my viewpoint. The key for me is to rely more on the generator to keep the library up to date with the resource spec, ensure reproducible results (due to renames that are required), and to generate the corresponding stubs accurately.

To expand on what @ITProKyle said and to give my 2cts on the whole pydantic story:
I got introduced to pydantic mostly from those convos, and went off, created projects where I would laze off using the JSON schema to deal with creating my classes just because it feels then easy to just deal with objects and there properties instead of dealing with dictionaries / lists etc. Very cool, very familiar to using the CFN CLI tool to create resources/modules.
However, although I find the principle of generating the Troposphere properties from the JSON schema exposed by AWS CFN sounds amazing, I think that moving from the current object model which is superbly easy to read and understand, moving to auto-generated classes, even with the ability to override the Base class, feels like a giant step back and would break so much code logic that has been implemented so far.
I rely on the current structure of troposphere (i.e issubclass(x, y) so much that I would publish my own fork version of troposphere to Pypi to keep compatibility of the current model going.
Plus the logic to go over a root AWS Resource down to its nested AWS Property is fairly straightforward. I might have already mentioned that, with the current model, you can pass a whole AWS Resource from an existing template and get its Troposphere version in a flash. For my usage, the compatibility is such that I can take the example for a given resource type from the AWS docs, and it works without a miss (modulo Intrinsic functions)
Where I do like what cottonformation does for example, which I implemented my own way for my own purpose, is providing a way to know what the valid return values are (from Ref / GetAtt etc.) but that is then again something that is fairly straightforward to implement.
So, in my opinion, going the pydantic way instead of good old **kwargs is going to be a nightmare for anyone using Troposphere as a pure library.
However, for the use of the JSON definition of the CFN resources as exposed by the CFN team, I would much rather see using that purely as a json schema validation in the validate() process
If for example we had a python library with all the CFN schemas in there (probably would be huge, but pydantic is not light anyway) we could use that as source for jsonschemas validation very easily.
To your point @markpeek the one advantage I see with the generator is to avoid human error (which I know I did in one of my PRs) but I find the community has been pretty great at doing just that. So if we combined JSON validation from the CFN official models to validating PR changes we could be keeping up with the changes very fast and very nicely with a high grade of confidence.
Thanks for reading. Go Troposhere!

@MacHu-GWU - Just want to echo the feedback that everyone else has provided. Changing the names of the properties kills its usability for me and my teams. I get that you are trying to differentiate required vs optional parameters but the appropriate way to do that would be by making the type annotation of the property Optional[type] not by changing the documented names of the properties. This is something that all modern IDEs display and provide feedback for before runtime (type checkers like pyright can also be used). I my opinion and that of other I work with, changing the names of the properties adds more complexity especially for the "low experience engineers" you are targeting.

Thank you for the feedback! Great to hear different sounds with very solid reasons.

On the topic of validators, there's much less need for maintaining basic validation functions with the use of pydantic as its all done automatically by the library. It even handles converting a dict into an object if the user wants to provide a dict instead.

...appears due to the use of kwargs in troposphere and there isn't a great solution for typing on each kwarg

Adding types for kwargs is quite easy but i'm not sure how we would go about auto-generating them for troposphere stubs. To it it, it would require changing to **kwargs to something like **, Kwag1: str, Kwarg2: Optional[str] = None for each property where Kwarg1 is required and Kwarg2 is optional. (PEP 3102)

I will have to look harder at pydantic but initially I'm not a fan of the "title" change. Also, it seems PyCharms has a pydantic module but I don't believe VS Code has one so there is still a gap.

The "title" change is partially pydantic and partially a new PEP being worked on to unify how type checkers treat custom classes that work like dataclasses (discussion).
The __init__ method of a pydantic model can be overwritten to accept "title" as a positional argument but it would break the native autocomplete support provided by the PEP being drafted as it would no longer work like a dataclass. I can't say im particularly happy about this change either, specificity when supplying arguments  is never a bad thing. There is also precedence baked into python for instantiating objects using only explicit kwargs (dataclasses).
As for vscode support, it is supported natively with the next release of pydantic (currently available from the master branch) which implements the PEP being worked on by pyright. Pyright/pylance is use by default by vscode's python extension.

I rely on the current structure of troposphere (i.e issubclass(x, y) so much that I would publish my own fork version of troposphere to Pypi to keep compatibility of the current model going.

This is something that would remain viable through the use of pydantic. Looking at my PoC, the only base classes being changes is that of the troposphere.BaseAWSObject and troposphere.Template from object to pydantic.BaseModel. All other classes would have the same exact base classes.

So, in my opinion, going the pydantic way instead of good old **kwargs is going to be a nightmare for anyone using Troposphere as a pure library.

How would it be a nightmare? It would work exactly the same but actually define the kwargs it wants instead of letting the user guess what it wants. **kwargs is great for low effort code to just get something working but it's a horrible user experience to not have explicitly defined keyword arguments.

As nice as it would be from a maintainer standpoint to have troposphere auto-generated from the CFN spec, it adds little value to the end user for the large time investment it will require. Not to say that it doesn't need done - there are just more impactful projects for the users of troposphere such as this one.
A possible stopgap solution would be to validate troposphere against the CFN spec instead of generating from it. For example - for each resource in the spec, check to ensure that a class exists and that it's properties match. This would ensure that troposphere matches the spec (at least loosely) now and that it continues to match the spec as full auto-generation is worked towards.

How would it be a nightmare? It would work exactly the same but actually define the kwargs it wants instead of letting the user guess what it wants. **kwargs is great for low effort code to just get something working but it's a horrible user experience to not have explicitly defined keyword arguments.

Sorry I was mistaken when wrote this. That's why I should not be doing this at 1AM (and yet I am replying at 2AM  ^^).
I meant the way the props are declared, not the way one can use of **kwargs already in current model or with pydantic.
I really disagree on the point around that passing kwargs vs defined keywords would make user life easier: there is no shortcut to reading the docs and knowing / learning which parameters do what.
Typically, nothing will ever be good enough at educating people on the importance of Update requires: <nothing|replacement> Hint typing will not tell people whether this is a good thing or not to do. No lib (CDK/cottonformation/troposphere) can teach experience.
The best we can do is implement the heck of of validators for resources that we know have incompatible properties and that sort of things (I will admit I have quite a few to backport from other project into this one).
Validators generated from the JSON definition of the CFN resources into pydantic objects, as well, won't quite be able to do more than what JSON conditions allow do define/expect. And unless we can open PRs to CFN to improve as much as possible validation logic in the Schema definitions, it will always come down to "us" to implement these in code.
Now, I might be missing something in what's been done so far to go the pydantic way and such, and I am more than happy to take a fork/branch that uses that new model for a spin to validate on backward compatibility.
But if all this is only just to help users with a better IDE "help" experience and the way to do that is to change the whole classes model, we are trying to fix something that really needs no fixing at all and just works.
The major advantage of troposphere vs cdk etc. is that the properties names are identical to the name in the docs, leaving no room for confusion for people who do RTFM.

A possible stopgap solution would be to validate troposphere against the CFN spec instead of generating from it. For example - for each resource in the spec, check to ensure that a class exists and that it's properties match. This would ensure that troposphere matches the spec (at least loosely) now and that it continues to match the spec as full auto-generation is worked towards.

Can't agree more. I think that validation against the model when troposphere performs the render to_dict() of the objects instead of trying to generate these from the schema definition is much easier, and requires a ton less work.

As nice as it would be from a maintainer standpoint to have troposphere auto-generated from the CFN spec, it adds little value to the end user for the large time investment it will require. Not to say that it doesn't need done - there are just more impactful projects for the users of troposphere such as this one.

Again, can't agree more. I'd volounteer to go over each AWSProperty in the code to add the links to the docs in CFN for people to relate to it (i.e as in here) if that gives that shortcut for users to open the definition by clicking on it from the IDE.
Which actually brings me to a question/suggestion: should we look into defining a docstring standard format ?

Per my above comments, I pushed some updates to the code generator along with changes to a few classes to prove it out. @JohnPreston this also includes adding doc links to the generated classes. There is an update to the CONTRIBUTING doc to attempt to document the changes needed to each class. @DrLuke the code generator should produce corresponding stub files (manually) if you want to verify it. I'm just doing file redirection at this time as I need to verify correctness and backward compatibility. Here are the simple shell aliases I've been using:
gen () {
  name=${1:none}
  python3 scripts/gen.py --name $name CloudFormationResourceSpecification.json
}

stub () {
  name=${1:none}
  python3 scripts/gen.py --stub --name $name CloudFormationResourceSpecification.json
}

Not sure if this is related. But just in case. Just pulled from the main branch and installed in my venv and just realized, S3/ECR and a few other resources have code auto-generated. And yes, it looks slick to have the docs stings to the resource etc. and very happy to see that the props / resource_type are still here etc.
@markpeek  please see https://github.com/cloudtools/troposphere/pull/1995 to fix import issues though :)


Dev - move binpack result data from cart/order metadata to cso metadata

This data should belong to the custom shipping option (cso_) object.
Lets leave the cart/order alone aside from just adding the cso_id's to their metadata

data moved to cso metadata with references to the cso's via ids in the cart/order metadata


bug: child projects question is asked even when provided with the config file

Describe the bug
When transforming a dot net core app with move2kube.
When provided the m2kconfig.yaml file from a previous transformation, it still asks the select child projects question again.
To Reproduce
Steps to reproduce the behavior:

Transform a dot net core app
Use the same config file to transform again

ibm-macbook-pro:t11 user$ move2kube transform -s src/ --config old/m2kconfig.yaml
INFO[0000] Configuration loading done
INFO[0000] Start planning
INFO[0000] Planning started on the base directory
INFO[0000] [CloudFoundry] Planning
INFO[0000] [CloudFoundry] Done
INFO[0000] [ComposeAnalyser] Planning
INFO[0000] [ComposeAnalyser] Done
INFO[0000] [DockerfileDetector] Planning
INFO[0005] [DockerfileDetector] Done
INFO[0005] [Base Directory] Identified 0 named services and 0 to-be-named services
INFO[0005] Planning finished on the base directory
INFO[0005] Planning started on its sub directories
INFO[0005] Identified 1 named services and 0 to-be-named services in .
INFO[0005] Planning finished on its sub directories
INFO[0005] [Directory Walk] Identified 1 named services and 0 to-be-named services
INFO[0005] [Named Services] Identified 1 named services
INFO[0005] Planning done
INFO[0005] No of services identified : 1
INFO[0005] Starting transformation
INFO[0005] Iteration 1
INFO[0005] Iteration 2 - 1 artifacts to process
INFO[0005] Transformer DotNetCore-Dockerfile processing 1 artifacts
? For the multi-project Dot Net Core app 'eShop', please select all the child projects that should be run as services in the cluster:
ID: move2kube.services."eShop".childProjects.[].enable
Hints:
- deselect any child project that should not be run (example: libraries)

  [Use arrows to move, space to select, <right> to all, <left> to none, type to filter]
> [✓]  eShop.Web
  [✓]  eShop.WebApi

Expected behavior
The question should not be asked again
Version
version: v0.3.0+unreleased
gitCommit: e81744452c3c90f3fd00897879b736eef7765cd4
gitTreeState: clean
goVersion: go1.18.1
platform: darwin/amd64

Additional context
Found by @binypanackal
The config file
move2kube:
  containerruntime: docker
  minreplicas: "2"
  services:
    eShop:
      childProjects:
        eShop.Web:
          enable: true
          ports:
            - "51047"
            - "51048"
        eShop.WebApi:
          enable: true
          ports:
            - "51044"
      dockerfileType: build stage in base image
      enable: true
    eshop-web:
      "51047":
        servicetype: Ingress
        urlpath: /eshop-web
      "51048":
        servicetype: Ingress
        urlpath: /eshop-web
    eshop-webapi:
      "51044":
        servicetype: Ingress
        urlpath: /eshop-webapi
  target:
    default:
      clustertype: Kubernetes
      ingress:
        host: myproject.com
        ingressclassname: ""
        tls: ""
    imageregistry:
      namespace: myproject
      quay.io:
        logintype: use the credentials from the docker config.json file
      url: quay.io
  transformers:
    types:
      - ArgoCD
      - Buildconfig
      - CloudFoundry
      - ClusterSelector
      - ComposeAnalyser
      - ComposeGenerator
      - ContainerImagesPushScriptGenerator
      - DockerfileDetector
      - DockerfileImageBuildScript
      - DockerfileParser
      - DotNetCore-Dockerfile
      - EarAnalyser
      - EarRouter
      - Golang-Dockerfile
      - Gradle
      - Jar
      - Jboss
      - Knative
      - Kubernetes
      - KubernetesVersionChanger
      - Liberty
      - Maven
      - Nodejs-Dockerfile
      - PHP-Dockerfile
      - Parameterizer
      - Python-Dockerfile
      - ReadMeGenerator
      - Ruby-Dockerfile
      - Rust-Dockerfile
      - Tekton
      - Tomcat
      - WarAnalyser
      - WarRouter
      - WinConsoleApp-Dockerfile
      - WinSLWebApp-Dockerfile
      - WinWebApp-Dockerfile
      - ZuulAnalyser
  transformerselector: ""

Caused by sub keys with special characters being used without quoting.
INFO[0000] No of services identified : 1
INFO[0000] Starting transformation
ERRO[0000] DEBUG BEFORE k: 'eShop'
ERRO[0000] DEBUG AFTER newK: 'move2kube.services.eShop.enable'
INFO[0000] Using the transformation option 'WinWebApp-Dockerfile' for the service 'eShop'.
INFO[0000] Iteration 1
INFO[0000] Iteration 2 - 1 artifacts to process
INFO[0000] Transformer WinWebApp-Dockerfile processing 1 artifacts
ERRO[0000] DEBUG BEFORE k: 'eShop.Web'
ERRO[0000] DEBUG AFTER newK: 'move2kube.services.eShop.childProjects.eShop.Web.enable'
ERRO[0000] DEBUG BEFORE k: 'eShop.WebApi'
ERRO[0000] DEBUG AFTER newK: 'move2kube.services.eShop.childProjects.eShop.WebApi.enable'


Complie Error Description	Resource	Path	Location	Type GoogleAPIClientToken cannot be resolved to a variable

I do step by step from https://desktop.jitsi.org/Documentation/ConfigureEclipseNew
When I complie It's show  Error: Could not find or load main class net.java.sip.communicator.launcher.SIPCommunicator  and
GoogleAPIClientToken cannot be resolved to a variable
How can I fix it or I have something wrong?
PS. I import google-api-client-1.6.0-beta.jar  to lib of jitsi project
and build ant clean I build in eclipse.

@jojoth so it happens when you run maven make target?


Screenshot/GIF preview broken

The location of the website has changed, which has resulted in GIF preview being broken in the readme.
Very low priority for now.

Fixed.


[AMLII-1994] Improve expected_tags_duration for metrics

What does this PR do?
Fixes configurable host tags that are added to metrics expected_tags_duration is configured.
This PR changes the logic for adding host tags and moves it after aggregation occurs so that a metric's context hash does not change and the aggregator does not mistake the same metric as a new one.
Motivation
Issue
Describe how to test/QA your changes
To verify that configurable host tags work as expected

Add the following settings to datadog.yaml

tags: "foo:bar"
expected_tags_duration: 1m
log_level: 'debug'
log_payloads: true

Start the agent, and tail the logs.
grep for tags foo:bar
For the first ~1m of the agent running you should see foo:bar tags on every metric logged in the payloads.
After ~1m passes, you should no longer see these tags.

To verify that the bug was resolved

Use the same datadog.yaml settings as before
Create a test file
dev/dist/checks.d/testcheck.py
Inside the file, configure the following check

from datadog_checks.base import AgentCheck

class ServerCheck(AgentCheck):
    inc = 0

    def check(self, instance):
        ServerCheck.inc += 100
        self.monotonic_count('brian.test.check.count', ServerCheck.inc, flush_first_value=True)

Run the agent then the check
Verify that a spike does not occur in 1m, here is how the spike used to look

QA steps are also given in the ticket
Additional Notes
I've benchmarked these changes with dogstatsd stress tests and displayed the results in this document.
Notebook
RSS pod memory usage
Old host tag feature:

Tags enabled: 237M average
Tags disabled: 228M average

New host tag feature:

Tags enabled: 229M average
Tags disabled 224M average

CPU usage
Old host tag feature

Tags enabled: 1.18 cores average
Tags disabled: 1.15 cores average

New host tag feature

Tags enabled: 1.16 cores average
Tags disabled: 1.11 cores average

Results:
3.7 % reduction in memory usage when tags are enabled while using the new host tag feature
1.8 % reduction in memory usage when tags are disabled while using the new host tag feature
1.7 % reduction in average cores used when tags are enabled while using the new host tag feature
3.5 % reduction in average cores used when tags are disabled while using the new host tag feature
The old version also has a CPU drop when the host tags expire which the new version does not have.

NIT: Can we change the title to something like: "Improve expected_tags_duration for metrics`

/merge


Fix conflicting types in esp_aes_xts_setkey_enc et al., causing build errors

Building without hw accelerated AES encryption generates build errors similar to this:
CC build/esp32/hwcrypto/aes.o
/home/esp-idf/components/esp32/hwcrypto/aes.c:434:5: error: conflicting types for 'esp_aes_xts_setkey_enc'
 int esp_aes_xts_setkey_enc( mbedtls_aes_xts_context *ctx,
     ^
In file included from /home/esp-idf/components/esp32/hwcrypto/aes.c:30:0:
/home/esp-idf/components/esp32/include/hwcrypto/aes.h:280:5: note: previous declaration of 'esp_aes_xts_setkey_enc' was here
 int esp_aes_xts_setkey_enc( esp_aes_xts_context *ctx,
...

Steps to reproduce:

Enter any exampel applications (e.g. examples/wifi/scan)
Run make menuconfig
Disable "Enable hardware accelerated AES encryption" (Component config -> mbedTLS)
Save and exit
Run make

This is a problem with the current v3.1.1 release.

@lanker Thanks for this PR but fix for this issue was already in our internal queue, now merged with https://github.com/espressif/esp-idf/commit/761d44bd365d011a05200b7c20001186293521f3

I'm still having this issue in the 3.1 release branch latest commit. Did 761d44b ever get merged into the 3.1 release branch?

@eagi223
Merged in 3.1 release with https://github.com/espressif/esp-idf/commit/76f98a4b36aca8146dad591272472cc0a959b3d1


[html5] Merge dev into html5-feature-0.5 and fix the conflicts

Fix the conflicts in #1556 . It can be squash merge into html5-feature-0.5.


Missing AppKit Framework

is there any roadmap to provide AppKit? I have seen it is part of the Cocotron project, therefore it shouldn't be to big effort to put in the WinObjc package. As far as I understand a huge portion of the iOS layer is taken from there.

AppKit support is not in the pipeline.

Ok, thanks for your feedback.


feat(ThemeProvider): add dark, light alias for ThemeProvider

Closes https://github.com/github/primer/issues/919
Update ThemeProvider's ColorMode to accept dark and light as aliases for night and day. Let me know if I missed any branches here that could be seeing dark or light as colorMode, was trying to following along in the source code but could easily have missed a path 👀
Question for reviewers
What would be the best way to test this in ThemeProvider.test.tsx? 👀

What would be the best way to test this in ThemeProvider.test.tsx? 👀

Maybe copy and paste these test cases and replace day/night with light/dark:
https://github.com/primer/react/blob/main/src/__tests__/ThemeProvider.test.tsx#L119-L137

@colebemis love it, done!


Match code condition names to new names

We're calling conditions "joint" and "individual" now. For readabilty of code, these conditions should be called this in the code as well.

need to change these in the analyses, too @JMankewitz


Add RPC method to get Storage Nonce Public Key

Is your feature request related to a problem?
No response
Describe the solution you'd like
Implement https://github.com/archethic-foundation/archethic-wallet/issues/769
Additional context
No response
Epic
No response

canceled


Task queue priority should be based on file importance

At the moment, it seems like the task queue order is kinda random:
2023-10-07 16:12:12,329 Processing chunk <FileChunk tests/functional/dashboard/test_category.py 28>...
2023-10-07 16:12:12,733 Handling task: analyze_chunk
2023-10-07 16:12:12,733 Note, 25086 tasks left in the queue.
2023-10-07 16:12:12,733 Processing chunk <FileChunk src/oscar/apps/order/migrations/0001_initial.py 314>...
2023-10-07 16:12:13,095 Handling task: analyze_chunk
2023-10-07 16:12:13,095 Note, 25085 tasks left in the queue.
2023-10-07 16:12:13,096 Processing chunk <FileChunk src/oscar/apps/order/migrations/0001_initial.py 302>...
2023-10-07 16:12:13,562 Handling task: analyze_chunk
2023-10-07 16:12:13,562 Note, 25084 tasks left in the queue.
2023-10-07 16:12:13,562 Processing chunk <FileChunk src/oscar/apps/payment/abstract_models.py 318>...
2023-10-07 16:12:13,889 Handling task: analyze_chunk
2023-10-07 16:12:13,890 Note, 25083 tasks left in the queue.
2023-10-07 16:12:13,890 Processing chunk <FileChunk src/oscar/apps/customer/alerts/utils.py 117>...
2023-10-07 16:12:14,185 Handling task: analyze_chunk
2023-10-07 16:12:14,185 Note, 25082 tasks left in the queue.
2023-10-07 16:12:14,185 Processing chunk <FileChunk tests/functional/customer/test_order_status.py 6>...

Instead it should be based on the importance of the file, because we want to process the most important files in the repo first!
This is the code where these tasks are added to the queue:
https://github.com/kantord/SeaGOAT/blob/3c0d9279c33384c2cde77f327e8b85f26e2ea5db/seagoat/queue/task_queue.py#L74-L77
remaining_chunks_to_analyze already returns the chunks in the correct order, but as you can see, all of these tasks are added using priority=LOW_PRIORITY. This queue used to be a FIFO queue, so tasks were processed in the correct order by default. However now they are processed in a random order.
Existing priorities are defined here:
https://github.com/kantord/SeaGOAT/blob/3c0d9279c33384c2cde77f327e8b85f26e2ea5db/seagoat/queue/base_queue.py#L12-L13
We could probably introduce a medium priority like this:
HIGH_PRIORITY = 0
+MEDIUM_PRIORITY = 0.5
LOW_PRIORITY = 1

Then we could make sure that each task is added with the correct priority. For example. if we have 6 tasks, they could be added with the following priorities:

0.5, 0.6, 0.7, 0.8, 0.9, 1.0

So somehow if we have X tasks, the formula could be something like (pseudo code!)
priority(task_index) => MEDIUM_PRIORITY + ((LOW_PRIORITY - MEDIUM_PRIORITY) / len(X) * task_index)

I guess the code that adds the tasks will change something like this (pseudo code):]
 for task_id, chunk in enumerate(remaining_chunks_to_analyze):
     # write actual formula, this is untested 👇
     priority = MEDIUM_PRIORITY + ((LOW_PRIORITY - MEDIUM_PRIORITY) / len(X) * task_index)
     self.enqueue(
         "analyze_chunk", chunk, priority=priority, wait_for_result=False
     )

It is also important to write a test that verifies this behavior. The test should fail with the current implementation There are different potential approaches to testing this, but maybe the easiest way is to basically copy paste this test:
https://github.com/kantord/SeaGOAT/blob/3c0d9279c33384c2cde77f327e8b85f26e2ea5db/tests/test_server.py#L74-L94
then get the list of files not analyzed yet. That can be done by easily by creating a new Engine object in the same repo and checking the chunks_not_yet_analyzed value. Code example:
my_engine = Engine(repo_with_more_files.working_dir)
list_of_chunks_not_cached = my_engine.cache["chunks_not_yet_analyzed"]
all_vector_embeddings = my_engine._create_vector_embeddings()
top_files = list(my_engine.repository.top_files())

files_not_yet_analyzed = { chunk.path for chunk in all_vector_embeddings if chunk.id in list_of_chunks_not_cached }

Then you can make an assertion to make sure that the files that are not analyzed yet are the files that are least important (i. e. they are at the end of the top_files list):
assert {file['path'] for file in top_files[-len(files_not_yet_analyzed):]} == files_not_yet_analyzed

Hi is this open for contribution?

Hi @agnes-sharan yes, absolutely, go for it!

also if you get stuck or need some info, feel free to schedule a call with me https://calendly.com/kantord/30-minute-call

Hi! I would like to work on this issue.

Hi @kantord
I have generated the PR pls check it, and let me know if any changes are needed.
waiting for your reply.


Background: literature references

https://music-encoding.org/resources/background.html refers to some literature without giving full refereces. @pe-ro could you have a look, as probably the text goes back to some of your early texts on MEI?

It's actually one reference, the one to Maxwell 1981

I wrote this bit -- The reference is:
Maxwell, J.T. 1981. Mockingbird: An interactive composer's aid. M.S. thesis,  Dept. of Electrical Engineering and Computer Science, Massachusetts Institute of Technology.
http://dspace.mit.edu/handle/1721.1/15893

Thanks for checking on this, @bwbohl. I felt conflicted about just removing it and was planning on emailing Perry. An issue was a better solution. I will make the changes today.
I guess I should not include this source in the "Selected Bibliography" because this is not a source talking about MEI. So, instead, I could add a section at the end of "Background" (where this reference appears) to include all references. Sounds like a good solution? Or just add the link where the reference to Maxwell appears?
Thanks again, @bwbohl! And thanks for providing the full reference, @ahankinson!

Solved in PR https://github.com/music-encoding/music-encoding.github.io/pull/134

thanks to both of you!
@martha-thomae  I think it's a good idea to also include a section with all references at the end of the "Background" page. Nevertheless I like your idea in adding it to some structured bibliography… we should come up with some concept, e.g. a  reading list for background matter


Support loading multiple indexed read files

#732 added support for using index files to load a subset of a single BAM file. We should generalize this to allow parallel loads from multiple BAM files.

@fnothaft quick question about this and whether or not I should make a new issue: would this allow me to supply a tumor bam file and a normal bam file (seperate files) into avocado? One really nice thing you can do with GATK that I would really want here as a minor addition, is to pass a user supplied tag associated with the multiple input files that get appended to the reads. For example in GATK (and mutect) you can do this, which allows for my desired usage pattern:
[some args and other things] ... \
--input:normal some_file_normal.bam \
--input:tumor some_file_tumor_1.bam \
--input:tumor some_file_tumor_2.bam \
[other args] ...\

So you can see the same tags could be given to multiple files. Mutect treats the entire pool of files labeled tumor as a big tumor sample for the purpose of generating the noise file which is used to filter downstream sites (when they are not also cosmic sites).
It would be super lame if we had to first combine all bam files into a single file to do that analysis.
Anyhow let me know if I should make the labeling thing above a separate issue, or if that is ok to be appended to this issue?

Closing as dupe of #993


Update sources-dist.json with adapter powerfox2

RE-CHECK!

Automated adapter checker
ioBroker.powerfox2

[ ] :heavy_exclamation_mark: [E019] Invalid repository URL: https://github.com/ax-led/ioBroker.powerfox2. Expected: git+https://github.com/Ax-LED/ioBroker.powerfox2.git
[ ] :eyes: [W400] Cannot find "powerfox2" in latest repository

Add comment "RE-CHECK!" to start check anew

what do i have to do? And where do i have to do it?
Thanks in advance.
Regards
AxLED

RE-CHECK!

Automated adapter checker
ioBroker.powerfox2

[ ] :heavy_exclamation_mark: [E019] Invalid repository URL: https://github.com/ax-led/ioBroker.powerfox2.git. Expected: git+https://github.com/Ax-LED/ioBroker.powerfox2.git
[ ] :eyes: [W400] Cannot find "powerfox2" in latest repository

Add comment "RE-CHECK!" to start check anew


pseudo-class arguments should not be quoted

Hello! Sorry for the late response. Could you please add a test?

Fixed.


63012 move functions to scheduler, disable cover due to error

rep_state/1, find_jobs_by_dbname/1, find_jobs_by_doc/2 - moved to scheduler
Added tests to couch_replicator_doc_processor.  Noticed we still wrote replication_id for duplicate docs back to the document, removed that.
Added tests to doc processor to make sure it still works after functions moved to scheduler and after removing replication_id write-back to docs.
Tests seemed to have triggered a bug in cover and in module loading test. Module loading test fixed but cover disabled for now (to at least have tests running).
Upstream OTP issue which seems to be related:
https://github.com/erlang/otp/pull/885

+1. shame we lose cover, though.


Mandatory Attributes

The latest UML2YANG tool will include mandatory substatement to attributes that has "Multiplicity 1 + no default values defined".
The following attributes which are formerly optional will be changed to mandatory in the upcoming YANG.
Further , if an attribute is decided to be optional , we shall handle it in the UML modelling by either introducing a default value or by modifying the Multiplicity to 0..1.

S.No
Grouping/Datatype
Attribute
Mandatory
Optional

1
object-creation-notification
object-id-ref

2
object-deletion-notification
object-id-ref

3
attribute-value-changed-notification
object-id-ref

4
current-performance
granularity-period

5
historical-performance
granularity-period

6

period-end-time

7
g-826-threshold-cross-alarm-type
g-826-value-kind

8

granularity-period

9
segment-status-type
segment-status-type-id

Proposal to the 5G-xhaul call on 6th of September 2023:
The attributes marked as "Mandatory" shall stick with multiplicity [1].
The attributes marked as "Optional" shall change to multiplicity [0..1] and get a default value.

S.No
Grouping/Datatype
Attribute
Mandatory
Optional

1
object-creation-notification
object-id-ref
X

2
object-deletion-notification
object-id-ref
X

3
attribute-value-changed-notification
object-id-ref
X

4
current-performance
granularity-period
X 1)

5
historical-performance
granularity-period
X 1)

6

period-end-time
X 1)

7
g-826-threshold-cross-alarm-type
g-826-value-kind
X 1)

8

granularity-period
X 1)

9
segment-status-type
segment-status-type-id
X 1)

It is a key attribute

Fixed with PureEthernetStructure_2.0.0-tsi.230907.1715+yang.1


Add builder-like with_finish method to ProgressBarIter.

This lets you more concisely set the finish behavior of the progress bar when using ProgressBarIter.
For example, to show a progress bar and keep it displayed when it finishes, you can do
v.iter().progress().with_finish(ProgressFinish::AndLeave)

instead of
v.iter()
        .progress_with(ProgressBar::new(v.len() as u64).with_finish(ProgressFinish::AndLeave));

Closes #545

Thanks!