The -g parameter does not show the TPM_PT_PERMANENT flags status?

When use ./eltt2 -g The follow parameters are not shown.
ownerAuthSet
endorsementAuthSet
lockoutAuthSet
disableClear
inLockout
tpmGeneratedEPS

I found that If use SLB9670VQ2.0 FW7.62 every flags will shown, but on SLB9670VQ2.0 FW7.85  is not.

Thanks for the report - you are correct.
The reason is that the TPM_PT_PERMANENT flags belong to the PT_VAR group, not PT_FIXED.
So they should not have shown up in -g but in -v
TPMs with revision 1.16 (e.g. 7.62) did not enforce the group boundary, revision 1.38 do (e.g. 7.85).
I will create a fix for this

Closed via #16

Hi Peter,
Thanks a lot.
Sincerely,
注意事項: TPM所有相關資料需從MyICP帳號下載。
若有需求，請告知，我將會指導申請帳號與資料。
Nick
Silicon Application Corp./品佳股份有限公司
Nick.Ko/柯佳均, Senior FAE
E-Mail: nick.ko<EMAIL_ADDRESS>Tel: +886-2-8226-1500#83243
Mobile: +886-963-358-858

本人免責聲明如下：本人所提供之一切設計服務,包括但不限於提供任何軟硬體工程上之建議或意見以及電腦程式軟體上之撰寫服務或軟體之程式修改等等均屬例外無償服務之性質,因此對於上該本人所提供之無償服務之內容,收受者應自行判斷抉擇或評估其適用性及正確性並自行承擔後續所有可能衍生之一切責任,本人對上述無償所提供之一切服務一概不負擔任何法律責任.

From: Peter Huewe<EMAIL_ADDRESS>Sent: Tuesday, June 16, 2020 10:04 PM
To: Infineon/eltt2<EMAIL_ADDRESS>Cc: Nick Ko 柯佳均<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [Infineon/eltt2] The -g parameter does not show the TPM_PT_PERMANENT flags status? (#15)
Thanks for the report - you are correct.
The reason is that the TPM_PT_PERMANENT flags belong to the PT_VAR group, not PT_FIXED.
So they should not have shown up in -g but in -v
TPMs with revision 1.16 (e.g. 7.62) did not enforce the group boundary, revision 1.38 do (e.g. 7.85).
I will create a fix for this
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FInfineon%2Feltt2%2Fissues%2F15%23issuecomment-644786887&data=02|01|nick.ko%40sacsys.com.tw|2cb339f142124a683da408d811fe1412|de047c79d4d94af391debc44b0581490|0|0|637279130677923720&sdata=53ZJanLHpkySbAqZ76%2B%2FHASfZA2Qhl02Qg%2FAhWm5jis%3D&reserved=0, or unsubscribehttps://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAKYAUMZOZ4VWC7SNR3JYNXDRW53TZANCNFSM4LL7GJMQ&data=02|01|nick.ko%40sacsys.com.tw|2cb339f142124a683da408d811fe1412|de047c79d4d94af391debc44b0581490|0|0|637279130677923720&sdata=wj5DPZuRMoArTaMwkXpENERiCECbK0WWDnZ%2B2l7M0oo%3D&reserved=0.


Refactor Reflection.get_page_digest/1 to use page digest registry

Done in: https://github.com/segmetric/hologram/commit/5a6028b0590d0f0a8e3b7ff32569622715499551


Fix tests on cnpj and cpf.

Coverage increased (+2.1%) to 100.0% when pulling 1bce92f604828da15e476e6511f17cb0c7b2f013 on fix-tests into 087dc1093311561b16ea546a3176887793ae405a on master.


Update foundation.d.ts

#9593 Updated some options.
Added ResponsiveMenu and ResponsiveToggle types.
Added defaults to all plugins.

i hate this travis ci .... i must say ..... network connectivity issues always

@DaSchTour @stcp what is the status of this PR?

@kball I think we shouldn't change anything here. We should do the work to shift to TypeScript and get full typings from there.

@DaSchTour Given we'll likely do at least one more release (6.4) prior to any sort of TypeScript shift, are our current typings good enough? We're likely looking at July for 6.5

@kball I work with them regularly and they serve well. I'm note sure about the changes made here and the consequences they may have and the author didn't answer any of my questions :/

Seems reasonable. Closing in lieu of any additional responses indicating why we'd need these.


Added support for RST and TXT files

Basically, for RST and TXT files we skip the comment parsing section, and simply pass each line of the files to the spell checker.
Also, more comments were added to the code.

Does this need to deal with rst markup somehow or is it sufficient to treat that as regular words and the user may need to add some that are not words into the exception/additional dictionary?

Yeah, it doesn't properly deal with RST markup keywords.  I'm going to add those keywords to the SimpleITK dictionary.


Saving/loading workspaces via sdk

What changes are proposed in this pull request?

Move fiftyone.core.spaces to fiftyone.core.odm.workspace. They were documents so belonged in odm to begin with I think. fo.Space and fo.Panel are still available as before (and have unchanged class definition except for module path.
Create fiftyone.core.odm.workspace.WorkspaceDocument class that has a Space as a top level child, as well as the other metadata like description, color, created_at, etc. This is what's saved in DB.
Copy most of the saved view implementation and paste as "workspace"

Not done: export/import/snapshot spaces (tracked in separate ticket)
How is this patch tested? If it is not, please explain why.
Added new unit tests like saved view but for workspaces
Test yourself like this:
import fiftyone as fo
import fiftyone.zoo as foz

dataset = foz.load_zoo_dataset("quickstart")

embeddings_panel = fo.Panel(
    type="Embeddings",
    state=dict(
        brainResult="img_viz",
        colorByField="metadata.size_bytes"
    ),
)
workspace = fo.Space(children=[embeddings_panel])

workspace_name = "embeddings-workspace"
description = "Show embeddings only"
dataset.save_workspace(
    workspace_name,
    workspace,
    description=description
)
assert dataset.has_workspace(workspace_name)
info = dataset.get_workspace_info(workspace_name)
assert info["description"] == description

New session
import fiftyone as fo
import fiftyone.zoo as foz

dataset = foz.load_zoo_dataset("quickstart")

embeddings_panel = fo.Panel(
    type="Embeddings",
    state=dict(brainResult="img_viz", colorByField="metadata.size_bytes"),
)
workspace = fo.Space(children=[embeddings_panel])
workspace_name = "embeddings-workspace"
dataset.save_workspace(workspace_name, workspace)

# Some time later ... load the workspace
loaded_workspace = dataset.load_workspace(workspace_name)
assert workspace == loaded_workspace

# Launch app with the loaded workspace!
session = fo.launch_app(dataset, spaces=loaded_workspace)

# Or set via session later on
session.spaces = loaded_workspace

Release Notes
Is this a user-facing change that should be mentioned in the release notes?

[ ] No. You can skip the rest of this section.
[x] Yes. Give a description of this change to be included in the release
notes for FiftyOne users.

Added ability to save and load :ref:`app spaces layouts <app-spaces>` as :ref:`workspaces <app-saving-spaces-python>` in the SDK.

What areas of FiftyOne does this PR affect?

[ ] App: FiftyOne application changes
[ ] Build: Build and test infrastructure changes
[x] Core: Core fiftyone Python library changes
[ ] Documentation: FiftyOne documentation changes
[ ] Other

Summary by CodeRabbit

New Features

Introduced workspace management in the fiftyone library, allowing users to save, load, update, and delete workspaces. Custom workspace layouts with metadata can now be created.
Added functionality for configuring app spaces within a workspace, defining components like Panel and Space for organizing app elements. Users can create and manage workspace configurations with multiple children.

Bug Fixes

Corrected a method reference in the documentation for updating saved view information.
Fixed a typo in the docstring of the ListenPayload class for improved grammar.

Documentation

Updated user guides for managing workspaces and using views with the new workspace functionality.

Refactor

Updated import statements and references for workspace-related entities across various modules to ensure consistency and alignment with the new workspace management system.

Tests

Added comprehensive tests for the new workspace management functionality, ensuring robustness and error handling.

@swheaton really appreciate the thorough treatment here! 💪
I believe there's just one additional place that needs treatment: the [Legacy]FiftyOneDataset[Importer|Exporter] classes should also include workspaces:

Yes we separated that into a different ticket for scheduling purposes (import/export not considered strictly necessary for the feature to be valid). I can add it on to this PR if I find some time.

Ok import/export is complete. I need to hop over to API repo to finish it for snapshots

@benjaminpkane do you approve of this PR? If there's more needed for UI or URLs, let's add it in a follow on PR.


Collection of ISA devices

It would be fun to have a large collection of ISA devices available.

[x] Adlib card
[x] Generic VGA card (https://github.com/andreas-jonsson/virtualxt/issues/5)
[ ] Tandy Graphics (https://github.com/andreas-jonsson/virtualxt/issues/42)
[ ] Tandy Audio (https://github.com/andreas-jonsson/virtualxt/issues/42)
[ ] Soundblaster
[ ] Diamond Trackstar (https://youtu.be/A-6AKe2pvsQ)
[ ] Covox Speech Thing
[ ] Disney Sound Source
[ ] Gravis Ultrasound (Is there software support?)

...suggestions?

Gravis Ultrasound would be great if we're talking soundcards

Never had one of those. Could be cool to try.
But are there any 8086/V20 software that supports it?
I realize there is not a lot of software that supports soundcards on these machines. :)

To be fair I had never heard of an XT system with an Adlib before, but back then I had a potato Amstrad PC-1512 :)
The "G-List" looks like a good resource for DOS games supporting Ultrasound, but as the card was first sold in '92 I doubt anything would work natively on a V20 or 8086: http://www.gravisultrasound.com/files/documentation/GLIST.TXT

For completeness's sake, I'd add the Pro Audio Spectrum and Media Vision Thunderboard sound cards


CVE-2022-21986 vulnerability caused by transitive reference to Microsoft.AspNetCore.Http.Features

My team has a .net 6 project making using of the Microsoft.ApplicationInsights.AspNetCore package on version 2.21.0. We use Veracode to scan our code and report on any vulnerable packages. We noticed that it was flagging the Microsoft.ApplicationInsights.AspNetCore package because it depends on  Microsoft.AspNetCore.Http > Microsoft.AspNetCore.Http.Abstractions > Microsoft.AspNetCore.Http.Features transitively through the Aspnetcore Http package at v2.1.22. It refers to CVE-2022-21986 as a DoS vulnerability caused by this reference.
Is this an issue that can be mitigated? Since .net core 3.1 and older has been EOL'd as of December of 2022, is it possible to have this package use dependencies referring .net6?

@gpai-pv did you share the correct CVE #?
The link you've shared is regarding "Microsoft.AspNetCore.App.Runtime" and the resolution is to update your installed runtime to the latest version.
I just doublechecked our internal tool and I'm not seeing any outstanding issues.
If you have any more details, please share here.

Interesting, I can share the output from the veracode scan regarding this issue. In the image, you can clearly see how it's pointing from the app insights package to the vulnerable http.features code.

Thanks for sharing!
The Dependency graph is correct, we do have a transitive dependency on "Microsoft.AspNetCore.Http.Features" v2.1.1
But I don't see how this is related to the CVE.
Interesting to note that this version of the package hasn't been deprecated:
https://www.nuget.org/packages/Microsoft.AspNetCore.Http.Features/2.1.1

I don't understand how veracode flagged it as a vulnerability either. So, to reiterate it is currently safe to use Microsoft.ApplicationInsights.AspNetCore package?

Yes, there are no known issues with any of our Application Insights SDKs.
v2.21 was affected by one CVE. I addressed that issue several months ago and the fix is available in our latest beta.
The next stable release should be coming out within the next month or two.
https://github.com/microsoft/ApplicationInsights-dotnet/blob/main/CHANGELOG.md

@TimothyMothra  Veracode is reporting the same vulnerability exists in the current beta version of microsoft.applicationinsights.aspnetcore as well (v2.22.0-beta3).
Is this something that can be addressed in the next GA version of microsoft.applicationinsights package? below are the details of the vulnerability reported by veracode.
Package: microsoft.aspnetcore.http.features 2.1.1
Vulnerability: https://sca.analysiscenter.veracode.com/vulnerability-database/security/denial-of-service-dos-/csharp/sid-34137

Please let me know if you need additional details that could help.

Reopening while I follow up on this.
Workaround
@gpai-pv @SenthilSelvaraju as a workaround, you should be able to take a direct dependency on a newer Microsoft.AspNetCore.Http.Features.
That should resolve the Veracode alert for your applications.
If you do this, can you please respond which version you took to clear the alert?
Details
Some mixed messages on this CVE...

https://github.com/advisories/GHSA-x459-p2rx-f8ff

To fix the issue, please install the latest version of .NET 6.0 or .NET 5.0.

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-21986
This only references the Security Updates for .NET 6.0 and 5.0
https://sca.analysiscenter.veracode.com/vulnerability-database/security/denial-of-service-dos-/csharp/sid-34137
Veracode is recommending updating Microsoft.AspNetCore.Http.Features to v5.0.14.
v5.0.14 is referenced in Microsoft's security advisory and was released in tandem with the .NET update.

https://devblogs.microsoft.com/dotnet/february-2022-updates/
https://github.com/dotnet/core/blob/main/release-notes/5.0/5.0.14/5.0.14.md#microsoft-security-advisory--cve-2022-21986---net-denial-of-service-vulnerability

https://www.nuget.org/packages/Microsoft.AspNetCore.Http.Features/5.0.14#versions-body-tab
The owners of Microsoft.AspNetCore.Http.Features have marked v5.0.14 is Deprecated.

https://www.nuget.org/packages/Microsoft.AspNetCore.Http.Features/2.1.1#versions-body-tab
v2.1.1 has NOT been marked Deprecated.

We were able to get the veracode message to go away if we update to v5.0.14 or higher. As it is in a .net 6 project though, it seems odd that the fix is to reference either a deprecated v5.0.14+ package or a 6.0.0 preview package. We had a nuget package internal to our company for which we were able to fix it by making it target .net 6 instead of net standard 2.0. Please advise on next steps.

I spent some more time looking into this.
To resolve this issue, please make sure to install the latest version of the .NET Runtime.

https://github.com/advisories/GHSA-x459-p2rx-f8ff

To fix the issue, please install the latest version of .NET 6.0 or .NET 5.0.

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-21986

Demonstrating the fix
I created an empty ASP.NET Core application with the latest AI SDK beta.
Although SDK references Microsoft.AspNetCore.Http.Features v2.1.1, the runtime will pull in a higher version.
This can be seen by debugging an application and inspecting the Modules:


math.js counterintuitive formula with mod

If you use s*t mod 10 as a math.js formula, you get s*(t mod 10), whereas I think anyone reading it would expect (s*t) mod 10.  If this is just something about math.js, then we could at least warn/document.  If this is something we can change, that would be great.

This is a mathjs issue that has been fixed in ver 14, so should be resolved by #343


Individual Review Ticket (Ethan)

Name: Ethan Hong
Team+Indi+Teacher:
Key Commit(s): 1. https://github.com/ninaadkiran/tinga2/commit/90793dd7598b01f42c7c968f4bdf07df3aac00a6    (Barebones, created the barebones of the website and functions with edited/removed lines of code which would serve as our main basis and idea of the website. Added 3 different binary lines for each R G and B value.)

https://github.com/ninaadkiran/tinga2/commit/24390391a0d41a1cf87a1e256b64236c059c4c5d  (Added Opacity  Slider, Added opacity slider which holds functionality to the website by not strictly using R G and B for colors, but also  adding translucency to the colors which adds to having 4 different values that would each contribute to the amount of red, blue, green, and the actual visual aspect of the website.)

https://github.com/ninaadkiran/tinga2/commit/ee265eb3ce34e6f1503cc04f843fc668c1bb1efa      (Added Hex to RGB, the hex to RGB allows for pre-existing color codes to be used within the website and show the actual binary values that those existing codes would provide. The Hex to RGB uses a text box to use codes such as FFFFFF(white) or 000000(black) to combine percentages to values and binary.)

Analytics: https://github.com/ninaadkiran/tinga2/graphs/contributors

Team Review: Individual review ticket for Ethan Hong [Ankit Pulivendula]:

[x] The team should have a Web Pages that teach: Binary, Data, Data Structures, Data Abstraction.

Team Review ticket containing key Team and individual contributions

[x] Growth/Accomplishments in work is according to historical Team Plan, or they show revisions to plan according to work
[x] Short falls/Improvement that could be made in Work or Team Plan, team highlights next steps or improvements that could be made
[x] Showing key accomplishments according to requirement in Frontend such as Binary Math, ASCII, Unicode, Color Codes, Logic Gates, etc.
[x] Showing key user interaction and learning(s).  For instance how you visualized  Algorithms, Data, Data Structures.  Or, how you provided response and Feedback to user on their success in learning.

Per check.
0.55 not attempted/no check
0.7 attempted, incomplete, but some runtime
0.8 mastery and runtime
0.9 above and beyond.
FINAL GRADE: 0.9/0.9
Justification: Ethan has clearly demonstrated proficiency in JavaScript through his major additions to their project. He created the barebones of the entire project with buttons, etc. He also created the opacity slider, making an enjoyable experience for the user. Finally, he implemented the hex to binary conversion feature along with the RGB decimal code conversion. Overall, it is clear that Ethan has contributed greatly to the project while also going above and beyond, earning him a 0.9/0.9. Great job!
Other comments: Efficient division of work with teammates.


Frontend refactoring

This PR is a long overdue, it cleans up the way the plonk constraint system is added, and makes the code upgradable for different new constraint systems (custom gates, generalised arithmetic circuits, square constraints, etc).
Architecture
The frontend is now organised like this:
frontend/
├── compiler
├── cs
│   ├── plonk
│   └── r1cs
└── utils
frontend/
api.go provides the API interface that a constraint system should implement (with the usual fonctions like Add, Mul, etc). It also provides an interface System with inherits from API, and provides the fonctions
type System interface {
	API
	NewPublicVariable(name string) Variable
	NewSecretVariable(name string) Variable
	Compile(curveID ecc.ID) (compiled.CompiledConstraintSystem, error)
}

circuit.go provides the interface that a circuit should implement (as before).
compiler/
compile.go provides the logic to build a constraint system to its target form (r1cs or sparse r1cs). It provides the same function Compile as in develop. The difference is that buildCS has been renamed bootStrap and takes as parameter the System interface. It acts exactly as in develop, recursively instantiating the inputs and calling Define afterwards.
cs/
cs.go provides the common data shared by each constraint system:
type ConstraintSystem struct {
	compiled.CS

	// input wires
	Public, Secret []string

	CurveID ecc.ID
	// BackendID backend.ID

	// Coefficients in the constraints
	Coeffs         []big.Int      // list of unique coefficients.
	CoeffsIDsLarge map[string]int // map to check existence of a coefficient (key = coeff.Bytes())
	CoeffsIDsInt64 map[int64]int  // map to check existence of a coefficient (key = int64 value)

	// map for recording boolean constrained variables (to not constrain them twice)
	MTBooleans map[int]struct{}
}

It is essentially a list of coefficients, to be affected to wires, it is agnostic of the constraints. It inherits from CS defined in package compile.
r1cs/, plonk/
Those folders contain the actual instantiation of plonk constraint systme and Groth16 constraint system (respectively sparse_r1cs and r1cs in our naming).
r1cs/ contains the same api as in develop, the files were merely moved from frontend/ to r1cs/.
'plonk/' contains the equivalent data but for sparseR1CS. In particular an api.go has been created for handling plonk constraints, so there is no longer a conversion from r1cs to sparser1cs.
Both constraint systems inherit from ConstraintSystem, with an additional field which is the slice of the actual constraints (ex:
type SparseR1CS struct {
	cs.ConstraintSystem

	Constraints []compiled.SparseR1C
}

).
In both r1cs/ and plonk/ there is a conversion.go file providing a Compile function which essentially shifts the IDs of the variables in the logs, etc after a circuit is built. This function is internally called by Compile defined in frontend/compiler/compile.go.
API breaking changes

frontend.Compile --> compiler.Compile
type Hint struct {ID     hint.ID , Inputs []Variable}--> type Hint struct {ID     hint.ID,  Inputs []interface{}}

Status
Tests pass, except the circuits_stats tests for several of the circuits used in integration tests have been extended to cover more cases. There is no change in Groth16 in terms of number of constraints (Groth16 logic hasn't been modified at all, the files were merely moved around).

I have refactored the branch a bit more.
I reverted the move of Compile function into a sub-package. In addition, I added two registries:

a registry for frontend -> compiler mappings.
a registry for backend -> frontend mappings.

Now, when someone wants to add (or even use their internal backend), it is possible to use a gnark compiler without having to change the library. Similarly, it is possible to define a new compiler (a frontend actually as every frontend can have only a single compiler).
This has a small side-effect though -- as the registrations are performed lazily in inits (due to needing to avoid the import cycles), then in strange workflows the compilers won't be registered and compilation will fail (for example, when compiling a circuit without later proving or verifying it). I tried making the corresponding errors quite explanatory so that the user would know what to do.
There are still tons of things to do (and I would actually split some stuff into smaller PRs), for example:

[ ] fix failing tests (they were failing locally even before my additional refactoring)
[ ] make API smaller by moving out frontend-independent methods
[ ] move frontend debugging stuff out
[ ] bring back compiler options (they were already lost in the PR)

Does this API make sense? I'll move on polishing it more.

@ivokub I think this is not the best solution -->

then in strange workflows the compilers won't be registered and compilation will fail (for example, when compiling a circuit without later proving or verifying it).

--> I think this may happen quite often (use of the backend or the frontend independently), typically in dev cycles or serializing only the compiled circuit.
I don't see why the backend should know which frontend it "accepts". That limits gnark extensions; if someone wants to write a new R1CS frontend, suddenly they can't use our backend/groth16 package.
my proposition is essentially:

rename / move System in frontend/cs/ to frontend/Builder
have frontend/cs/r1cs and frontend/cs/plonk declare a public

func Builder(curveID ecc.ID) frontend.Builder {
	return newR1CS(curveID)
}

package level function. + public R1CS struct, all the rest, package private.
(or wrap it as you did in another function if you want to manage errors)

have the frontend.Compile signature change to:

func Compile(circuit Circuit, builder Builder, ...)

so that the caller code looks like
frontend.Compile(&circuit, r1cs.Builder(ecc.BN254))

I think it was a mistake to put the zkpID (backend.ID) in frontend.Compile in the first place; you can build a R1CS in different backend, so it makes no sense semantically to tie it to backend.GROTH16.
I started a branch (refactor-flexible-compiler) that did that, but can't finish tonight. You can pick it up or throw it away and come w/ a better approach :) . I stopped when I realized that the APIs of the assert.ProverSucceeded... assumed such a 1-1 mapping between frontend and backend, and that we need to think this through --> the testing package will need to know which pair of frontend / backend you want to test with. We can provide a default mapping, but I assume we need new TestOptions to allow users to supply their own backend / frontend .

@ivokub I think this is not the best solution -->

then in strange workflows the compilers won't be registered and compilation will fail (for example, when compiling a circuit without later proving or verifying it).

--> I think this may happen quite often (use of the backend or the frontend independently), typically in dev cycles or serializing only the compiled circuit.

It was not a fatal error - due to lazy registration the compiler does not get registered if it is not explicitly imported by anything. Adding a blank import (import _ "github.com/consensys/gnark/frontend/cs/r1cs") fixes the compilation.

I don't see why the backend should know which frontend it "accepts". That limits gnark extensions; if someone wants to write a new R1CS frontend, suddenly they can't use our backend/groth16 package.

But there is a dependence between a backend and a constraint system? Any Groth16 backend requires R1CS and PLONK backend requires SparseR1CS. Right now we have the constraint system (i.e. a list of constraints) and a circuit->CS compiler coupled. A backend does not necessarily require a specific compiler, but it still requires a specific CS.
In my branch the built-in backends register default compilers themselves. It would make sense to add a compile option to pick a particular compiler.

my proposition is essentially:

rename / move System in frontend/cs/ to frontend/Builder
have frontend/cs/r1cs and frontend/cs/plonk declare a public

func Builder(curveID ecc.ID) frontend.Builder {
	return newR1CS(curveID)
}

package level function. + public R1CS struct, all the rest, package private.
(or wrap it as you did in another function if you want to manage errors)

What about separating the CS and compilers? This means having structure:

frontend/ -- user API, generic Compile which uses registry for picking compiler, compilation options
frontend/cs/ -- your Builder, definitions of R1CS and SparseR1CS structures
frontend/compiler -- built-in compilers for compiling circuits into R1CS and SparseR1CS. Every compiler has New (rename?) variable of type Builder so that the compiler can be called bypassing the registry

have the frontend.Compile signature change to:

func Compile(circuit Circuit, builder Builder, ...)

so that the caller code looks like
frontend.Compile(&circuit, r1cs.Builder(ecc.BN254))

I think it was a mistake to put the zkpID (backend.ID) in frontend.Compile in the first place; you can build a R1CS in different backend, so it makes no sense semantically to tie it to backend.GROTH16.

I think having it makes some sense -- from a user point of view who just wants to construct a proof from a circuit, it doesn't really matter what is the underlying CS. Right now, due to the default mapping from a backend to compiler the user can just define which backend they intend to use and the frontend.Compile function picks a default one. It would make sense to add a compile option to allow choosing different compilers if the user really knows what they are doing, but otherwise the default choices should be sane.
Most of all, I think it wouldn't be great to change the frontend.Compile signature.

I started a branch (refactor-flexible-compiler) that did that, but can't finish tonight. You can pick it up or throw it away and come w/ a better approach :) . I stopped when I realized that the APIs of the assert.ProverSucceeded... assumed such a 1-1 mapping between frontend and backend, and that we need to think this through --> the testing package will need to know which pair of frontend / backend you want to test with. We can provide a default mapping, but I assume we need new TestOptions to allow users to supply their own backend / frontend .

I'll try.

I think having it makes some sense -- from a user point of view who just wants to construct a proof from a circuit, it doesn't really matter what is the underlying CS. Right now, due to the default mapping from a backend to compiler the user can just define which backend they intend to use and the frontend.Compile function picks a default one. It would make sense to add a compile option to allow choosing different compilers if the user really knows what they are doing, but otherwise the default choices should be sane.
Most of all, I think it wouldn't be great to change the frontend.Compile signature.

OK makes sense. Not a fan either of changing the Compile signature. So te be clear, idea is in the future, if we support other "builders" or "compilers " than the ones provided by gnark, call would be through compile options  :
 frontend.Compile(BN254, GROTH16, circuit, frontend.WithBuilder(myCustomBuilder))

OK makes sense. Not a fan either of changing the Compile signature. So te be clear, idea is in the future, if we support other "builders" or "compilers " than the ones provided by gnark, call would be through compile options :  frontend.Compile(BN254, GROTH16, circuit, frontend.WithBuilder(myCustomBuilder))

Yes, that is the idea. I think it wouldn't be too much to add to this PR, but having it in a separate PR would make more sense when creating changelog.

Rebased on top of develop, it now mergeable without conflicts. All the tests are now green and the discovered bugs fixed. Orthogonal to the refactoring work I had to modify compiled circuit serialization to/from CBOR so that the serialization tests would succeed.

looks awesome thanks @ivokub & @ThomasPiellard , will do few cosmetic edits and merge 👍

@ivo.kubjas I still don't like that we have to do this:
ccs, err := frontend.Compile(curve.ID, backend.UNKNOWN, &circuit, frontend.WithBuilder(plonk.NewBuilder))

instead of this
ccs, err := frontend.Compile(curve.ID, backend.PLONK, &circuit)


Allow to initialise PlatformIO project for the specified IDE

Aims
PlatformIO can be integrated to multiple IDE/editors using a few installation/customisation steps. They are described in main documentation. Will be useful to have additional option --ide to platformio init command.
How it works
If user specifies supported --ide type, then PlatformIO generates fully compatible project for the specified IDE (configuration files, etc.). This project can be imported later via IDE -> Import Project and should contain preconfigured settings:

Include Search Path: add to "Indexer Include Path" all paths from toolchain, framework, SDK
Build System: configure build system for project to: build command - platformio --quiet run, clean command - platformio --quiet run --target clean
Preprocessor definitions/symbols: Specific definitions based on board type, like __AVR_ATmega328__

IDE
We should support these IDE/Editors from the beginning:

eclipse Eclipse
visualstudio Visual Studio
sublimetext Sublime Text
qtcreator Qt Creator

Examples
# Arduino compatible project for Eclipse
$ platformio init --board=uno --ide=eclipse

# mbed compatible project for Microsoft Visual Studio
$ platformio init --board=lpc1768  --ide=visualstudio

Questions
How about multiple --board options or environments?
If more then one board is specified, then "first-generated" environment should be used. Nevertheless, we will add additional option, like use_for_ide = true to   [env:xxx] group in platformio.ini.

@valeros please look into @0xc0170 https://github.com/0xc0170/project_generator
Looks like what do we need. Nevertheless, project_generator  supports only eclipse, but we can extend this list via templates.

0xc0170/project_generator might save you a bit of work with exporting to IDEs - we currently don't support visualstudio or sublimetext, however it wouldn't take much work to get those working. The only problem is that project_generator is currently only used with ARM architecture processors, however it wouldn't take very much work to get this to work with AVR and others. I've actually been meaning to add sublimetext support to pgen since it's what I always use, so I'll open an issue over there now.
We'd definitely welcome any contribution you guys are able to make, especially towards supporting different architectures.
if you have any questions about project_generator ask me or @0xc0170

@matthewelse Thanks, see my comment above :+1:

The only problem is that project_generator is currently only used with ARM architecture processors, however it wouldn't take very much work to get this to work with AVR and others

Do we have option to specify own Preprocessor definitions/symbols and Build System? It is important for us, because PlatformIO has own code builder and uses own pre-built toolchains, frameworks and etc . In other words, it is replacement for internal IDE's  build system.
These Include Search Path and Preprocessor definitions/symbols  are need just for correct "code completion" and "Realtime Indexer".
See examples:

http://docs.platformio.org/en/latest/ide/visualstudio.html
http://docs.platformio.org/en/latest/ide/eclipse.html
http://docs.platformio.org/en/latest/ide/sublimetext.html

I guess that you mean doing platformio run instead of make as part of the build system?

Yes. See Get Started.

All project settings are predefined by a user in yaml files -> dictionaries, thus if a project dictionary is filled with proper data, it can be passed to pgen to export the project files. Is this enhancement to create a full project (all source files, include paths, macros in the IDE) ? Or just required project files with defined output binary created by your build system, be available for debugging? If you got questions, create a new issue on pgen github. We can continue the discussion there, if needed.
I would like to see more tools supported, as mentioned above, like sublime, visual studio or any other which users prefer to use.

@0xc0170, I've just opened a new issue #154. We will show what do we need in the final result.
Here are a few examples with Eclipse: https://github.com/platformio/platformio/tree/develop/examples/ide-eclipse

Is this enhancement to create a full project (all source files, include paths, macros in the IDE) ?

Just: include paths, macros + replacement of internal build system to PlatformIO Code Builder.

If you got questions, create a new issue on pgen github.

I create new issue on pgen project if the issue #154  will be fixed. I need to show you a few examples with configuration files which we need and how they should be filled.
Thanks!


TSX language service not showing suggestions in correct order

Issue Type
Bug
Description
interface MyComponentProps {
	name: string;
	age: number;
}

class MyComponent extends React.Component<MyComponentProps> {
	render() {
		return

;
	}
}

class OtherComponent extends React.Component {
	render() {
		return (
			<MyComponent  $1  />
		);
	}
}

Place cursor at the $1 location inside the render method of OtherComponent. Hit ctrl + space to see suggestions of the props that MyComponent requires.
You will see that name and age are provided as suggestions, but they aren't at the top of the list like they should be and they are scattered in among keyword and other suggestions.
This used to work until the most recent update.

VS Code Info
VS Code version: Code 1.20.1 (f88bbf9137d24d36d968ea6b2911786bfe103002, 2018-02-13T15:23:28.607Z)
OS version: Darwin x64 17.4.0

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz (8 x 2800)

Load (avg)
2, 2, 2

Memory (System)
16.00GB (2.57GB free)

Process Argv
/Applications/Visual Studio Code.app/Contents/MacOS/Electron .

Screen Reader
no

VM
0%

Extensions (5)

Extension
Author (truncated)
Version

gitlens
eam
8.0.2

json-tools
eri
1.0.2

vscode-subword-navigation
ow
1.1.5

json-organizer
rin
0.0.3

nunjucks
ron
0.2.3

Reproduces without extensions

Tracked upstream by https://github.com/Microsoft/TypeScript/issues/21844
Should already be fixed in typescript@next if you want to give that a try in your workspace


ESP32-C3: ESP_CONSOLE_USB_SERIAL_JTAG does not work if terminal program does not support escape sequences (IDFGH-7248)

Environment

Development Kit:      ESP32-C3-DevKitC-02
Kit version: v1.1
Module or chip used:  ESP32-C3-WROOM-02
IDF version: v4.4
Build System:         idf.py
Compiler version: riscv32-esp-elf-gcc.exe (crosstool-NG esp-2021r2-patch2) 8.4.0
Operating System:     Windows 11
(Windows only) environment type: PowerShell
Using an IDE?: Yes, VS Code
Power Supply:         USB

Problem Description
I'm trying to write a python script to send commands to ESP32-C3 over USB console (Not USB-UART chip) and read responses. Putty works fine with the terminal, but simple python serial.readline() does not. Figured out the reasons:

linenoiseProbe() blocks on read() even though non-blocking mode is set. Console will not start until you send at least 4 bytes in response to fprintf(stdout, "\x1b[5n");

linenoiseProbe() does not check if respose is correct (ESC[0n or ESC[3n) so any incoming bytes are treated as correct response and terminal program is treated as if it supports escape sequences and colors.

Terminal program response may be verified this way:
components\console\linenoise\linenoise.c:1066
+   if (read_bytes == 0 && c != 0x1b)
+   {
+       break;
+   }
    read_bytes += cb;

Expected Behavior

read() should not block
linenoiseProbe() should correctly detect terminal program capabilities

Actual Behavior

read() blocks even though non-blocking mode is set
linenoiseProbe() always reports escape sequences are supported

Thanks for raising the issue @dimka-rs! Indeed the non-blocking reads are not implemented in the VFS driver for usb_serial_jtag: https://github.com/espressif/esp-idf/blob/9663a282b35d4533a81d18e201f6895611fb2643/components/vfs/vfs_usb_serial_jtag.c#L74-L76. It seems that the underlying usb_serial_jtag driver actually supports that, so we need to modify usbjtag_rx_char_via_driver function in the same file to check the non_blocking flag.
Linking https://github.com/espressif/esp-idf/issues/8789 which is probably related (although is for S3, not C3).


async actions not correctly handled

Sails version: 1.0.0-36
Node version: 8.1.4
NPM version: 5.3.0
Operating system: Debian 9.0

Hello guys, when you make an async/await function as a controller action and an error occurs, this message is displayed :

You have triggered an unhandledRejection, you may have forgotten to catch a Promise rejection

This is because the error thrown by the promise is not correctly catched, the condition in lib/router/bind.js (line 339) is never true because you are testing the constructor of a wrapper function created at line 209 instead of the real action function (sails._actions[actionIdentity]), so the constructor name is always "Function".

@magiksd thanks for bringing this up!  This is fixed for helpers, actions, and policies on master, and it'll be included in the next beta release on NPM.  Apologies for the delay -- there's a few different packages involved in making this happen (particularly for helpers).  If you want to take it for an experimental spin in the mean time, please have a go at npm install sails@balderdashy/sails
(Before we do 1.0 stable, I'm hoping to squeeze in the same compatibility for the new v1.0 CLI scripts, and update the generators to always include the async keyword by default in new helpers, actions, policies, and scripts.  BTW, I'd love some help updating some of the more important v1 doc pages to use await if anyone wants to take a pass at a few pages on the 1.0 branch of balderdashy/sails-docs)

@magiksd Welllllll, my bad -- I totally missed the point.  Just reread your post and now I see what you mean.  Yes, this looks like a separate issue.  In the general case, this isn't showing up for actions anymore, but in certain cases it definitely looks like a problem (maybe it's just when action middleware like policies is being applied?)  I'll put aside some time early next week to take a closer look.  In the mean time, PRs welcome if anyone would like to get this started.

@mikermcneil thanks for your answer, but I don't understand what you mean with "this isn't showing up for actions anymore", have you already fixed it ?

@mikermcneil @magiksd We're handling uncaught promise rejections in bindFunction, which takes care of a lot of cases (including action middleware like policies and ad-hoc functions in the routes.js), but when it comes to actions we also need to handle the action function invocation here.  I'll take a pass at it and write some tests.

@magiksd This should be good to go on the master branch, if you feel like testing it out...

Yep, it works. I can finally have a correct error stack in the console and use my serverError response. Thanks !

Re async/await in docs and everywhere, October is the month where Node 8 should become LTS, may be it can wait until then? anyway, I support 100% the use of it!


Adopt native coroutines

Once Python 2 support has been removed (#63), we should update the coroutine decorators and associated backward compatible constructs to use native coroutines (async def and await).

There was a massive PR by @blink1073 #23 which did exactly that. At the time, it was decided to not go with this right away to remain closer to the notebook codebase for a little bit longer.
Maybe we want to go ahead with this now.

@SylvainCorlay - I'm sorry I didn't catch that - thanks (and thanks @blink1073!)
I think once we've brought over the remaining notebook commits, we should embark on such a thing.  (I suppose we should hold off on #90 until then as well.)  Do we have an enumeration of which commits we should cherry-pick?

Funny enough, I'm working on the notebook PR porting now...

These were all updated in #191! :tada: Closing!


x/pkgsite: package removal request for github.com/fastbpmn/go-study

What is the path of the package that you would like to have removed?

https://pkg.go.dev/github.com/fastbpmn/go-study
Are you the owner of this package?

yes
What is the reason that you could not retract this package instead?

I am new to publishing packages & made way too many mistakes & now have way too many versions of the package out there. I should've done it in pre-release first but was arrogant & thought the package was simple enough to push out there without pre-releases.

please use retract directives for this.

@fastbpmn, the retract directive must be included in the latest release of the module.
Try changing the directive to retract [v1.0.0, v1.0.3] and tagging it v1.0.3 (which would then retract itself).

@fastbpmn, the retract directive must be included in the latest release of the module.
Try changing the directive to retract [v1.0.0, v1.0.3] and tagging it v1.0.3 (which would then retract itself).

Thank you for your help，I will try it tomorrow.

I didn't have time to reply yesterday, this issue has been solved, thank you for your help.


Change rhel images to ubi images for Openshift manifests

Because R2011 requires all images to use ubi tab then I change it for Openshift manifests.
I've checked that Openshift dpeloyment works with these tags.

recheck

recheck

recheck

recheck

/gcbrun

recheck

recheck

recheck

recheck

recheck

recheck ha

recheck ha

recheck ha


Nuke

This only leaves a README stating exactly:
developer.rackspace.com
developer.rackspace.com is now split across several repositories, backed by the deconst engine.
There are two sections of the site, /docs and everything else:

/docs - github.com/rackerlabs/docs-quickstart
/, /blog, /sdks, etc. - github.com/rackerlabs/docs-developer-blog

Contribute in those repositories to reflect changes, submit blog posts, raise issues, demand ransom, eat cake, and encourage a vibrant community.
If you want to see behind the covers to know the layout, check out the control repository.

I'm worried about what this will do to the Jenkins builds, and I'm not quite ready to trash the running system just yet - I'm leaving it up for a week or so, so that we can cut back to it quickly if everything crashes horribly on the new system.
We could just kill the Jenkins servers and leave the rest running, though. :thought_balloon:

I agree with the joker. (I can't believe I'm saying this)

:laughing:
Alright. I'll :skull: when I hit a breaking point here. Right now I live in a universe of boxes and packing tape.

Yeah, it'll be fine to have it as a backup for now and nuke after you get settled.


Consider replacing CGLIB with ByteBuddy

I ran again to the java.lang.NoClassDefFoundError: net/sf/cglib/proxy/Callback issue that is caused by me not taking care of my classpath properly when using aliases.
Could it be possible to replace the enhancer with ByteBuddy which doesn't bring any proxy classes to the final bytecode like both JavaAssist and CGLIB do. This how Hibernate for instance has been lately solving similar issues around their bytecode enhancement.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Is there anything we can do to combat this? Or would we need to migrate?

This merely an annoyance unless CGLIB becomes again incompatible with latest jdk updates as it has in the past been. It's quite easy to forget to put CGLIB as a dependency because it's an optional one. With ByteBuddy, there is no such need because it doesn't leave any track of itself.

The core team is unlikely to pick this up any time soon. PR's will be accepted though.

Just to inform about cglib issue with JDK 17+


collapse all / expand all when no item is selected

From<EMAIL_ADDRESS>on 2010-09-12T18:27:04Z
The project explorer and outline explorer may perform "collapse all" / "expand all" when no item is selected.
No item is selected when the outline explorer is toggled on.
Original issue: http://code.google.com/p/spyderlib/issues/detail?id=357

From pierre.raybaut on 2010-09-13T00:58:49Z
Could you please rephrase this? (I think there is something missing in your report...)

From pierre.raybaut on 2010-09-25T00:56:09Z
Status: Invalid


One-line mode shows coordinates instead of City, Country format

Hi!
After #264 is fixed (thanks for the fast fix!) I suppose it is better to display the current city in the one-line mode for auto-detected location. Full mode display correct city
$ curl "wttr.in/?0"
Weather report: St Petersburg, Russia

               Overcast
      .--.     -9--2 °C
   .-(    ).   ← 26 km/h
  (___.__)__)  10 km
               0.0 mm

but in one-liners, I can see only coordinates
$ curl "wttr.in/?format=4"
59.938732,30.316229: ☁ 🌡-2⁰C 🌬←26 km/h

The label for predefined location is used from the query:
$ curl "wttr.in/Saint-Petersburg,Russia,PREDEFINED_TEST?format=4"
Saint-Petersburg,Russia,Predefined_Test: ☁ 🌡-2⁰C 🌬←26 km/h

Awesome! Thanks again for the fast fix! Now it works great.


TD-407: Add route to limit context

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
19 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-0.06%) to 89.308%

Files with Coverage Reduction
New Missed Lines
%

apps/hellgate/src/hg_limiter.erl
1
98.46%

apps/hellgate/src/hg_fault_detector_client.erl
3
43.55%

apps/hellgate/src/hg_invoice_payment.erl
15
94.38%

Totals

Change from base Build<PHONE_NUMBER>:
-0.06%

Covered Lines:
4068

Relevant Lines:
4555

💛  - Coveralls


Disregard messages if several come in rapid succession?

Discussed in https://github.com/karashiiro/TextToTalk/discussions/78

Originally posted by allibear17 January 30, 2022
TTS does not handle well messages that are typically macros of several chat messages, meant to make some sort of ascii art.  If it's possible to recognize that the same person sent several messages within a second of each other, you could disregard reading those?

Should be closed as of https://github.com/goatcorp/DalamudPlugins/pull/2145


JavaAgent Detector for LightStreamer

Would you be happy for a PR to include a new detector for LightStreamer?
LightStreamer starts its own MBean server and Jolokia is intermittently picking up the MBeans depending upon how fast the the JavaAgent gets through the MBean scanning stage and the LightStreamer MBean server being created.
I would like to submit code for a detector which will identify a LightStreamer system by either SystemProperty or loaded Class and then delay the MBean scanning until it detects the MBean classes being loaded.

I'm perfectly fine with a PR which does such lazy init, as long as it doesn't reference any non-standard classes directly (only via reflection). Please have a look at the Wildfly detector which also does a lazy evaluation and init (which is needed there because of some race condition with the initialization of the logging system).
Thanks !

PR Raised #347


Remove usage of compile configuration in Groovy transitive dependency sample

We are removing that sample so there is no need to fix. However there is the issue that it's not obvious for users they need to apply java-library plugin to access the api configuration.


Stack overflow with macros

Prerequisites

[x] Put an X between the brackets on this line if you have done all of the following:

Checked that your issue isn't already filed.
Reduced the issue to a self-contained, reproducible test case.

Description
Lean crashes with a stack overflow when defining macros by hand.
[Description of the issue]
Steps to Reproduce
Here's an MWE tested with current nightly (2022-07-18) on both Mac M1 and Linux x86
import Lean

declare_syntax_cat foo
syntax (name := foo1) ident : foo
syntax (name := foo2) foo,* : foo

@[macro foo1]
def expandFoo1 : Lean.Macro
  | `(foo| $x:ident) => do `(Lean.quote [$(← x.getId.toString)])

Open on Emacs/vscode or put it in a file and runlake build
Expected behavior: [What you expect to happen]
Lean not crashing (e.g. giving me a type error instead if something's wrong)
Actual behavior: [What actually happens]
Lean crashes with an error:
> LEAN_PATH=./build/lib LD_LIBRARY_PATH=/home/goens/.elan/toolchains/leanprover--lean4---nightly-2022-07-18/lib:./build/lib /home/goens/.elan/toolchains/leanprover--lean4---nightly-2022-07-18/bin/lean ./././Test.lean -R ././. -o ./build/lib/Test.olean -i ./build/lib/Test.ilean -c ./build/ir/Test.c
error: stderr:

Stack overflow detected. Aborting.
error: external command /home/goens/.elan/toolchains/leanprover--lean4---nightly-2022-07-18/bin/lean exited with status 134
error: build failed

Reproduces how often: [What percentage of the time does it reproduce?]
Every time
Versions
You can get this information from copy and pasting the output of lean --version,
please include the OS and what version of the OS you're running.
Lean (version 4.0.0-nightly-2022-07-18, commit 5083d47e4d3c, Release)
Both on MacOS 12.1 on Apple M1 Pro and Debian 11 on x86
Additional Information
Any additional information, configuration or data that might be necessary to reproduce the issue.

The declaration syntax (name := foo2) foo,* : foo is what is causing this (and it quite logically produces a stack overflow due to the recursive use of foo). How are you expecting Lean to prevent this? Note that it cannot, in general, simply check if foo is recursive, because a user can produce the same error with:
syntax hiddenFoo := foo
syntax hiddenFoo : foo

ah wow, I don't know how I didn't see this, sorry. I should have probably let it rest overnight, looking at it now in the morning it's obvious. Thanks!


[PBIOS-432] Dark mode color exception handling

What does this PR do? A clear and concise description with your runway ticket url.
Step by step to create a dark mode color exception:
Add extenssion to Color struct, Add to the correspondent component enum the dark mode color exceptions;
The dark mode color exception should be defined by a static funcs that will receive a colorScheme argumet;
Add a private Environment colorScheme prop to every component that needs a dark mode color exception.
Screenshots: Screenshots to visualize your addition/change

How to test? Steps to confirm the desired behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See addition/change

Checklist

[ ] LABELS - Add a label: breaking, bug, improvement, documentation, or enhancement. See Labels for descriptions.
[ ] RELEASES - Add the appropriate label: Ready for Testing / Ready for Release
[ ] TESTING - Have you tested your story?

 The text is not visible. But this is just the screenshot, you did add the ability to change the text color in the other task, correct?


Provide live streaming capability for suite_mode

Reproducible using <IP_ADDRESS>
Zafira run URL: http://<IP_ADDRESS>/zafira/#!/tests/runs/9
Configuration specifics:
driver_mode=suite_mode

it should be available in <IP_ADDRESS>+


no need to parse an HTML page for all of the lint rules

I notice that you're scraping the lint rules from a web page.
According to this comment, the lint rules are available as a yaml file here.

Oh cool, thanks for the tip, I just grabbed this link for my own usage! 😃

Using that file could be problematic because it has the lint rules of the current main branch, while the published version of the lints is for the stable version of the sdk. It can even contain rules for which a sdk version isn't published yet (e.g. current dev channel Dart version is 3.7.0-39.0.dev but it doesn't know about the specify_nonobvious_property_types rule).
So you'd have to use a tagged version (but now you need to get the version of the published stable Dart SDK from somewhere) to get the current stable version of the lints like: https://raw.githubusercontent.com/dart-lang/sdk/refs/tags/3.5.4/pkg/linter/example/all.yaml


[Node Mgr] Support Bulk Node Registration and Fix Upload API

This PR proposes the following two changes:

Add a new bulk create API to support batch node registration
Fix the current Upload API to support uploading a json file with multiple nodes. More context as follows.

Context
The Node Mgr API /nodes/upload doesn't meet the design goal of registering multiple nodes in one shot. The required format of machine.json file is as follows:
{
   "Hosts": [
      {
         "local_ip": "<IP_ADDRESS>",
         "node_id": "cc09465c-5ed6-400e-806d-fbe3d12f94a9",
         "mac_address": "00:A0:C9:14:C8:29",
         "node_name": "Compute1",
         "server_port": 50001,
         "veth": "eth0"
      },
      {
         "local_ip": "<IP_ADDRESS>",
         "node_id": "a976fe8a-2ebc-4d8b-9750-a6ec31b9680e",
         "mac_address": "00:A0:C9:14:C8:3A",
         "node_name": "Compute2",
         "server_port": 50001,
         "veth": "eth0"
      },
      ......
      {
         "local_ip": "<IP_ADDRESS>",
         "node_id": "7fa7f9b8-8ce5-4c61-9a09-a739eeb965ac",
         "mac_address": "00:A0:C9:14:C8:4F",
         "node_name": "Compute19",
         "server_port": 50001,
         "veth": "eth0"
      }
   ]
}

@haboy52581 This PR has been active for one week. Based on the ETA committed by you in the email communication and also mentioned again in today's sync up meeting, I would expect this PR ready for merge by the end of today, to catch the release train.

This PR involves lots of work and also has related new issues during the investigation #349 , I finished most of the work but due to fixed in #349 I have to change more test cases which has to take more time (at least day)


Updated stable and latest versions to v0.6.0

Fixes https://github.com/kubeflow/website/issues/953

This change is

/assign @kunmingg

Preview of pages where these shortcodes are used:

https://deploy-preview-954--competent-brattain-de2d6d.netlify.com/docs/other-guides/upgrade/
https://deploy-preview-954--competent-brattain-de2d6d.netlify.com/docs/use-cases/gitops-for-kubeflow/

/lgtm
/approve


RxBleScanRecordMock missing in maven artifact

Describe the bug
The class RxBleScanRecordMock is missing and the example at https://github.com/Polidea/RxAndroidBle/tree/master/mockrxandroidble#example does not compile.
To Reproduce
Steps to reproduce the behavior:

Include MockRxAndroidBle as described under Download via Gradle
See error "Cannot resolve symbol 'RxBleScanRecordMock'"

Expected behavior
All classes under src/main/java/com/polidea/rxandroidble2/mockrxandroidble/ should be in the aar artifact.
Smartphone (please complete the following information):
N/A, unit tests
Logs from the application when bug occurs (this will greatly help in quick understanding the problem)
N/A
Additional context
Downloaded mockclient-1.11.1.aar from https://mvnrepository.com/artifact/com.polidea.rxandroidble2/mockclient/1.11.1 and inspected it. RxBleScanRecordMock is missing.

I believe this is because there has not been a recent release. In addition, there hasn't been a snapshot recently either. I could really do with this too!

@nrbrook Many thanks! I am actually trying to use RxAndroidBle for testing only, so this could be a workaround for me. @dariuszseweryn Excuse my confusion, but the artifact version (mockclient-1.11.1.aar) suggests that the classes in the maven repo are the same as the version with the same tag (1.11.1) in the source code repo. If there will be a release from 1.11.1 source code what version will the artifact have?

@SwDevElatec Hi, you can check out my comment here on how to get these classes via gradle!

https://twitter.com/dseweryn/status/1369016230095511554?s=21

Just released a regular 1.12.0. Cheers!


Sorting of API Results

@ramonaspence I'm not sure if this is a result of the API rework, or if I'm missing something.
I noticed events on the OpenWorks dashboard aren't in time order and I see the results in the API aren't, which is why.
I'm assuming this is related to the recent PR.  Do you think we were previously sorting the results by the event date?
https://events.openupstate.org/api/gtc

Oh I see! Okay, I added a function to sort by time before it gets formatted for JSON or JSON+LD
I retested it in Postman, so I'll go ahead and create a pull request and let you review/re-test it.


Added word length options and Python 3 support

Nice improvements, thanks! I'll quickly test these out and merge as soon as I can.

sounds good.  These are just additional options for length.


Feature Request: Enhanced Capabilities for GitHub Copilot

Summary:
I would like to request additional features for GitHub Copilot that would enhance its functionality and make it more powerful. Specifically, I propose giving Copilot access to the internet and the ability to create multiple files at once while also understanding the relationship between them.
Description:

Internet Access:

Currently, Copilot relies on a pre-trained model to generate code suggestions. However, it would greatly benefit from having access to the internet to fetch real-time information, libraries, and code examples from reputable sources.
By incorporating internet access, Copilot could provide more up-to-date and accurate code recommendations based on the latest best practices and community standards.

Multi-file Creation:

Copilot's current capability is primarily focused on generating code snippets within a single file. It would be useful if Copilot could expand its functionality to create multiple related files simultaneously.
For example, if a user needs to scaffold a web application or a complex software project, Copilot could generate not only the main file but also accompanying files such as configuration files, templates, and utility modules.

Understanding File Relationships:

Alongside multi-file creation, it would be beneficial if Copilot could understand the relationships between different files within a project.
Copilot should be able to recognize dependencies, imports, and connections between files, allowing it to provide more context-aware and meaningful code suggestions.
This enhanced understanding of file relationships would enable Copilot to generate more comprehensive and accurate code snippets that fit seamlessly into the project structure.

Motivation:
These proposed enhancements to GitHub Copilot would significantly improve its capabilities and make it an even more valuable tool for developers. Internet access would allow Copilot to tap into a vast array of resources, ensuring it provides modern and reliable code suggestions. The ability to create multiple files and understand their relationships would enable Copilot to assist in large-scale project development, saving developers time and effort.
Thank you for considering this feature request. I believe that implementing these enhancements would make GitHub Copilot an even more indispensable tool for developers worldwide.
Best regards,
Pierre

Internet Access: #299 A limited list of sources of sites where there is relevant documentation could be established.

Totally agree! Fully support the idea of adding a feature to Github Copilot Chat that allows it to search the internet during conversations, summarize the latest knowledge, and provide answers. Even if it can only search for new content within GitHub, it would be sufficient to meet the needs.

I would also advocate for Copilot to be able to search for more up-to-date sources of data on the internet, whether that could be another slash command or even picking on the keyword latest, dependent on context of the prompt question.
I understand that re-training the model beyond the static September 2021 data can be expensive and time-consuming, but I believe there must be some sort of solution to overcome the rapid evolution of up-to-date frameworks / APIs, as to ensure Copilot suggestions are as accurate as possible over time, keeping in line with such advances in languages and tech stacks.
At the moment, Copilot is not giving me reliable suggestions based on latest API changes and updates, where Copilot fails to suggest the usage of the toSorted() JavaScript array method that was released in ECMAScript 2023 to immutably sort an array. Or the newly recommended approach to force a component to be server-side dynamically rendered in Next.js version 14 API changes using export const dynamic = 'force-dynamic'
At the moment, it seems like Copilot (OpenAI) is still stuck with data that is cut-off up to September 2021..
Those who do not keep up-to-date of latest API changes would otherwise be given out-of-date, non-optimal suggestions, or at worst no longer working suggestions.
Or for those who generally are aware of and keep up with tech stack / language evolution with a better sense of awareness and skepticism, then they may well have to refer back to Google / StackOverflow / Vendor API Documentation for correct solutions. In such cases, I believe this in part contradicts one of the core goals of Copilot, which is to aim to reduce the need to search / verify for such solutions outside of Copilot, and stay within the context of the Copilot embedded IDE (e.g. VS Code) as much as possible.

Understanding File Relationships:
Alongside multi-file creation, it would be beneficial if Copilot could understand the relationships between different files within a project.
Copilot should be able to recognize dependencies, imports, and connections between files, allowing it to provide more context-aware and meaningful code suggestions.
This enhanced understanding of file relationships would enable Copilot to generate more comprehensive and accurate code snippets that fit seamlessly into the project structure.

This could be so useful!
Besides, currently Copilot does not scan all the files in the folder / workspace. When I ask questions like "Return the list of Python files are in the folder?" It only lists half of them. My repository is not that big, with 10 Python files and 10 json files in total. This should exceed the token limit IMO.


Add primitives with adjacency information

Fixes #1152 by adding additional variants to Primitive.

Looks great, thanks @tocubed !
@homu r+

:pushpin: Commit d87d688 has been approved by kvark

:hourglass: Testing commit d87d688 with merge 827deea...

:sunny: Test successful - status


Glamour WithAutoStyle breaks List

I'm trying to render a list and a markdown file at the same time. When I create the glamour renderer using glamour.NewTermRenderer and WithAutoStyle it breaks the list. Once the list and glamour viewport appear then the list tries to filter by this weird value - terminal becomes virtually unresponsive but spamming esc + q eventually closes the app

Removing WithAutoStyle stops this - but I guess I'll have to beautify the glamour myself :(

Looks like using glamour's Render function alone resolves this issue and displays the markdown with styling and doesn't break the list!
str, _ := glamour.Render(markdown_template, "dark")


Safari back history titles not written, when using HTML5 history

Reproduction
https://codesandbox.io/s/cold-tree-vb8sku?file=/src/router.js
Steps to reproduce the bug

Use Safari
From the repro link, go to the deployed preview website - https://vb8sku.csb.app/
Click on the links a few times in the page
Assert that when you hold down the back arrow in the browser, to see the list of history items, none of them have titles.

Expected behavior
Page titles should be stored in the Safari history, when holding down the back arrow
Actual behavior
Titles are lost and we only see the urls instead. This only happens in Safari.

Additional information
This is caused by passing an empty string as a second parameter in the replaceState/pushState methods.
https://github.com/vuejs/router/blob/fb2bef43232badd41dd28d01f7efeb4f957e61e8/packages/router/src/history/html5.ts#L232
I know that MDN suggests the second param is unused, but Safari does in fact use it. If we pass document.title instead, like in Vue Router 3, this problem is no longer there.

It's not just that MDN suggests it, it's per spec 😅 (https://html.spec.whatwg.org/multipage/nav-history-apis.html#the-history-interface). This is more of a Safari bug: it could maybe fallback to document.title if an empty value is passed. That way it would just align with other browsers.
BTW v3 also passes an empty string: https://github.com/vuejs/vue-router/blob/3d026ea14f8f8fd93da73889d2bcd2103d44bec7/src/util/push-state.js#L37.
Also, setting it to document.title would mark it with the title of the current page instead of the upcoming page, so it would be even more confusing. I'm open to suggestions but given the niche case, they must be very lightweight and functional and I don't think there is any without changing the existing API. One could always implement a custom history that overrides that value though

Hmm... this is not an issue with router v3, but you are right, an empty string is also passed there.
Compared to V3, could it be the extra replace that is called, to add metadata to the page? - https://github.com/vuejs/router/blob/main/packages/router/src/history/html5.ts#LL288C5-L288C5

Maybe! It is a really important line though, so it cannot be removed.
Given how this is a Safari-specific behavior (or bug) I can't really tell. If you really care about this, I think you can give it some research and maybe there is something that could be improved in vue router. Otherwise, I think we will have to hope for Safari to fix it and align with other browsers (usually works as an argument if you open a ticket in webkit).
I'm closing this as a wontfix but will keep an eye on comments if anything changes and makes it possible to fix!


PRs for stable backporting: 10

PR: 20520 -- Reference datapath metrics in feature and troubleshooting guides (@aditighag) -- https://github.com/cilium/cilium/pull/20520
Merge with 2 commit(s) merged at: Wed, 28 Sep 2022 13:53:28 +0000!
Branch:     master (!)                          refs/pull/20520/head
----------                          -------------------
-- Clean Merge
v (start)
|  22cf89a475af725a27a5b3688c2fce9dc90cf2cb via 78f9615c9040b92bcba513e60e598dfa7243c02a ("docs: Reference terminating endpoints metric in kube-proxy free guide")
|  18ef60772318c707a72a44e32eee6ac99485c131 via 167c7680a84aae53e2b9d5445bcfe444c8642b92 ("docs: Reference conntrack metrics in troubleshooting guide")
v (end)

PR: 21495 -- alibabacloud: fix incorrect instance-type reported by cilium-agent (@ArthurChiao) -- https://github.com/cilium/cilium/pull/21495
Merge with 1 commit(s) merged at: Thu, 29 Sep 2022 21:23:18 +0000!
Branch:     master (!)                          refs/pull/21495/head
----------                          -------------------
-- Clean Merge
v (start)
|  5b411027eed3c06fafc6c74f61263af630cd23f6 via 50ea506016c0372a653599ad55b8bf6dee7c96d4 ("alibabacloud: fix incorrect instance-type reported by cilium-agent")
v (end)

PR: 21463 -- helm: Quote operator and etcd-operator image fields (@michi-covalent) -- https://github.com/cilium/cilium/pull/21463
Merge with 1 commit(s) merged at: Fri, 30 Sep 2022 08:10:28 +0000!
Branch:     master (!)                          refs/pull/21463/head
----------                          -------------------
-- Clean Merge
v (start)
|  5b40396716893b50616026f41f3f7d5836de61d4 via 5be1df7d7e5e357c714ccbb06baecafe6e11b23d ("helm: Quote operator and etcd-operator image fields")
v (end)

PR: 21461 -- ipsec: Refactoring around UpsertIPsecEndpoint (@pchaigno) -- https://github.com/cilium/cilium/pull/21461
Merge with 4 commit(s) merged at: Tue, 04 Oct 2022 10:19:54 +0000!
Branch:     master (!)                          refs/pull/21461/head
----------                          -------------------
-- Clean Merge
v (start)
|  8ae15622379b2b2614eee0864c714f46b3cf66cd via c15aee58ec5d71a7eafbc6b8f8e62487501c948a ("ipsec: Simplify DeleteIPsecEndpoint parameter")
|  3fe791905a098ca5f729933d0a5593c812dc218f via 8613c669fce11ae1847758b2d27a59485b44f0f1 ("ipsec: Rename variables in enableIPsec")
|  91fdc20faa8496fc57b157db87aad760418329df via 07c03cbebe2249d09d231e501932c529341de8d5 ("ipsec: New arguments for UpsertIPsecEndpoint")
|  645da8065170baf7933c18b1b565e02757416e3a via 23051acd0a85d503216aea43bb1649794552ec9f ("ipsec: Simplify UpsertIPsecEndpoint CIDR arguments")
v (end)

PR: 21497 -- bugtool: Fix pprof default ports (@pippolo84) -- https://github.com/cilium/cilium/pull/21497
Merge with 1 commit(s) merged at: Tue, 04 Oct 2022 10:25:59 +0000!
Branch:     master (!)                          refs/pull/21497/head
----------                          -------------------
-- Merge Conflict - daemon/cmd/daemon_main.go, operator/flags.go
-- @pippolo84 - Please confirm changes look good.
v (start)
|  b33adeb6f88701979d98095149d6ecb359dc8812 via 9e1917d470cfbc670dcd0f05bc3824c9ef983079 ("bugtool: Fix pprof default ports")
v (end)

PR: 21565 -- ipcache: Fix metadata access from CIDR allocation (@joestringer) -- https://github.com/cilium/cilium/pull/21565
Merge with 1 commit(s) merged at: Tue, 04 Oct 2022 22:40:54 +0000!
Branch:     master (!)                          refs/pull/21565/head
----------                          -------------------
-- Merge Conflict - skipped due to complexity
-- @joestringer - does not merge cleanly and not sure context for change.
v (start)
|  021ea42e6f8cfbb139286db88c4d5e2f84dac93f via 3f27143b048479157c24d2e8a07791ea77f5e8d1 ("ipcache: Fix metadata access from CIDR allocation")
v (end)

PR: 21577 -- contrib: avoid reviews from non-collaborators (@bimmlerd) -- https://github.com/cilium/cilium/pull/21577
Merge with 1 commit(s) merged at: Wed, 05 Oct 2022 09:31:54 +0000!
Branch:     master (!)                          refs/pull/21577/head
----------                          -------------------
-- Clean Merge
v (start)
|  5520be196693d7fce495a91fbf21e3838d5e7343 via 7a7137c5e27d6d6e5a87311205d3a00fd059c67b ("contrib: avoid reviews from non-collaborators")
v (end)

PR: 21588 -- test: fix up the number of pods in DemoDaemonSet (@julianwiedmann) -- https://github.com/cilium/cilium/pull/21588
Merge with 1 commit(s) merged at: Wed, 05 Oct 2022 17:19:48 +0000!
Branch:     master (!)                          refs/pull/21588/head
----------                          -------------------
-- Clean Merge
v (start)
|  1019e700a3eba4f8372c7449a7b231a0e3c7c606 via ab5d9640f3b99754f5cb9b91dfb5c4379f86e94f ("test: fix up the number of pods in DemoDaemonSet")
v (end)

PR: 21499 -- bpf: always track egress gateway connections (@jibi) -- https://github.com/cilium/cilium/pull/21499
Merge with 6 commit(s) merged at: Thu, 06 Oct 2022 00:16:26 +0000!
Branch:     master (!)                          refs/pull/21499/head
----------                          -------------------
-- Merge Conflicts
@jibi - lots of merge conflicts on almost every commit, mostly in nat.h. Please review
v (start)
|  453299601c8c5747deb0b004325db796a2fd31f9 via d2684bbe307896bc4b0b9181fa8e22b096e4b56c ("bpf: nat: always track egress gateway connections")
|  19c2d5999caa6733635f654a69aca33f2d1c679d via 1d53231593a2a8426448096215bcb4af03643407 ("bpf: nat: rename snat_v6_track_local to snat_v6_track_connection")
|  c62b2094dbec32a33259fb436b6e3ab1939b9766 via 2657214f2950ddf82cb93ae71c7e93725d401e37 ("bpf: nat: move snat_v{4,6}_needed into lib/nat.h")
|  658045e8a30d070db40ad2c0769dc7a01ed9328c via 159169fcaa919a528238f8305c62c6e74d26e382 ("bpf: nat: fix from_endpoint assignment")
|  59ac84f65d2c14fdf8038b29a53b2d1a87f18598 via 95a10c1fb331f55d63cc2ef46dac4066e4bdf37d ("bpf: nat: consolidate snat_v4_needed() state into ipv4_nat_target")
|  f9697d2eefab4a3f81668ee8798ccd4ed7395bb1 via 57448a303cb775f475565e37a93fc99cc7ddd077 ("bpf: nat: use target->from_local_endpoint in snat_v4_track_connection()")
v (end)

PR: 21444 -- plugins/cni: wait for AWS to drop its CNI configuration file (@squeed) -- https://github.com/cilium/cilium/pull/21444
Merge with 1 commit(s) merged at: Thu, 06 Oct 2022 00:16:55 +0000!
Branch:     master (!)                          refs/pull/21444/head
----------                          -------------------
-- Clean Merge
v (start)
|  d45999d5bded78590c19a670601f9c486dc0cba0 via 8b55f3fba8f9a682d0cfe749bc40213140e55ad2 ("plugins/cni: wait for AWS to drop its CNI configuration file")
v (end)

✅ ack on https://github.com/cilium/cilium/pull/21610/commits/a2534e4092f644819eaf64486478794223f167c8 thanks @ldelossa ! ❤

@jibi looks like I left a git diff marker in the commit, will fix momentarily.

force-pushed the pr/v1.12-backport-2022-10-06 branch from 945019a to 80a76e5 40 seconds ago

@jibi ^ force push removed git diff markr.

@joestringer ah, i think i may have deleted the original generated file the script generates. I kept my own copy and used that as input to the branch creation script.

@ldelossa I see. The general format of the description doesn't matter to me, but either way please ensure that the PR description has that upstream-prs snippet :pray:

Yup will do.

ci-awscni and ci-aks passed all good for my commit!

/ci-eks-1.12

@squeed These will all get tested as part of CI once Louis triggers it.

@joestringer fixed upstream code block. :heavy_check_mark:

dropped https://github.com/cilium/cilium/pull/21499 as per offline discussion.

Due to permission to forked repo, replace this by https://github.com/cilium/cilium/pull/21631


Now data is recieved as json in api

Now data is received as json in api
Previously data was extracted as form data
Change route of requests to flask route
Fixes https://github.com/scorelab/fact-Bounty/issues/156

@root5533 fixed issue of request

@Anmolbansal1 there are few issues with coding standards. Please view them through Codacy and fix.

@root5533 done!!


Correct small typo in CRYPTO_GET_REF

Previous commit was flagged red by travis for this exact reason. Why wasn't it addressed then? Are we just wasting resources?
And I fail to see why does it have to be addition of 0. As well as what does one need this function for (is there meaningful decision that you can make based on counter value when you don't change it?).

Previous commit was flagged red by travis for this exact reason. Why wasn't it addressed then? Are we just wasting resources?

We are humans, sometimes something looks so self evident that we miss details.  So no, generally speaking, I don't think we are wasting resources, and quite frankly, I don't see why the relatively few anecdotes like this one should make you think otherwise.

And I fail to see why does it have to be addition of 0. As well as what does one need this function for (is there meaningful decision that you can make based on counter value when you don't change it?).

Say you have a reference counter associated with object FOO, and you want to allow freeing FOO only when the reference counter is zero.
static whatever *FOO;
static CRYPTO_REF_COUNT FOO_refs = 0;
static CRYPTO_RWLOCK *FOO_refs_lock = NULL;

int destroy_FOO(void)
{
    int i;

    CRYPTO_GET_REF(FOO_refs, &i, FOO_refs_lock);
    if (i != 0)
        return 0;
    OPENSSL_free(FOO);
    return 1;
}

Merged.  c27bc74698ed043b7549d5637ec0a8cf65b39e59

So no, generally speaking, I don't think we are wasting resources.

Of course I don't suggest that we generally do, it was just a rhetoric expression to call upon everybody, not you personally, to be more attentive. What can be simpler than to look at ci summary? Why can't/shouldn't you take it personally or refer to human fallibility? One of major points with review requirement is to eliminate the human fallibility factor.

relatively few anecdotes like this one

Well, what can I say, I felt compelled to say it, i.e. I don't feel that it was few enough not to bring it up. One can argue that it shouldn't have been brought up in any specific context, in which case apologies. It just was so glaring simple to avoid...

Yes, I agree, it was glaringly simple, and I am embarassed.

static whatever *FOO;

This is inadequate example. Because in order to be able to do as suggested, you have ensure that nobody can read the FOO between you read reference counter and pointer is invalidated. I mean let's say somebody increases reference counter right after you've read it, but before free happens. Right thing to do would be to protect reference to FOO with lock(*), but then you should be able to just read reference counter without any special call. Bottom line is that this is not common usage pattern for reference counters. Common usage pattern is to pass non-static pointer and have last one to decrement reference counter to zero free the object. I mean you have to actually decrement counter to make decision, you can't make decision on just read value...
(*) This implies that there is "give me FOO" and "release FOO" subroutines that claim lock, in which case they can as well just operate on reference counter directly. Since it's already serialized.

Hmmm, good point.

#3576

This one should be closed now that the original was reverted, right?
(The only use case I could easily see for CRYPTO_GET_REF() would be for debugging output, which would be enough of a use case for me, since mixing atomic and non-atomic accesses is a bad idea.)

But, err, it is closed...


insertSpaceBeforeFunctionParenthesis setting is not working for standard function

Platform: macOS
Vetur version: 0.7.0
VSCode version: 1.12.2

I have the following config setting:
"vetur.format.js.InsertSpaceBeforeFunctionParenthesis": false

when formatting the following code:
<script>
var add = function (a, b) {
  return a + b;
};

export default {
  name: 'hello',
  methods: {
    login(event) {
      console.log(event);
    }
  },
  data() {
    return {
      msg: 'Welcome to Your Vue.js App!!!' + add(12, 14)
    };
  }
};
</script>

It removes correctly the spaces in login or data, but it adds a space before parenthesis in the standard add function.
PS: When vetur.format.js.InsertSpaceBeforeFunctionParenthesis is true everything is consistent

Thanks. I can confirm it's working as expected in ts file but not vue file.

That space is controlled by InsertSpaceAfterFunctionKeywordForAnonymousFunctions in TS formatter setting, not InsertSpaceBeforeFunctionParenthesis.
I've made it so that InsertSpaceBeforeFunctionParenthesis would control both, so now Vetur should be consistent for space before function. Will be available in 0.9.5.

Hi i'm on Vetur 0.10.1 and I don't see InsertSpaceBeforeFunctionParenthesis in config options

@BruceHem

set vetur's default formatter to "vscode-typescript"
and then set "javascript.format.insertSpaceBeforeFunctionParenthesis" to "true"

"vetur.format.defaultFormatter.js": "vscode-typescript",
"javascript.format.insertSpaceBeforeFunctionParenthesis": true


Added one Useful Link

Hey, I have added a reference link for the

Hey, we expect anybody who works with our SDK knows the basics of HTML and CSS.
I'm going to close this PR.


fix: remove unnecessary InvalidDocumentTypeError handling

Issue being fixed or feature implemented

Need to remove InvalidDocumentTypeError from unserializeStateTransition method, because it was a hardfix for a bug.
What was done?

Removed unnecessary InvalidDocumentTypeError handling from unserializeStateTransition method
How Has This Been Tested?

Unit tests
Breaking Changes

No
Checklist:

[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have added or updated relevant unit/integration/functional/e2e tests
[x] I have made corresponding changes to the documentation

For repository code-owners and collaborators only

[x] I have assigned this pull request to a milestone

@shuplenkov we should update DPP here. I would try to use "0.16-dev" channel for that https://www.npmjs.com/package/@dashevo/dpp


Depth stream

https://mexcdevelop.github.io/apidocs/spot_v3_en/#diff-depth-stream

Published under 0.5.0 on crates.io


remove trailing slash from #57

'T was the only entry with a trailing slash in the link label
as displayed on the site.
Follows-up 62a525da5c5005.

Fixed in d38ff36


Add CI github actions

now it's on test

Good!!!!!!!

When running unit test on Github Actions, the "testAdditionalAuthenticationChecks" test is failed.
If run the tests in org.ngrinder.security packages only, all the tests are succeed.
If run all the tests in ngrinder-controller module, the only one test, "testAdditionalAuthenticationChecks" is failed.
It seems like an issue caused by modifying security context on the other test. But, it's pretty hard to find out.

Test was crashed becuase the test user account's password was encoded twice.
Default test user information

ID: TEST_USER
Password: 123
Encoded Password: c96aadc66c909133e634a4f19f255290a00cd83d (SHA-1 hash result of 123{TEST_USER}

And the encoded password when the test is failed is b525fa2966b3f37e91f4cb66534c5630c8d363d7 which is SHA-1 hash result of c96aadc66c909133e634a4f19f255290a00cd83d{TEST_USER}.
After removing the updating test user account having password, the test "testAdditionalAuthenticationChecks" will success.


Send concatenated SMS after completion

"They will receive the success/failure text as a concatenated SMS after completion to use as a reference"

Example: https://github.com/praekelt/mama-ng-jsbox/blob/develop/src/utils_project.js#L641-L680

@imsickofmaps please review.

👍


[hotfix][doc] Fix typo of SlotManager javadoc

What is the purpose of the change
Fix typo of SlotManager JavaDoc

cc @TisonKun


FOGL 5891

TODO

Change documentation for Fledge.
Change documentation for flir and FogLAMP.
Make changes in system tests of CSV writer filter.
Make changes in system tests of this plugin.

Tests are passing. Merging this branch. Documentation will be added in other branch named fogl-5891.docs.


Change Architecture

Evaluate if we need to change the inheritance architecture to this

see how to write this diagrams here

We can also append the virtual move constructor


[SR-12405] Can't download swift-5.2-RELEASE-osx-symbols.pkg

Previous ID
SR-12405

Radar
None

Original Reporter
@norio-nomura

Type
Bug

Environment
swift-5.2-RELEASE for macOS
swift-5.2.1-RELEASE for macOS

Additional Detail from JIRA

Votes
0

Component/s
Project Infrastructure

Labels
Bug

Assignee
@shahmishal

Priority
Medium

Watchers: @shahmishal
md5: 0dd477438a375d408f692746a7a05c95

Issue Description:
When I download swift-5.2-RELEASE-osx-symbols.pkg, it stops at 2048MB every time.

This issue should be resolved, please try new domain. (download.swift.org)


[ISSUE #2873] add benchmark for batch message

What is the purpose of the change

Add benchmark test for batch message sending.

Brief changelog

Add BetchProducer.

Verifying this change

Follow this checklist to help us incorporate your contribution quickly and easily. Notice, it would be helpful if you could finish the following 5 checklist(the last one is not necessary)before request the community to review your PR.

[x] Make sure there is a Github issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a Github issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[x] Format the pull request title like [ISSUE #123] Fix UnknownException when host config not exist. Each commit in the pull request should have a meaningful subject line and body.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[x] Write necessary unit-test(over 80% coverage) to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
[x] Run mvn -B clean apache-rat:check findbugs:findbugs checkstyle:checkstyle to make sure basic checks pass. Run mvn clean install -DskipITs to make sure unit-test pass. Run mvn clean test-compile failsafe:integration-test  to make sure integration-test pass.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

Coverage increased (+0.09%) to 51.927% when pulling 9c2252be19e7967f8f1e21121271508f535f9421 on Git-Yang:benchmark_batch into b4240d5cea8d001c21b9c0d73f5aa700fcd0d568 on apache:master.

pls merge to apache:develop, not master

Codecov Report

Merging #2876 (c6011cf) into develop (03c1f11) will increase coverage by 0.12%.
The diff coverage is 73.17%.

:exclamation: Current head c6011cf differs from pull request most recent head 67c2dbf. Consider uploading reports for the commit 67c2dbf to get more accurate results

@@              Coverage Diff              @@
##             develop    #2876      +/-   ##
=============================================
+ Coverage      45.88%   46.00%   +0.12%
- Complexity      4315     4321       +6
=============================================
  Files            547      547
  Lines          36031    36236     +205
  Branches        4783     4808      +25
=============================================
+ Hits           16532    16671     +139
- Misses         17430    17477      +47
- Partials        2069     2088      +19

Impacted Files
Coverage Δ
Complexity Δ

...pache/rocketmq/client/common/ThreadLocalIndex.java
100.00% <ø> (+25.00%)
4.00 <0.00> (ø)

...r/rebalance/AllocateMessageQueueByMachineRoom.java
0.00% <0.00%> (ø)
0.00 <0.00> (ø)

...main/java/org/apache/rocketmq/store/CommitLog.java
66.52% <28.57%> (-0.97%)
79.00 <0.00> (-1.00)

...pache/rocketmq/store/dledger/DLedgerCommitLog.java
73.70% <75.44%> (+1.36%)
72.00 <15.00> (+15.00)

...ocketmq/client/impl/producer/TopicPublishInfo.java
58.13% <100.00%> (+16.27%)
13.00 <0.00> (+2.00)

...nt/producer/selector/SelectMessageQueueByHash.java
100.00% <100.00%> (+33.33%)
3.00 <2.00> (+1.00)

...ain/java/org/apache/rocketmq/common/MQVersion.java
99.83% <100.00%> (ø)
5.00 <1.00> (ø)

.../main/java/org/apache/rocketmq/common/UtilAll.java
36.36% <100.00%> (+1.59%)
41.00 <0.00> (-3.00)
:arrow_up:

.../apache/rocketmq/logging/inner/LoggingBuilder.java
63.60% <100.00%> (ø)
3.00 <0.00> (ø)

...rg/apache/rocketmq/common/stats/StatsSnapshot.java
84.61% <0.00%> (-15.39%)
7.00% <0.00%> (-2.00%)

... and 24 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 03c1f11...67c2dbf. Read the comment docs.