Dependencies and Spring profiles

Hello,
First things first: thanks for the great integration. It took me only several minutes to get everything working.
Nevertheless, I have encountered something a little bit annoying.
Actually I have two different datasources, each one linked to a specific Spring profile. One is for deployment on AppEngine using Cloud SQL and another one for localhost using H2 in memory database.
The thing is that even if I load my Spring localhost profile, I loads any dependencies of the spring-cloud-gcp-starter-sql-postgresql (or maybe is it the postgres-socket-factory ?) into the classpath resulting in some requirements : developers now needs to launch the gcloud auth application-default login command in order to log in and generate an access token for the GCP while it is not needed.
Here is my application.yml file and my application-local.yml file for some more context:
spring:
  datasource:
    username: <username>
    password: <password>
 cloud:
    gcp:
      sql:
        database-name: <db-name>
        instance-connection-name: <instance-connection-name>

and
spring:
  datasource:
    driver-class-name: org.h2.Driver
    username: sa
    password:
    url: jdbc:h2:mem:test;DB_CLOSE_DELAY=-1

and in the logs:
2018-05-11 21:54:56.687  INFO 9775 --- [           main] o.s.c.g.a.s.GcpCloudSqlAutoConfiguration : Default POSTGRESQL JdbcUrl provider. Connecting to jdbc:postgresql://google/taggy-db?socketFactory=com.google.cloud.sql.postgres.SocketFactory&socketFactoryArg=x-ripple-200920:europe-west1:taggy&useSSL=false with driver org.postgresql.Driver
2018-05-11 21:54:56.691  WARN 9775 --- [           main] o.s.c.g.a.s.GcpCloudSqlAutoConfiguration : spring.datasource.driver-class-name is specified. Not using generated Cloud SQL configuration
2018-05-11 21:54:56.691  WARN 9775 --- [           main] o.s.c.g.a.s.GcpCloudSqlAutoConfiguration : spring.datasource.url is specified. Not using generated Cloud SQL configuration
2018-05-11 21:54:56.977  INFO 9775 --- [           main] j.LocalContainerEntityManagerFactoryBean : Building JPA container EntityManagerFactory for persistence unit 'default'
2018-05-11 21:54:56.989  INFO 9775 --- [           main] o.hibernate.jpa.internal.util.LogHelper  : HHH000204: Processing PersistenceUnitInfo [
	name: default
	...]
2018-05-11 21:54:57.052  INFO 9775 --- [           main] org.hibernate.Version                    : HHH000412: Hibernate Core {5.0.12.Final}
2018-05-11 21:54:57.054  INFO 9775 --- [           main] org.hibernate.cfg.Environment            : HHH000206: hibernate.properties not found
2018-05-11 21:54:57.055  INFO 9775 --- [           main] org.hibernate.cfg.Environment            : HHH000021: Bytecode provider name : javassist
2018-05-11 21:54:57.097  INFO 9775 --- [           main] o.hibernate.annotations.common.Version   : HCANN000001: Hibernate Commons Annotations {5.0.1.Final}
2018-05-11 21:54:57.208  INFO 9775 --- [           main] org.hibernate.dialect.Dialect            : HHH000400: Using dialect: org.hibernate.dialect.H2Dialect
2018-05-11 21:54:57.741  INFO 9775 --- [           main] org.hibernate.tool.hbm2ddl.SchemaExport  : HHH000227: Running hbm2ddl schema export
2018-05-11 21:54:57.768  INFO 9775 --- [           main] org.hibernate.tool.hbm2ddl.SchemaExport  : HHH000230: Schema export complete

To avoid adding Maven profiles to exclude dependencies, it may be interresting to add a parameter to load your dependencies.
Maybe I am doing something wrong though.

Hello @MadJlzz, thanks for your report!
As your log points out, the URL and driver class name you provided are being used, so there should be no need to set the credentials.
Can you please paste the error you're seeing?
If your application doesn't need credentials, Spring Cloud GCP will log an error saying they weren't found, but the application starts up anyway. I suspect this should be your case.
We're going to do something about that error message but, for now, you could try to add this bean to get rid of the error log entry:
	@Bean
	public CredentialsProvider noCredsProvider() {
		return new NoCredentialsProvider();
	}

Let me know if it helps.

#670 tunes down the lack of core credentials messaging so that users don't feel there is an issue with their app.

Hello,
I apologize for the late answer but I've been really busy working the GCP cloud architect certification. I was not able to reproduce the error but it seems that it happens when the token saved by default in ~/.appcfg_oauth2_tokens_java doesn't exist.
I will test some cases to reproduce it though and try your solution.

@MadJlzz let me backtrack a little bit: using OAuth2 authentication with the Spring Cloud GCP for Cloud SQL is the expected flow.
You will either have to authenticate with application default credentials using Cloud SDK or download a service account private key and use the spring.cloud.gcp.credentials.location or spring.cloud.gcp.sql.credentials.location property.
The upside of this is that you don't need to open your SQL instance to any IPs on the internet. Using a SQL username and password also becomes somewhat optional, since the main authentication is the one done by OAuth2.
Will close since it's working as intended. Please feel free to reopen if you have any further questions.


Password Jupyter

dbgap2x password provided in the documentation doesn't work.

There was a confusion between the docker hub image located on dbmi repo and the original one that has the correct password. We will update it.


2 Questions about Parsing

Why does Grammar::parse_input have a return type of impl Iterator<Item = ParseTree> and not of Option<ParseTree> or Result<ParseTree, Error>? Is there any circumstance in which Grammar::parse_input could parse to multiple ParseTrees?

I know that I can access the data in a ParseTree by calling ParseTree::rhs_iter to get something of type ParseTreeIter, which implements Iterator<Item = &ParseTreeNode>. I can then iterate through this to get items of type &ParseTreeNode, but how can I get the data out from this? src/lib.rs only publicly exports Grammar and ParseTree from src/grammar.rs, and I cannot construct the variants of the externally private ParseTreeNode necessary to match ParseTreeNodes and access the data stored within.

Hey @Axiomatic-Mind 👋 as to your first question, whether parse_input returns a list of parse trees or not is mostly up to your grammar, and things like grammars for programming languages usually shouldn't have ambiguous ways to interpret a sentence. But grammars for natural language can be full ambiguities that can lead to multiple parse tree. My personal favorite example of the kind of sentence that would lead a parser like this to return multiple trees is "Time flies like an arrow". Where we're either talking about the concept of time moving quickly, or something more like a plot line from Doctor Who, i.e. "Time flies like an arrow. Fruit flies like a banana."
As to your second question, it's a great point! ParseTreeNode probably needs to be exposed!

Thanks! Embarrassingly, I was trying to get that information by calling format!(“{:?}”, foo) on the output of the parse_input function and using regular expressions to parse it. The lengths to which one will go!

Thanks so much for #106! I've published version 0.4.1 to crates.io now so you should be able to use your changes

Thanks for noticing this issue @Axiomatic-Mind ! totally just an oversight. And double thanks for opening a PR 🙌

My pleasure👍


Question: persistence time

Hi. First, awesome work with hydrated too.
I have a question/issue :thinking:
I'm using hydrated to store if it isn't the first time the app is opening. It works but after some time, like 4 o 5 days, the state is lost.
I'm using hydrated incorrectly?
class MainBloc extends HydratedBloc<MainEvent, MainState> {
  @override
  MainState get initialState =>
      super.initialState ?? MainState(true, false);

  @override
  Stream<MainState> mapEventToState(
    MainEvent event,
  ) async* {
    if (event is DisableFirstTime) {
      yield MainState(false, currentState.logged);
    }
  }

  void dispatchDisableFirstTime() {
    dispatch(DisableFirstTime());
  }

  @override
  MainState fromJson(Map<String, dynamic> json) =>
      MainState(json['firstTime'] as bool, json['logged'] as bool);

  @override
  Map<String, dynamic> toJson(MainState state) =>
      {'firstTime': state.firstTime, 'logged': state.logged};
}

class MainState {
  bool firstTime;
  bool logged;

  MainState(this.firstTime, this.logged);
}

class DisableFirstTime extends MainEvent {
  @override
  String toString() => 'DisableFirstTime';
}

Thank you for your time.

Hi @pblinux 👋
Thanks for opening an issue and for the positive feedback!
Regarding your question, out-of-the-box HydratedBlocStorage writes to temporary storage.
/// Path to the temporary directory on the device that is not backed up and is
/// suitable for storing caches of downloaded files.
///
/// Files in this directory may be cleared at any time. This does *not* return
/// a new temporary directory. Instead, the caller is responsible for creating
/// (and cleaning up) files or directories within this directory. This
/// directory is scoped to the calling application.
///
/// On iOS, this uses the `NSCachesDirectory` API.
///
/// On Android, this uses the `getCacheDir` API on the context.

If that doesn't meet your needs, you can always implement your own HydratedStorage by simply implementing the HydratedStorage interface and initializing HydratedBlocDelegate with your custom HydratedStorage.
// my_hydrated_storage.dart

class MyHydratedStorage implements HydratedStorage {
  @override
  dynamic read(String key) {
    // TODO: implement read
  }

  @override
  Future<void> write(String key, dynamic value) async {
    // TODO: implement write
  }

  @override
  Future<void> clear() async {
    // TODO: implement clear
  }
}

// my_hydrated_bloc_delegate.dart

class MyHydratedBlocDelegate extends HydratedBlocDelegate {
 MyHydratedBlocDelegate() : super(MyHydratedBlocStorage());
}

// main.dart

BlocSupervisor.delegate = MyHydratedBlocDelegate();

Hope that helps 👍

Thank you @felangel , that gets me more clear idea of what can I do. Again, thank you.

Good morning, I'm here again to disturb you again :(.
I just noticed Sembast read operations are asynchronous and it makes it impossible for me to get my cached data when I call super.initialState() in my hydratedBloc;
It throws type 'Future<dynamic>' is not a subtype of type 'String'.
How would you approach this?

@felangel is it possible to create custom HydratedStorage, and make it write to getApplicationDocumentsDirectory() instead of getTemporaryDirectory(). Will it persist data, and avoid clearing by OS?

@shamnex hey 👋
Would it be feasible for you to perform an initial asynchronous query in the initialization of the storage client which would read everything into memory? You would then be able to synchronously return values for a given key. It would be very similar to how the built-in HydratedBlocStorage works.
void main() async {
  BlocSupervisor.delegate = await HydratedBlocDelegate.build();
  runApp(App());
}

HydratedBlocDelegate.build(); handles load the data asynchronously into memory.
Let me know if that helps or if it doesn't meet your requirements 👍

Hi @kakajansh 👋
You definitely can but I would be cautious because in the documentation for getApplicationDocumentsDirectory it states:

Path to a directory where the application may place data that is user-generated, or that cannot otherwise be recreated by your application.

Using getApplicationDocumentsDirectory for app cache is technically not what it is intended for.

@shamnex hey 👋
Would it be feasible for you to perform an initial asynchronous query in the initialization of the storage client which would read everything into memory? You would then be able to synchronously return values for a given key. It would be very similar to how the built-in HydratedBlocStorage works.
void main() async {
  BlocSupervisor.delegate = await HydratedBlocDelegate.build();
  runApp(App());
}

HydratedBlocDelegate.build(); handles load the data asynchronously into memory.
Let me know if that helps or if it doesn't meet your requirements 👍

Hello, champ!!! @felangel
I just did what you as you asked and It works perfectly!
Thank you so much for this and keep up the good work.
It takes a lot to maintain an open source project with the level of commitment you show. We appreciate all your efforts man.
Have a lovely weekend.


Add Match Page

Description
Add a basic page for choosing matching criteria and dialogs for finding and retrying to find a match.
Checklist

[ ] I have updated documentation
[ ] All tests passing

Hi just a quick note, our wireframe for match page is slightly outdated. We're no longer including programming language as part of the matching criteria.

Hi just a quick note, our wireframe for match page is slightly outdated. We're no longer including programming language as part of the matching criteria.
Edit:
The UI looks really good 🔥🔥🔥

Haha oops I'll remove it. Thanks for the review 😄


[OP] Embedding

Description
Instead of decomposing embedding into smaller OP we can lower the entire embedding OP to raf embedding. Note that RAF's version of embedding does not accept padding_idx, scale_grad_by_freq, and sparse parameters - these params will be ignored in the current implementation.
Checklist

[ ] PR's title starts with a category (e.g. [BUGFIX], [MODEL], [TUTORIAL], [FEATURE], [DOC], etc)
[ ] Changes are complete (i.e. I finished coding on this PR)
[ ] All changes have test coverage
[ ] Code is well-documented

cc @awslabs/raf-reviewer @zachzzc

thanks @anadeem2


How to update a document with unique index (constraints)?

How to properly update an ArangoDB document with unique index field?
My Environment

ArangoDB Version:        3.4.3
Storage Engine:             RocksDB
Deployment Mode:        Single Server
Infrastructure:               localhost
Operating System:        Fedora 29
Total RAM in your machine:       16GB
Disks in use:                   HDD
Used Package:              official RPM

more details
I posted the whole question and problem on StackOverflow:
https://stackoverflow.com/questions/54916765/how-to-properly-update-an-arangodb-document-with-unique-index-field

Yes, you're right. This missbehaviour was introduced with ArangoDB3.4

Will this be updated? When? What's the proper way to handle this now (update an object with unique constraints)?

yes, thats why I flagged it with 'bug'. The workaround should be clear from the stackoverflow issue? 3.4.4 won't contain a fix for this, its to late in the QA pipeline already.

https://github.com/arangodb/arangodb/pull/8422 will fix this in 3.4 - if you want a fixed environment now, you may try to checkout the branch bug-fix-3.4/arrayindex-unique-update and compile your own arangod.

Hi @robert-zaremba,
version 3.4.5, which includes a fix for this issue, has just been released.
Could you please give it a try?
The latest release is available in the download section.

Closing this issue as fixed. Updating an object with unique constraints works in 3.4.5.
Working arangosh example:
Create collection:
db._create('usersCollection')
[ArangoCollection 106, "usersCollection" (type document, status loaded)]

Add unique index:

db.usersCollection.ensureIndex({ type: "hash", fields: [ "emails[*]" ], unique: true, sparse: true })
{
  "deduplicate" : true,
  "fields" : [
    "emails[*]"
  ],
  "id" : "usersCollection/517",
  "isNewlyCreated" : true,
  "selectivityEstimate" : 1,
  "sparse" : true,
  "type" : "hash",
  "unique" : true,
  "code" : 201
}

Create document entry:
db.usersCollection.save({_key: "1", name: "A", emails<EMAIL_ADDRESS>{
  "_id" : "usersCollection/1",
  "_key" : "1",
  "_rev" : "_Yi26PIa---"

Add email in the "emails" field:
db.usersCollection.update("1", {emails<EMAIL_ADDRESS><EMAIL_ADDRESS>{
  "_id" : "usersCollection/1",
  "_key" : "1",
  "_rev" : "_Yi27SlW--_",
  "_oldRev" : "_Yi26PIa---"
}

Inspect collection:
db.usersCollection.toArray()
[
  {
    "_key" : "1",
    "_id" : "usersCollection/1",
    "_rev" : "_Yi27SlW--_",
    "name" : "A",
    "emails" : [
<EMAIL_ADDRESS>
<EMAIL_ADDRESS>    ]
  }
]

Thanks!


div contents 'jump out' and is organizing by columns, not in-line row

html is set up as:
<ul border blue, display:block, as-sortable="dragListeners">
  <li ng-repeat, border: red, display:inline-block, as-sortable-item>
    <div as-sortable-item-handle>{{stuff}}</div>
  </li>
</ul>

Can anybody please shed some light? I have attached screenshots. Second is when we start to drag move

I have same issue.

Looks similar to the issue I've just raised: https://github.com/a5hik/ng-sortable/issues/364
Might be worth trying the fix I found


CommandBuffer suggestions

I found the commandbuffers implementation not very user-friendly and about this I suggest to merge all the cmdbuffer types into an unique class (not a struct) to emulate the World class.
I see multiple advatanges:

a better and tiny API
users will work with Entity struct only [all the internal changes should be tracked into Arch]

Ugly pseudo code:
struct Transform { public Vector3 Position; }

var world = World.Create();
var cmd = new CommandBuffer(world);

var entity = cmd.Create<Transform>();
ref var transform = ref cmd.Get<Transform>(in entity);
transform.X = 20;

world.Query(in query, (in Entity e, ref Transform t) => {
   if (t.Position == Vector3.Zero)
      cmd.Destroy(in e); // will mark the entity as destroyed and next queries will not grab this entity until the real destruction
  else
    --t.X;

});

Currently not at home, looking at it later... Well this would be way better in terms of usage ^^
Any idea on how the data structure may look like ? All ways that come into my mind make heavy use of dictionarys for lookups which is very bad for performance... Thats why i came up with the current solution.

Some thoughts
Merging the 4 different command buffers into one commandbuffer is totally possible and would provide a cleaner API... so lets put that onto our list. In this case we could continue using the existing buffers.
Would still require manuall playbacks however, since some users may want controll about such "sync" points.
Using only Entity
Is also possible, but would require a lot of dictionary lookups for certain operations. Which would slow the overall queries and usage.
Commandbuffers use other internal structures and therefore need to map the Entity to their buffer arrays. This makes them fast since no lookups are required. The downside of this is that the usage suffers from it.
Outlook
A combined commandbuffer which works on pure Entity structs, while it still requires no lookups and a clean API. Also they should still support managed structs.
We need plenty of ideas for this, since overall this will be a very challenging design task.
For the first it probably makes the most sense to merge the commandbuffers.

The ideal would be to handle changes to the World class directly. Maybe an internal World instance where you put changes that will be merged when the Playback function is called.
(Sorry for the comparision, but i think flecs is a good startpoint): https://github.com/SanderMertens/flecs/blob/master/examples/c/systems/mutate_entity/src/main.c#L15-L24

The ideal would be to handle changes by the World class directly. Maybe an internal World instance where you put changes that will be merged when the Playback function is called.
(Sorry for the comparision, but i think flecs is a good startpoint): https://github.com/SanderMertens/flecs/blob/master/examples/c/systems/mutate_entity/src/main.c#L15-L24
edit: missclicked the close button sorry

I took a look at flecs but couldnt find a clean way to implement this into Arch. Flecs embedds this into the world itself, i do not really like this approach since it destroys several programming principles and creates a big dependency. Of course that approach also has some advantages, but i found it way too hard to maintain in the future.
Instead i looked at your sugessted API usage and implemented something on my own. Its still pretty "ugly", not cleaned up and optimized. But the first version already works, its located inside the "feature/command_buffer" branch : https://github.com/genaray/Arch/blob/feature/command_buffer/Arch/Core/CommandBuffer/CommandBuffer.cs
Its usage is similar to your provided API sugestion :
var entity = world.Create(new ComponentType[] {typeof(Transform), typeof(Rotation), typeof(int) });
var bufferedEntity = commandBuffer.Create(new ComponentType[] {typeof(Transform), typeof(Rotation), typeof(int) });

commandBuffer.Set(in entity, new Transform{ X = 20, Y = 20});
commandBuffer.Add(in entity, new Ai());

commandBuffer.Set(in bufferedEntity, new Transform{ X = 20, Y = 20});
commandBuffer.Add(in bufferedEntity, new Ai());

commandBuffer.Playback();

What do you think about it ? :)

We can probably cose this due to #35 and #37


cargo doesnt work

Tryied to build my lastest project update. cargo run seems lazy and the command doesnt do anything.

Reinstall causes the same problem. Yesterday it worked properly.
Any suggestions?

This is an issue with Cargo: https://github.com/rust-lang/cargo/issues/4189
It has been fixed in this pull request: https://github.com/rust-lang/rust/pull/42754
Try updating to get the release that includes the fix.

 nightly-x86_64-pc-windows-msvc unchanged - rustc 1.19.0-nightly (04145943a 2017-06-19)
cargo updated and it´s still lagging.

Unfortunately this version does not contain the fix, so you will have to wait until the next nightly that contains the fix. As you can see in the commit list, the version of Cargo that comes with nightly right now is 50b1c24d1, 4 commits behind the one with the fix.
Until then, perhaps you could use the beta version, and wait until the new nightly gets released.

thanks for the advice given.


Sentry 429 error causes BadResponseException

Thanks to a pile up of deprecation notices from Symfony 2.7, I've stumbled upon an issue where Sentry returns 429 TOO MANY REQUESTS, which causes Guzzle to throw a BadResponseException.
I'm not sure what the best way of handling this is, but I don't think it makes sense for Sentry to be able to cause it's own uncaught exceptions.

I believe Sentry only responds with a 429 when you more events than your contract allows. I agree that it makes more sense to catch the BadResponseException exception from Guzzle, log the violation and let the process carry on.


DynamoDB backup plan

Summary | Résumé
Creates a backup plan and attaches the dynamoDB database as its resource to backup. This is needed in reference to ATO referenced in #191

Very nice! Using managed backup service is 👍
Just for my own understanding, presumably there's data residency requirement, so both db and backup are in canada central region. Is this correct?

Yes. We try to stick with ca-central-1 whenever possible but if a service does not exist in this region, then we use a different North American region (usually us-east-1). I am not 100% sure on the policy side what are the requirements but we can ask Sharly on Monday during our weekly meeting.


gl.drawArrays(gl.TRIANGLES, 0, sceneVertNo);

Hey, how can I do something like this in bgfx?
WebGL:
gl.drawArrays(gl.TRIANGLES, 0, sceneVertNo);

Basically not setting a pre-generated indexbuffer, like:
bgfx::setIndexBuffer(m_ibh);

So instead of using a indexbuffer, I just wanna say "I have 1000 triangles, 0,1,2 3,4,5, 6,7,8 etc."

Simply setting the vertex buffer with bgfx::setVertexBuffer(m_vbo); and calling bgfx::submit(0, m_shaderId); should do just that.

Oh wow, that works. :dancer:

So it automagically calculates the amounts of triangles based on submitted vertices?
So I guess other drawArrays options are not supported? Like gl.TRIANGLE_STRIP or gl.TRIANGLE_FAN
Your answer already solved my problem, just curious now about how to change the "implicit" index buffer layout

See supported primitive types:
https://github.com/bkaradzic/bgfx/blob/master/include/bgfx/bgfxdefines.h#L63
Default is TRILIST. And there is no TRIFAN since it's not useful (can be done via TRILIST or TRISTRIP).

Ok, I added now normals and colored the knot with them. That made me realize, that the triangles are wrong-sided:

Can I turn them inside-out somehow via bgfx? The knot vertices are from a WebGL example and I would like to be "compatible" with WebGL stuff, because I learn WebGL/bgfx basically side-by-side.

https://github.com/bkaradzic/bgfx/blob/master/include/bgfx/bgfxdefines.h#L54

Thanks, that did the trick :)
Since line numbers change in the future and nobody knows anymore where it pointed to, this is the solution:
	// Set render states.
	bgfx::setState(BGFX_STATE_DEFAULT | BGFX_STATE_CULL_CCW);

You should remove CW bit from BGFX_STATE_DEFAULT before setting CCW.

Building state from scratch works for me well enough:
	uint64_t bit = 0;

	switch(culling)
	{
		case Culling::CW: bit |= BGFX_STATE_CULL_CW; break;
		case Culling::CCW: bit |= BGFX_STATE_CULL_CCW; break;
        default: break;
	}

	switch(primitiveMode)
	{
		case RenderMode::LINE_STRIP: bit |= BGFX_STATE_PT_LINESTRIP; break;
		case RenderMode::LINES: bit |= BGFX_STATE_PT_LINES; break;
		case RenderMode::POINTS: bit |= BGFX_STATE_PT_POINTS | BGFX_STATE_POINT_SIZE(5); break;
        default: break;
	}

	bgfx::setState(0
        | BGFX_STATE_RGB_WRITE
        | BGFX_STATE_ALPHA_WRITE
        | BGFX_STATE_DEPTH_TEST_LESS
        | BGFX_STATE_DEPTH_WRITE
        | BGFX_STATE_MSAA
		| bit
    );


Quest alpha and AMD VCE/AMF

Hey, just curious if the Quest alpha has AMD VCE/AMF support in any way? When attempting to stream, my encoding latency is around 90ms with HEVC.

Just checked, it's about 400ms with AVC, and my transport latency is only around 4ms with no dropped packets.

Seems to be fine (i.e ~50ms -total latency-, 11ms encode) up to 75% resolution. Once it's turned up to 100%, it turns into a lagfest.

I think alpha version supports VCE.
If VCE did not work properly, SteamVR just fails at startup.
Perhaps it is not Quest specific issue. What's GPU are you using?
If you change bitrate, do you see different result?
It could be possible that VCE on your GPU doesn't support above 2k resolution of hardware encoding.

https://github.com/obsproject/obs-amd-encoder/wiki/hardware-support#video-coding-engine-20
VCE 2.0 seems to support at most 1920x1920 resolution.

I'm using an RX 570, so VCE 3.4. Bitrate doesn't seem to change much (at least, between 1 and 30Mbps). Even 100% res @ 1Mbit has the same latency.

Hello.
my graphic card is a T9 290X which supports only VCE2.0. Will it work ?
https://en.wikipedia.org/wiki/Video_Coding_Engine
Thank you


SFDX upgrade from 7.125.0 to 7.126.0 is breaking community file deployment - Error: Expected source files for type 'SiteDotCom'

After upgrading SFDX from
sfdx-cli/7.125.0 linux-x64 node-v16.13.0
to
7.126.0
We started getting the following issue while trying to deploy community files.
force:source:deploy fails with
app/main/default/sites/IBM_Partner_Portal.site-meta.xml: Expected source files for type 'SiteDotCom'
Started failing today(Nov 11, 2021) between 1PM GMT and 5PM GMT
reverting SFDX back to 7.125.0 confirmed to resolve the issue.

Also seeing this issue with the upgrade to 7.126.0. Rolling back the issue also corrected the issue

Similar issue for me as well. It happens during source:convert in my pipeline after updated to 7.126.0
sfdx force:source:convert -p force-app -d mdapioutput
ERROR running force:source:convert:  ./force-app/main/default/sites/MTC.site-meta.xml: Expected source files for type 'SiteDotCom'

Same issue here also with source:convert and then Expected source files for type 'SiteDotCom'

This is fixed in 7.127 ( sfdx update stable-rc if you want to test or use it now)

Upgrading to 7.127 resolved the issue for me 👍

Upgrading to 7.127 fixed this for me. I was however on 7.97 previously so I don't think this was an issue specifically with 7.126.


Possible mergeable classes for merging code bases

The main aim of this ticket is to clarify the project progress and having contribution with who is interested in it.
At the first step, we've prepared a list of possible mergeable files with their types which maybe need some pruning. Then, priority could be declared before starting to merge.

 There isn't a way to merge further for two reasons, 1) netstandard doesn't contain elliptical curve, netcore and netfx instantiate crypto providers in entirely different ways that I couldn't abstract any further.
SqlBuffer is very close to being done the remaining differences are because there is allocation free guid support in netcore that isn't in netfx. This means that SqlDataReader changes need to be ported to add that feature on netfx.
Some classes like TdsParser, TdsParserStateObject, SqlDataReader, SqlCommand are very large and I don't think we can do in a single PR, it would be impossible to review. I believe the way to do those types is a many small PR's which take identical functionality from both into a new shared version of the file slowly reducing each project specific file to the parts which are different and then those can be thoroughly reviewed.

Thanks for the comments.
Regarding the KeyConverter, I think we could extract the behavior of the class in the lowest possible abstraction.
I completely agree with keeping the PRs as simple as possible for the sake of review. Based on your idea, the above table doesn't mean each file or type should be merged in a single PR.

Looking at some of the merged from @lcheunglci I thought it might be useful to write down some of my knowledge and methodology used in my merges. From what I've gathered:
The nextfx codebase was forked at some point and that fork had a managed implementation of the network interface written so that it could be used on linux for netcore. This means that this codebase now has managed and native versions of the Sql Network Interface (SNI) in the netcore codebase and they are switched out depending on the platform that you restore the nuget package for. You can also force the use of managed network in windows with an appcontext switch. This mostly makes a difference in the core of TdsParser and TdsParserStateObject.
After netcore was forked the codebase was cleaned up a bit. So in general netcore is newer than netfx. However, changes and fixes may have been made to the netcore and netfx codebases independently so there's no guarantee that either was one better than the other they can both contain better versions of any particular function.
The netfx codebase is very very old, it was in the original 1.0 release of netfx and it hasn't always been updated to use the latest features. An example of this is the pool key derivation mechanism on netfx, it uses direct api calls to windows security apis because the managed equivalents were not available or not know to be usable at the time of writing.
This means that any change can be old or new and come from any version of the source code. To merge them you have to try to work out if they are functionally identical or equivalent enough that the difference cannot be observed by users up to and including timing and ordering of operations. This can get complicated and time consuming.
Style between the two codebases is highly variable. In general when merging a file it's a good idea to turn on the compiler Info messages and look through all the possible refactoring options is gives you. You don't have to take all the suggestions just take a look at them and make the code feel like it has the same style as some of the already merged components. The objective is to work towards a coherently styled single codebase where naming and formatting are easy to understand between most files.

Thanks @Wraith2 for your insight. I'll keep that in mind when I'm doing the code base merges. I'm currently starting small particularly focusing on the simpler code merges with the least conflicts before I look at the bigger ones.  Your feedback and suggestions are much appreciated.

While I was looking into SqlReferenceCollection.cs in PR #1303 , I noticed a dependency on SqlInternalConnection.cs which I've have merge locally, but noticed another dependency on SqlDataReader.cs, which I also have merged locally. However, after a conversation with @cheenamalhotra, she mentioned there was a change to SqlDataReader.cs in #1019 , so I decided to put that on hold until that PR is approved and merged.  In case someone else decided to merge SqlDataReader.cs and/or SqlInternalConnection.cs, I thought I'd mention it here to let you know that the work is in progress.

Reviewing the recent related PRs, I found it would be helpful to explain a bit about this project and its aim.
The main goal of merging codebases is to find the common codebases and make them easier and clearer for maintenance and further improvements. So, while you're working on this project consider how much your approach is close to these goals.
Two main approaches are:

Preprocessor directive
It's possible to merge codebases in a file using these directives. But consider overusing it could hurt the clarity of the code. It'd be a good practice to use it just for minor function body differences to include the extra line of code on specific conditions at compile time. For instance, assume NETFRAMEWORK is defined and equals true when using .NET 4.x target framework:

internal class Test1
{
    public void CommonFunc()
    {
        // something - not related to the specific conditions

#if NETFRAMEWORK
        System.Console.WriteLine("Just for .NET 4.x target framework");
#else
        System.Console.WriteLine("While target framework is not .NET 4.x");
#endif

        // something - not related to the specific conditions
    }
}

Partial classes and methods
This keyword helps to have more than one file for a type that means we could use it to separate each framework related implementation on a file. For instance, assume the following code for partial class usage:

// Note: there are three different cs files in total
// common codebase - definition in file TestCommon.cs

internal partial class Test
{
public void CommonFunc() { //Something }
}

// netfx - only - definition in file Test.cs in netfx project
internal partial class Test
{
public void Func1() { //Something }
}

// netcore - only - definition in file Test.cs in netcore project
internal partial class Test
{
public void Func2() { //Something }
}

C# preprocessor directives
Partial Classes and Methods (C# Programming Guide)

There's a quandry with naming around TdsParser.
in netfx we have netfx\TdsParser.cs so it's easy to rename that to netfx\TdsParser.netfx.cs and then introduce a new shared\TdsParser.cs file.
In netcore we have netcore\TdsParser.cs netcore\TdsParser.NetStandard.cs and 'netcore\TdsParser.NetCoreApp.cswhich means that we can't just renamenetcore\TdsParser.cs` to add netcoreapp to the end because that name is already taken. We also can't merge either of the netstandard or netcoreapp versions in because we need to keep both for their different builds. We could move the contents of both files into the main file and use #ifdef's but in the past we've chosen to use separate files with the general agreement that it is clearer that way.
So we need a name that means netcoreapp but isn't netcoreapp.
I know we can have two files called the same thing, as we do with SqlUtil.cs, but I'm fairly sure that doing that is what causes visual studio to be unable to track the currently active file in the solution window so I'd rather avoid it. I also thing having two files with the same name is confusing.

I think some of the classes in TdsParserHelperClasses should be split out into their own files. Specifically _SqlRPC _SqlMetaData, _SqlMetaDataSet and anything else that is has methods of it's own, I think classes which are just used as DTO's are probalby fine collected together. I'd also like to get rid of the _ prefixes on those classes.

@DavoudEshtehari SqlEnums.cs was moved to shared in #1317
SqlClientMetaDataCollectionNames.cs was moved to shared in #1287

@Wraith2 So removing netstandard support will improve the abaility to merge code?

I think I see the PR you're talking about @Wraith2 (#1022), thanks for that. Nowadays, the main problem lies in the ECDiffieHellman class: the creation of an RSA instance from a key blob components seem to have been replaced with a managed

SqlClientFactory has been merged in #2369. A lot of the other merge PRs pre-date the removal of support for .NET Standard - I'll bring these up to date as they're prioritised and reviewed.
In the wake of that removal, #2501 merges three of the four SqlColumnEncryptionKeyStoreProvider derivatives. These classes are almost identical between .NET Core and .NET Framework.
The remaining derived class is SqlColumnEncryptionCertificateStoreProvider, which is a little more complex: the .NET Framework version uses RSACryptoServiceProvider and directly accesses the private keys of certificates, while the .NET Core version uses the GetRSAPrivateKey extension method. I'll merge the class once I've tested with both CAPI and CNG keys.
Once #2501 and the extra PR have been merged, there'll be room for Unix support for Always Encrypted.

I've reached a stopping point with the merge, so it's now just a matter of triage. To summarise the table I've been using to keep track:
Files covered by PRs

File
.NET Framework path
.NET Core path
Associated PR

AdapterSwitches
src/Microsoft/Data/Common
-
#2828

NativeMethods; SafeNativeMethods; UnsafeNativeMethods
src/Microsoft/Data/Common
-
#2828

DbConnectionPool
src/Microsoft/Data/ProviderBase
src/Microsoft/Data/ProviderBase
#2812

SqlGenericUtil
src/Microsoft/Data/Sql
-
#2812

AAsyncCallContext
-
src/Microsoft/Data/SqlClient
#2383

AlwaysEncryptedHelperClasses
-
src/Microsoft/Data/SqlClient
#2376

SqlCertificateCallbacks
src/Microsoft/Data/SqlClient
-
#2831

SqlClientOriginalAddressInfo
src/Microsoft/Data/SqlClient
-
#2831

SqlColumnEncryptionCngProvider
src/Microsoft/Data/SqlClient
src/Microsoft/Data/SqlClient
#2501

SqlColumnEncryptionCspProvider
src/Microsoft/Data/SqlClient
src/Microsoft/Data/SqlClient
#2501

SqlColumnEncryptionEnclaveProvider
src/Microsoft/Data/SqlClient
src/Microsoft/Data/SqlClient
#2501

SqlDelegatedTransaction
src/Microsoft/Data/SqlClient
src/Microsoft/Data/SqlClient
#2861

SqlDependencyUtils
src/Microsoft/Data/SqlClient
-
#2812

SqlFileStream
src/Microsoft/Data/SqlClient
src/Microsoft/Data/SqlClient; src/Microsoft/Data/SqlTypes
#2398

TdsParserHelperClasses
src/Microsoft/Data/SqlClient
src/Microsoft/Data/SqlClient
#2376

TdsParserStaticMethods
-
src/Microsoft/Data/SqlClient
#2814

UnsafeNativeMethods
src/Microsoft/Data/SqlTypes
-
#2828

SQLCLR, code access security types
All of these depend upon #2862. There's not much code to merge here, just a lot of files. I think there'll probably be 3-4 PRs for these.

File
.NET Framework path

DBDataPermissionAttribute
src/Common/src/Microsoft/Data/Common

NameValuePermission
src/Common/src/Microsoft/Data/Common

DBConnectionString
src/Microsoft/Data/Common

Smi*; TriggerAction
src/Microsoft/Data/SqlClient/Server

SqlClientPermission
src/Microsoft/Data/SqlClient

SqlClientWrapperSmiStream
src/Microsoft/Data/SqlClient

SqlClientWrapperSmiStreamChars
src/Microsoft/Data/SqlClient

SqlDataReaderSmi; SqlInternalConnectionSmi; SqlSequentialStreamSmi; SqlSequentialTextReaderSmi
src/Microsoft/Data/SqlClient

SqlStreamChars
src/Microsoft/Data/SqlClient

Metrics, logging
These use two different mechanisms between .NET Framework and .NET Core, and they also record metrics at slightly different times. It might be better to merge the API surface and verify the metric timings as part of any future OpenTelemetry work. The issue tracking that is #2210 and #2211.

File
.NET Framework path
.NET Core path

DbConnectionPoolCounters
src/Microsoft/Data/ProviderBase
-

SqlClientDiagnostic
-
src/Microsoft/Data/SqlClient

SqlClientDiagnosticListenerExtensions
-
src/Microsoft/Data/SqlClient

SqlClientEventSource
-
src/Microsoft/Data/SqlClient

SqlDiagnosticListener
-
src/Microsoft/Data/SqlClient

Native SNI
This'll change the public-facing dependencies for the NuGet packages. Barring any objections, I'm planning to change the .NET Framework package to reference Microsoft.Data.SqlClient.SNI.runtime. This'll mean that there's one architecture-dependent DLL file in the resultant builds, not three DLLs which are toggled between at runtime.

File
.NET Framework path
.NET Core path

SNINativeManagedWrapperARM64; SNINativeManagedWrapperX64; SNINativeManagedWrapperX86; SNINativeManagedWrapper
src/Microsoft/Data/Interop
src/Interop

TDS parser
I'm pretty confident that the majority of the logic is identical, it's just obscured by the fact that only one codebase was refactored. There are probably some methods which can be merged as-is, but for the vast majority of cases I think we'll just need to repeat that refactor piecemeal.
I'm not planning to start until #2714 is merged, given how deeply any refactor work will touch the state machine.

The work to merge the two codebases has been going on for a long time. The problem is always testing and review.

I've definitely seen that - there's a lot of history here. A lot of the problem seems to be that we've got a mixture of different types of changes:

Purely syntax-based changes which don't impact the compiler output, but which balloon the diff - methods being rearranged in a class, automatic properties, => syntax, etc.
Infrastructure code which is no longer referenced, or which has been reorganised - PInvokes which are no longer referenced, others which have been moved to separate files
Structural refactors
"Real" feature/implementation differences (like SQL Azure's read-only failover partner support in SqlInternalConnectionTds, which only exists in .NET Framework)

Reviewing and testing PRs which contain any combination of those is always going to be tricky; many of the remaining classes have so much of the first two types of change that it's obscuring the changes which need the most review. I've seen a few "style change" PRs which touch large parts of both codebases. Those are disruptive when merged and their size makes them harder to review, but they might be a safer way to fix those first type of change and free up some bandwidth to review the more important changes.

Is there value in moving 100% matches first? e.g. in TdsParser there is PutSession, which is 100% identical.
I know it was touched upon in https://github.com/dotnet/SqlClient/issues/1261#issuecomment-917382886, but I'm not sure what the current sentiment is here?

I also wonder if it makes sense to equalize any code style changes between netfx and netcore by lifting up netfx to be the same as netcore (and if this should be a separate effort from merging)

I've tried both approaches. The throughput limitations are always review time and release cadence. We can only go as far as the MS team allow and they're busy.

So code style changes (for the sake of equalizing) should take the least time to review I guess?

In theory but in practice any review will take the same amount of time to happen so you have to choose what is more important to use your review quota for. Do you want to make material changes and improve the library or do you want to improve the quality of the codebase in a way that does not affect users?

Yep, understood. That's why I'd like to get some guidance from MS on what they prefer we'd do before starting new PR's that they don't want

Speaking personally here...
I've found my approach to PRs drifting into a cycle: start with a small PR which touches as little as possible and aligns some part of the public API (the API surface or behavioural) between netcore and netfx; follow up with a set of larger PRs which do more of the heavy lifting for that change. I've been trying to align the small PRs with the days/~fortnight before a GitHub milestone. Hopefully this should mean that the releases are met by easier-to-review community PRs, and the team gets a few, larger PRs when there's less pressure to review them. The Context Connection PR is a decent example of this - it's a small PR which functionally removes about 8k lines of code and half a dozen files. I'm not submitting those larger removals until after 6.0!
Separately to this: the point around code style merges is good. I don't have any real opinions on whether we should have a series of "big bang" PRs which target a few files and apply every code style change at the same time, or some other approach. My only two opinions here are that we should avoid making very large code style adjustments as part of a merge, and that we shouldn't roll out a repo-wide change which needs manual merge conflict resolution in lots of PRs without some forewarning. I'm happy to contribute to whichever approach makes sense besides that.

I agree with your thought to reduce scope of changes for faster reviews, and  limit changes to only file merges, however being a developer it's hard to not make code style changes after merge, and I understand that sentiment too. However, it would be best to lay guidelines on the process that can be followed by everyone contributing in this area something that aligns best to a reviewer mindset in this space and is a standardized approach.
I'll let @benrr101 come up with what should be a standard way of work to follow, being the current owner of this effort and please feel free to chime in to improvise.


Incorrect fast conversion for fp8 e4m3

The conversion forgot to add exponent compensation, so the conversion is not correct:
https://github.com/ROCmSoftwarePlatform/triton/blob/0cc3f8b84a16892396f6e08a04991034d67e32b1/lib/Conversion/TritonGPUToLLVM/ElementwiseOpToLLVM.cpp#L183-L218

cc @zhangyaobit

@scxiao Can you take a look?

Hi @cloudhan, what do you mean for "exponent compensation"? Could you please give an example for that? Thanks

Hi @cloudhan, what do you mean for "exponent compensation"? Do you mean the exponent bias? Thanks
Hi @cloudhan, never mind, I figured it out. F8e4 and FP16 has different values of exponent bias, which needs an adjustment in the conversion. It seems like fp8e5 is fine since it has the same exponent bias 15 as fp16. Thanks for pointing this out. We will fix it.

Hi @cloudhan, what do you mean for "exponent compensation"? Do you mean the exponent bias? Thanks
Hi @cloudhan, never mind, I figured it out. F8e4 and FP16 has different values of exponent bias, which needs an adjustment in the conversion. It seems like fp8e5 is fine since it has the same exponent bias 15 as fp16. Thanks for pointing this out. We will fix it.

Hi @cloudhan, some more update. Seem like our latest code already has the adjustment, please see: https://github.com/ROCmSoftwarePlatform/triton/blob/b25557ad5eb173a8a0680ed199954bf216448d2b/lib/Conversion/TritonGPUToLLVM/ElementwiseOpToLLVM.cpp#L490.
Thanks
Shucai


Support UIDocumentPickerViewController (apple rejects approval since no support for Files folder files)

We need to support UIDocumentPickerViewController in order for this app to be approved by app store.
I have been rejected and that is the reason. This is now enforced as new policy to use new features like iCloud and Files App.
Here is a message from Apple:
Guideline 2.5.15 - Performance - Software Requirements
We noticed that your app enables users to view and select files, but it does not include functionality to allow users to view or select items from the Files app and the user's iCloud documents, as required by the App Store Review Guidelines.
Next Steps
To resolve this issue, please revise your app to allow users to view and select items from the Files app and the user's iCloud documents.

This is definitively of utmost importance, no one wants to build apps for the simulator

Any update?

This is really strange. I think dozens of apps using this picker got approved recently (ours included). You should be able to make an appeal in the meantime.

It's not reproducing in my side. If you have such a problem, please make a PR with link to this issue.


Stop attempting template substitutions for invalid files

Fixes #204

@k0pernicus do you think we could do a point release for this?

@EverlastingBugstopper I was waiting for another review, but I can merge this fix tomorrow if no another review has been added here :ok_hand:

I'd also love another review on this, always good to have that.

OK so
with the last commit, the output looks like this

i dont love this tho. this could mask actually errors... especially with a future facing perspective on the idea that we'll implement custom variables. thoughts @k0pernicus @EverlastingBugstopper ?

perhaps a better approach is to look at the contents of the template placeholder and make sure it matches a name we expect like "template_name" or "author"

@EverlastingBugstopper the whitelist approach makes sense. ill see what i can do!

@ashleygwilliams Any chance we can get something along the lines of this merged? It's basically impossible to have GitHub Actions integrated in a template currently.

@EverlastingBugstopper @ashleygwilliams any update on this please? :)

unfortunately i dont have bandwidth for this right now - sorry :(

Basically this depends on @ashleygwilliams, if you feel you don't have time/motivation for this project, I recommend passing the rights to merge and publish releases to crates.io to some most active contributor

impossible to have GitHub Actions integrated in a template currently.
This is already possible (on master) with the use of (raw tags)[https://shopify.github.io/liquid/tags/raw/].

But other than that, if there are like for instance unknown variables used, it still fails. So a solution to this issue is still appreciated I guess. But I lost a bit track of what needs to be done to get it merged, @k0pernicus any idea what needs to be done?

This is already possible (on master) with the use of raw tags.

Totally.

But other than that, if there are like for instance unknown variables used, it still fails. So a solution to this issue is still appreciated I guess. But I lost a bit track of what needs to be done to get it merged, @k0pernicus any idea what needs to be done?

To be honest I lost the track too...
I can check the changes and reviews to "refresh my mind" in the next days, and rebase the work from @EverlastingBugstopper to match our master.

I can check the changes and reviews to "refresh my mind" in the next days, and rebase the work from @EverlastingBugstopper to match our master.

No worries, I was working recently on a fail-safe handling as well, so I can double-check this one and rebase it too. I have a bit of time this weekend.

Awesome, thanks @sassman :+1: :)

just for cross-reference there is now PR #245 that aims to tackle the thing and also handling undefined variables issues. So the scope is a bit wider than this one. Feel free to discuss pros and cons there.


Script deleted my entire MSDOS installation

You got Discord? Skype? MSN? Habbo Hotel?  I dont have Skype, MSN, Habbo Hotel and whatnot except for Discord but I dont wish to share my contact information on a github issue except for my email(which can be easily snagged, its "yusisamerican@gmail.com"). What "NV driver shit" are you talking about?


Warn user about --password cli option in login

Using command line parameter --password may reveal registry password. Better to warn user about this.
Signed-off-by: Abhijeet Kasurde<EMAIL_ADDRESS>

/assign @umohnani8

/approve
/ok-to-test

LGTM

/lgtm

@mheon @rhatdan Thanks for the review and merge.

Day late dollar short, but would you consider opening a new PR using logrus.Warn() instead of printf?

Warnf isn't printed by default, which could be a problem

Warnf isn't printed by default

:gaping-mouth-agog-emoji: I didn't realize that. Um, ok, never mind. Thanks for the quick response.

I kind of want to change that, but we have a bunch of warnings that will show by default now. We'd need to do a pass over all our logging and determine what severity things should be (and then try and fix any warnings that were still being displayed)

I agree, but I believe these warnings run deep.


[WIP, pending on #11248, #11358] EC and SM2 param / key generation

Both implemented at the same time, because they are so very closely related.
To get the same kind of functionality as with legacy keys, where we can basically switch back and forth between the EC and SM2 keytypes, this adds a OP_keymgmt_gen_get_params, which can really be used to get all kinds of information from the key generation, but for the moment, it's used to get the resulting keytype after generation.

THIS IS A VERY EARLY DRAFT!
It is incomplete and doesn't even build right.  I just wanted to expose the idea of being able to switch the keytype of the EC key structure.

Heh, it turns out that this must wait on #11248, since there are tests that generate an SM2 key in this PR, and then have signature failing because that hasn't been implemented yet.

Heh, it turns out that this must wait on #11248, since there are tests that generate an SM2 key in this PR, and then have signature failing because that hasn't been implemented yet.

I expect #11248 will remove the WIP soon

I think we should discuss the approach of mixing SM2 and EC keygen.

Why should the provider care about the legacy quirkiness of libcrypto in handling SM2 and EC as if they were the same? Wouldn't it be better if the provider implementation was simpler (at the cost of small repetition in non critical code)?

if framework asks for an SM2 key generation the SM2 key generation is performed
if framework asks for an EC key generation (even on the curve named SM2) an EC key generation is performed
push the "you asked for an EC key on SM2, take instead this SM2 key" logic inside libcrypto

The current implementation of keygen for SM2 in 1.1.1 (and in this PR) is slightly incorrect: the ranges for the random scalar differ (see #8435). In 1.1.1 we got stuck because EC and SM2 share too much code about keygen, here in the provider keeping SM2 and EC keygen more separate could be better.

I think we should discuss the approach of mixing SM2 and EC keygen.
@romen spoke thusly:

Why should the provider care about the legacy quirkiness of libcrypto in handling SM2 and EC as if they were the same? Wouldn't it be better if the provider implementation was simpler (at the cost of small repetition in non critical code)?

if framework asks for an SM2 key generation the SM2 key generation is performed
if framework asks for an EC key generation (even on the curve named SM2) an EC key generation is performed
push the "you asked for an EC key on SM2, take instead this SM2 key" logic inside libcrypto

Generally speaking, it's a good question, and it basically comes down to "no surprise".  Essentially, the way the new legacy code works is by detection, i.e. change the key type based on curve name, currently only for SM2, but hang on, it'll be more interesting as I continue :wink:.
For the "push" that you mention, i.e. check at generation if the curve name was "SM2", and in that case, switch over to ask for an SM2 keymgmt instead of the EC keymgmt...  this involves much more, and I think that this also ties into what you've talked about elsewhere, to be able to have keytypes that contain a bit more information, for example to be able to specify, say, the keytype "EC-P239v1".
So basically, you're saying that EVP_PKEY_gen() should:

detect that it's handling a key type that has possible sub-categories.  Right now, that would be detecting that the key type is "EC"
figure out the sub-category.  Right now and if the key type is "EC", that involves getting the curve name, create a new key type composed of the key type "EC", a dash, and the curve name.  If the curve name is "P239v1", the resulting string is "EC-P239v1"

So question is, when happens with the next key type that has similar properties, but is otherwise different?  On the vid call today, you mentioned RSA (I supposed you meant things like RSASSA-PSS and RSAES-OAEP), so we'd have to hack in special knowledge about those.  And then there was something about DSA...
Do you see where I'm going with this, and how things could become quite "interesting" indeed?

The current implementation of keygen for SM2 in 1.1.1 (and in this PR) is slightly incorrect: the ranges for the random scalar differ (see #8435). In 1.1.1 we got stuck because EC and SM2 share too much code about keygen, here in the provider keeping SM2 and EC keygen more separate could be better.

I'll have to study that issue.  I wonder if that could even be the issue to kill EVP_PKEY_set_alias_type() (I thoroughly dislike that function, it's not well thought out)...

For SM2 my argument is slightly different than for ECDH/ECDSA over different curves.

SM2 is its own cryptosystem, it has its specific keygen and its specific sign/verify algorithms.
ECDSA is its own cryptosystem with its keygen and sign/verify algorithms.
Both SM2 and ECDSA (and ECDH) are based on elliptic curve cryptography, so they use the EC module, the same way RSA and DSA use the BN module, but they are strictly independent from an operational point of view just as RSA and DSA.
Both SM2 and ECDSA have as a parameter the elliptic curve on which to run the algorithms: for EC many different curves are standardized and commonly in use, for SM2 at the moment there is only one curve that the standard recommends for use (and it is what we informally refer to as the "SM2 curve"), but nothing prevents the definition of new SM2 recommended curves in the future (e.g. to increase the level of security one could expect the definition of a >512 bits curve, as the current one is around 256 bits), and already now the SM2 standard allows for arbitrary prime and binary curves with the full set of parameters we have for traditional ECDSA/ECDH (even though it is not clear to me how such keys would be serialized), nor we should prevent applications from running ECDSA/ECDH over the "SM2 curve".
The only real point of contact between SM2 and ECDSA(/DH) is that SM2 does not specify its own distinct serialization format for keys

Instead implementations are reusing the SECG serialization used for ECDSA/ECDH keys, but instead of filling the "named curve" identifier member with a curve OID, OID <IP_ADDRESS>97.1.301 for "SM2" elliptic curve cryptography is used
This OID is not properly a curve OID, and at the moment I don't even know how an SM2 key on another curve would be serialized: actually <IP_ADDRESS>97.1.301 it's even weirder because usually it's leaf nodes in the "OID tree" that are used as identifiers, but in this case 301 represents a class as it has child nodes!
An EC curve over the "SM2 curve" at the moment could only be serialized using explicit parameters, because among the many SM2 related OIDs none is officially identifying the curve itself

So, originally, the issue of coercing "EC(DSA/DH) over SM2 ECC" serialized objects into "SM2" memory objects, could have been an issue to be handled only on deserialization, but the way we handled SM2 in 1.1.1 has created a problem that we have to deal with:

SM2 was treated as a subtype of ECDSA/ECDH: programmatically one created an EC_KEY on the "SM2 curve" and magically/hackishly the application ended up with a peculiar kind of EC_KEY object that instead of running ECDSA/ECDH like any other EC_KEY ran SM2 as the signing algorithm.

There might be applications out there that would expect this behavior of the API to keep working in 3.0
My belief is that providing compatibility with legacy somewhat quirky behaviour is a job for the framework and not for the providers that should register EC and/or SM2 keymgmt algorithms.
IMO we should avoid mixing again EC and SM2 keys and keep the provider interface simple, so if the framework asks an EC keymgmt for a key it should get back an EC key object, similarly an SM2 keymgmt should be able to generate only an SM2 key object: there shouldn't be the notion of EC keymgmt returning an SM2 object.

Relevant standards
Using https://github.com/alipay/tls13-sm-spec and https://github.com/metanorma/gmt-0009-2012 for  English translations.
More details about different standardization bodies and the relationship between different standards can be found at https://github.com/alipay/tls13-sm-spec#chinese-algorithm-standards

CSTC
NISSTC
ISO
Notes
Name

GM/T 0003.1-2012
GB/T 32918.1-2016

SM2 Key generation
Public Key Cryptograhpic Algorithm SM2 Based on Elliptic Curves - Part 1: General

GM/T 0003.2-2012
GB/T 32918.2-2016
ISO/IEC 14888-3:2018
SM2DSA
Public Key Cryptograhpic Algorithm SM2 Based on Elliptic Curves - Part 2: Digitial Signature Algorithm

GM/T 0003.3-2012
GB/T 32918.3-2016

Public Key Cryptograhpic Algorithm SM2 Based on Elliptic Curves - Part 3: Key Exchange Protocol

GM/T 0003.4-2012
GB/T 32918.4-2016

Public Key Cryptograhpic Algorithm SM2 Based on Elliptic Curves - Part 4: Public Key Encryption Algorithm

GM/T 0003.5-2012
GB/T 32918.5-2016

Public Key Cryptograhpic Algorithm SM2 Based on Elliptic Curves - Part 5: Parameter Definition

GM/T 0009-2012 (unofficial translation)
GB/T 35276-2017

SM2 objects encodings
SM2 Cryptographic Algorithm Application Specification

Last one shows some ingredients for encoding private and public keys, but is not complete.
I couldn't find the sources for the registration of the various OIDs related to SM2, or at least not in English.

ECDSA is its own cryptosystem with its keygen ...

Wait what?

IMO we should avoid mixing again EC and SM2 keys and keep the provider interface simple, so if the framework asks an EC keymgmt for a key it should get back an EC key object, similarly an SM2 keymgmt should be able to generate only an SM2 key object: there shouldn't be the notion of EC keymgmt returning an SM2 object.

I wholeheartedly agree with this.  Upon a closer look, that won't be very much of a breaking change either.  Basically, EVP_PKEY_set_alias_type() will have to stop working.  All other SM2 things are in master only, so there's quite ample space to get things right.

ECDSA is its own cryptosystem with its keygen ...

Wait what?

Well, technically it is not false, it happens that both ECDH and ECDSA where defined to share the key generation algorithm.
I was oversimplifying, and focusing on the digital signature side of things, as we can see from the table above also SM2 can be declined not only in a digital signature algorithm, but also in key exchange/derivation (a la ECDH) and for public key encryption.

I said:

Upon a closer look, that won't be very much of a breaking change either.  Basically, EVP_PKEY_set_alias_type() will have to stop working.  All other SM2 things are in master only, so there's quite ample space to get things right.

I didn't look close enough, it's a bit more than that.

Having looked around at the code in crypto/ec, I've decided to slowly and quietly back out from legacy SM2 stuff, and do what @romen proposes and keep that strictly separate in provider code.
(in other words, I'm removing the SM2 keygen from this PR and reworking it in another...  as to the legacy SM2 implementation, I frankly have zero desire to dive into that rabbit hole, especially in view of our schedule)

In the same vein, I'm move away the keytype change feature from this PR, even though I see uses in the future (if we do decide to "upgrade" EC keys to composite "EC-{grp}" key types)...

I reworked this to really only include provider side EC key generation, and let `EVP_PKEY_gen() detect the SM2 curve, and downgrade it to a legacy key.  This is as close to emulating what legacy EC key generation currently does as I can imagine.

This is not a draft any more.  Comments welcome

This is not a draft any more. Comments welcome

Is it still pending on other PRs? Is the WIP label still appropriate?

Is it still pending on other PRs?

At least #11358, which quickly fixes the issues with EVP_PKEY_get0_EC
I've removed the dependency on #11248, though

Is the WIP label still appropriate?

I want to try this PR merged with #11358 to see that they want to play well together.

Looks like there are a whole bunch of ctrls that need to be handled in EVP_PKEYs that don't have an ameth.
ASN1_PKEY_CTRL_PKCS7_SIGN, ASN1_PKEY_CTRL_CMS_SIGN, ASN1_PKEY_CTRL_CMS_ENVELOPE, ASN1_PKEY_CTRL_CMS_RI_TYPE, ASN1_PKEY_CTRL_SET1_TLS_ENCPT, ASN1_PKEY_CTRL_GET1_TLS_ENCPT

So, a good reason for keeping this one WIP was that I hadn't touched legacy_ctrl_str_to_param() and legacy_ctrl_to_param()...  and I'm not yet sure I got it right.

ASN1_PKEY_CTRL_PKCS7_SIGN, ASN1_PKEY_CTRL_CMS_SIGN, ASN1_PKEY_CTRL_CMS_ENVELOPE, ASN1_PKEY_CTRL_CMS_RI_TYPE, ASN1_PKEY_CTRL_SET1_TLS_ENCPT, ASN1_PKEY_CTRL_GET1_TLS_ENCPT

I'll deal with them later this evening

Also #11366 is likely to be a blocker in getting the SSL tests to pass with this PR.

Also #11366 is likely to be a blocker in getting the SSL tests to pass with this PR.

Ok, I'll have a look at that tomorrow

Merged with #11358 and #11394, this builds and tests fine with one exception, test_cms.  I'm currently working on that one, PR will appear soon

The last bit that's needed is for PKCS#7 and CMS to start dealing with provider side keys.  I've started that effort in #11422

#11358 being merged, I rebased this, and squashed all fixups while I was at it

I just realised that the CMS code, at least as far as our current tests go, currently never gets to see a provider side key, with only one exception:
https://github.com/openssl/openssl/blob/f5056577ba08b3694aab2722eae1c97bf00acc80/crypto/cms/cms_kari.c#L270-L298
... and of course, since ECDH is right in the middle of that, EC generation would hit CMS where it hurts the most.
In #11422, I recently added a few temporary hacks, simply because the EVP_PKEY_ASN1_METHOD code that cms_RecipientInfo_kari_encrypt and CMS_RecipientInfo_kari_decrypt use is much more complex than anticipated and requires more thought for rewriting in provider key terms.  I just tried with only those hacks added, and lo' and behold, the test_cms tests pass flawlessly.
So, instead of keeping this stuck on a PR that needs more effort, I'll have it depend on a much smaller PR that involves temporary hacks similar to what was done for TLS in #11358.

I just realised that the CMS code, at least as far as our current tests go, currently never gets to see a provider side key, with only one exception:

Which is the reason 1024 bit keys for DH were causing a issue when the key size restriction was changed to >= 2048 bit.

#11501 is the temporary hack.  I've tested it merged with this PR, and it seems to work flawlessly.

Which is the reason 1024 bit keys for DH were causing a issue when the key size restriction was changed to >= 2048 bit.

Is there a reason we haven't implemented that change in legacy code?

Which is the reason 1024 bit keys for DH were causing a issue when the key size restriction was changed to >= 2048 bit.

Is there a reason we haven't implemented that change in legacy code?

Apart from the fact that it breaks backwards compatablity.. The change would be to have the code the same and regenerate data using 2048 bit keys.

Apart from the fact that it breaks backwards compatablity.. The change would be to have the code the same and regenerate data using 2048 bit keys.

Sooo...  accept 1024 bit keys but refuse to generate lower than 2048?  Not sure I understand what you're arguing, I just think it's even worse if we have different generation limits depending on if the EVP_PKEY_METHOD implementations or the provider implementation happens to be called.  Let's at the very least be consistent across the board!

24 hours has passed since 'approval: done' was set, but this PR has failing CI tests.  Once the tests pass it will get moved to 'approval: ready to merge' automatically, alternatively please review and set the label manually.

Rebased

My original approval still stands. Since its only been rebased since then and more than 24 hours have elapsed I consider this ready for merge.

Darn. I spoke too soon. Travis failed :-(
There are a number of different problems.

The memleak was interesting...  I wonder why we haven't seen it before.

Still a couple of travis failures remaining (issues noted above)

I could have sworn I had pushed exactly those fixes, @mattcaswell.  Now done...

This pull request is ready to merge

Merged
2b9add696573131fc463d098ed8bcbff1b5829d9 KEYMGMT: Add functions to get param/key generation parameters
1f185f51a7899e1eddc9161d7781e3d5ae86ab78 PROV: Implement EC param / key generation
10d756a70e2aeaff0c08e86014075a8623f3e0ab EC: Refactor EVP_PKEY_CTX curve setting macros for param generation
813d31717853252e777b810cb74fa5793fcbb154 EVP: Add a temporary SM2 hack to key generation
49276c3569656a17c24517ff0781967ced2c9658 EVP: fix memleak in evp_pkey_downgrade()


Update HMAC proofs for PR aws/aws-lc#1574

HMAC precomputed keys PR aws/aws-lc#1574 adds fields to hmac_methods_st, which made the original proof failed.
This commit updates the proof.
This is a breaking change: the updated proof only works after PR aws/aws-lc#1574 is merged.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Hi @fabrice102 , the change looks good to me. One thing, could you point the submodule src to be your branch in .gitmodule? An example of it would be like: https://github.com/awslabs/aws-lc-verification/pull/147/files#diff-fe7afb5c9c916e521401d3fcfb4277d5071798c3baf83baf11d6071742823584


FastRoute enhancements

Enhanced runtime report
Add check and warnings for objects outside die area
Add option to set grid origin
New wirelength report
Add option to finish routing when overflow cannot be totally removed
Add check if tracks exist (with unit test)
New unit tests log
Add option to route nets with PADs

Thanks for the feedback, @jjcherry56. I fixed these issues now. After Jenkins ends with green checks, I'll proceed with the merge


[DEVX-1555] Add concurrency shard option

Description

Motivation and Context

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Documentation fix (typos, incorrect content, missing content, etc.)

Checklist

[ ] I have read the contributing document.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

It'd be good to add an explanation of what it means to split by concurrency.

@alexplischke Can you help to take look at this?


Allow more than 4 properties

The current implementation only allows 4 properties to be read simultaneously. This is a renderer limit, although sources should be modified by this too.
WebGL imposes some limits regarding texture units, but the limit is higher, although texture units are shared with ramp() textures and other expression textures too.
We need to dynamically use as much TUs as we need and throw an error if the required number of textures is higher than the WebGL implementation limit.

PR https://github.com/CartoDB/renderer-prototype/pull/241


cue: attribute parsing should respect nested brackets

What version of CUE are you using (cue version)?

$ cue version
cue version v0.0.0-20230211165554-7d89acd5c44b

go version devel go1.21-a4d5fbc3a4 Thu Feb 9 21:14:00 2023 +0000
      -buildmode exe
       -compiler gc
     CGO_ENABLED 1
          GOARCH amd64
            GOOS linux
         GOAMD64 v1
             vcs git
    vcs.revision 7d89acd5c44bca0c756f76089436ee9913818b03
        vcs.time 2023-02-11T16:55:54Z
    vcs.modified false

Does this issue reproduce with the latest stable release?
Yes
What did you do?

exec go mod tidy
exec go run main.go
cmp stdout expect-stdout

-- go.mod --
module test

require cuelang.org/go v0.4.3
-- main.go --
package main

import (
	"fmt"

	"cuelang.org/go/cue"
	"cuelang.org/go/cue/cuecontext"
)

func main() {
	ctx := cuecontext.New()
	v := ctx.CompileString(`
x: 1 @A(t=(a, b))
`)
	a := v.Lookup("x").Attributes(cue.FieldAttr)[0]
	fmt.Println(a.Arg(0))
}

-- expect-stdout --
t=(a, b)

What did you expect to see?
A passing test.
What did you see instead?
> exec go mod tidy
> exec go run main.go
[stdout]
t (a
> cmp stdout expect-stdout
--- stdout
+++ expect-stdout
@@ -1,1 +0,0 @@
-t (a
@@ -0,0 +1,1 @@
+t=(a, b)

The attribute is split on comma even though there are nested parentheses.
It would be in the spirit of the attribute syntax to allow arbitrarily nested substructure for attributes.

cc @4ad. @mpvl mentioned this may be required/key part of the Wasm work?

Marking as v0.6.0 for now, on the basis there might be a Wasm dependency.


Added warning for unsupported ground primitive texture materials in Sandcastle for Internet Explorer.

Fixes: https://github.com/CesiumGS/cesium/issues/8431

Thanks for the pull request @nithinp7!

:heavy_check_mark: Signed CLA found.
:grey_question: CHANGES.md was not updated.

If this change updates the public API in any way, please add a bullet point to CHANGES.md.

:grey_question: Unit tests were not updated.

Make sure you've updated tests to reflect your changes, added tests for any new code, and ran the code coverage tool.

Reviewers, don't forget to make sure that:

[ ] Cesium Viewer works.
[ ] Works in 2D/CV.
[ ] Works (or fails gracefully) in IE11.

@nithinp7 Looks good and congrats on your first PR! Since this is just modifying a sandcastle example no CHANGES.md updates or unit tests are required.


Profile Torch CIFAR

profile the code on Torch website? https://pytorch.org/tutorials/beginner/blitz/cifar10_tutorial.html

Also, in the code they shuffle after every epoch
There is no explicit statement for that
If you could isolate the shuffle time and/or understand how they implement shuffle, that would be great

0.0012947185039520264 ms to load a batch of 4 per iteration


Implement spanner_batch_client example.

This example seems to use PartitionQuery():
https://github.com/GoogleCloudPlatform/golang-samples/blob/40a33f7ff5de11da00a6715eaa29ce45fdf92387/spanner/spanner_snippets/snippet.go#L826-L869

Do we have batch client?

Do we have batch client?

Not a separate client, but we have  PartitionQuery() and ExecuteQuery() with a QueryPartition:
https://github.com/googleapis/google-cloud-cpp-spanner/blob/3157ba421a2bf2f6513ed80cad0c4885783de4e8/google/cloud/spanner/client.h#L267-L280
https://github.com/googleapis/google-cloud-cpp-spanner/blob/3157ba421a2bf2f6513ed80cad0c4885783de4e8/google/cloud/spanner/client.h#L327-L350


String Interpolation

I couldn't find any issue that matched this, so I felt this should be created.
Most languages have a nicer way to do a format then having to do something like format("{}", myObj), often they either take the 'Swift' route and do something like "\{myObj}" with the \{being existent in all strings; I personally don't like this as it does seem to do 'stuff' behind your back without you asking for it.
Whereas the 'C#' way which is something like $"{MyObj}", requires a symbol to designate that it is interpolated, I feel that this way is nicer in terms of usability and demonstrates clearly if a string should be interpolated you can write '{' by double writing it like {{ kinda like escaping it; we could also allow escaping it via the typical escape keyword \{ but that may be too similar to the first method to confuse people.
The third way is I guess more inline with the fact that Zig doesn't really use symbols for things like this and uses 'words' (i.e. transition from % to try) so I guess it would be something like fmt "{MyObj}" which would just translate to format("{}", MyObj).

'fmt' is just a name I chose to demonstrate the idea it is an implementation detail so probably not something to 'argue' about, more focus on the idea.

Why have this?
It helps when you have long format strings as you can easily prevent weird bugs of putting things in wrong orders (though those bugs are typically caught easily).  I don't have too many reasons for why they really are 'needed' so I wouldn't say that this is a necessity but it's one of those things I find that most people just go 'huh that's nice', kinda like how the 'for' loop in zig is not necessary but it just makes things nice.
On the other hand the negative of having it is 'bloating the language' (something I disagree that this would do but I can understand this view), you could also argue it is doing stuff 'behind' your back, but I would argue it is not doing anymore than what something like 'try' is using.
😄

One other note! Did not think about only allowing this at comptime. Here we don't have to worry about allocation failure and all that stuff, and we already have ++ and **. I think this feature have a higher chance of being a comptime only thing, but I still don't really think it's need.

Been meaning to reply, just passed my thoughts :).  I actually completely agree, and I don't really see this in 'Zig' the more I think about it; however I still felt it was worth creating the issue just incase others had opinions :).  Also means its a place to drive people who ask this in the future.
On your other points, I agree that referring to objects is quite nice; printing different format strings at runtime is extremely important too, though I think that is probably the place for a library to come in?  Since it is quite a niche place, however I may be wrong.
And yes it was a complete comptime feature so that's why I didn't mention allocators :).  But I actually don't think it's a need or even a want really, I think Zig is nice enough already with printing things.

:+1:


[Productize GEMM Performance] Features

This is the GEMM Performance features productization umbrella ticket. Before converting this ticket umbrella ticket, please:

Add the step-by-step GEMM Performance features productization plan here.
Create a separate ticket for each step and list it here. For ease of tracking, prefix the ticket title with [Productize GEMM #step_number]
Add the definition of done for this ticket. The definition of done may state that all commits from PoC have been merged and CI run on the main branch shows no difference on performance numbers comparing to the PoC branch

cc: @chengjunlu, @quintinwang5, @Dewei-Wang-sh, @etiotto, @whitneywhtsang, @tdeng5, @LiyangLingIntel

This ticket is related to:

#1451

Update the status for the GEMM performance on the fallback path from the issue #878.
Already finished:

Setup a benchmark tools and monitoring the GEMM performance in CI.
-- #879
Support sub-group-size 32 for DPAS
-- #416
Use the 2D load/store for the both the ToP (tensor of pointers) and PoT (pointer of tensor). (Ignore: nested ToPoToP....)
-- PoT (pointer of tensor): #146 , #413 , #415
-- ToP (tensor of pointers):
To pipeline the loops body with heavy tt.dot ops with prefetching.
Reduce the number of the convert layout between the chained dot operations.
-- Remove redundant convert layout: #894 ,

Things need to be finished:

Use the 2D load/store for the both the ToP (tensor of pointers) and PoT (pointer of tensor).
-- #1143
-- #880
Reduce the number of the convert layout between the chained dot operations.
-- #951
To use the dense stride instead of warp stride in tiling the tt.dot operation. So that we can use packed 2D load/store to load the operands A and B.
-- #969
Enable the large GRF as a turnable options for GEMM performance.

feature needed to productize gemm with block pointer

https://github.com/intel/intel-xpu-backend-for-triton/pull/1132
https://github.com/intel/intel-xpu-backend-for-triton/pull/1240
https://github.com/intel/intel-xpu-backend-for-triton/pull/1152
https://github.com/intel/intel-xpu-backend-for-triton/pull/1137

Still need to enable split barrier.

@whitneywhtsang what is the ticket # for enabling split barrier?

@whitneywhtsang what is the ticket # for enabling split barrier?

There was a functional failure when enabling split barrier, it is fixed in https://github.com/intel/intel-xpu-backend-for-triton/pull/1708. As commented in https://github.com/intel/intel-xpu-backend-for-triton/pull/1708#issuecomment-2253097323, there is no performance gain in GEMM geomean, so it is not enabled.


Request-464366

Is this a new chart
No
What this PR does / why we need it:
There are missing tolerations in some files, therefore, it can't be deployed in clusters with tolerations
Which issue this PR fixes
(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

fixes # Tolerations when deploying the chart

helm upgrade --install -f tolerations_values.yaml newrelic-bundle newrelic/nri-bundle \
--set global.licenseKey=LICENSE_KEY \
--set global.cluster=devqa \
--namespace=newrelic \
--set newrelic-infrastructure.privileged=true \
--set ksm.enabled=true \
--set prometheus.enabled=true \
--set kubeEvents.enabled=true

The pod was not being able to be deployed because of the taints
kbd -n=newrelic pod/newrelic-bundle-nri-metadata-injection-admission-create-g66v4
Name: newrelic-bundle-nri-metadata-injection-admission-create-g66v4
Namespace: newrelic
Priority: 0
Node: <none>
Labels: app=nri-metadata-injection-admission-create
app.kubernetes.io/instance=newrelic-bundle
app.kubernetes.io/managed-by=Helm
app.kubernetes.io/name=nri-metadata-injection
app.kubernetes.io/version=1.5.0
controller-uid=c1346bf6-e78a-4384-9936-84c8226ae205
helm.sh/chart=nri-metadata-injection-1.5.1
job-name=newrelic-bundle-nri-metadata-injection-admission-create
Annotations: kubernetes.io/psp: eks.privileged
Status: Pending
IP:
IPs: <none>
Controlled By: Job/newrelic-bundle-nri-metadata-injection-admission-create
Containers:
create:
Image: jettech/kube-webhook-certgen:v1.5.0
Port: <none>
Host Port: <none>
Args:
create
--host=newrelic-bundle-nri-metadata-injection,newrelic-bundle-nri-metadata-injection.newrelic.svc
--namespace=newrelic
--secret-name=newrelic-bundle-nri-metadata-injection-admission
--cert-name=tls.crt
--key-name=tls.key
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from newrelic-bundle-nri-metadata-injection-admission-token-5q4gh (ro)
Conditions:
Type Status
PodScheduled False
Volumes:
newrelic-bundle-nri-metadata-injection-admission-token-5q4gh:
Type: Secret (a volume populated by a Secret)
SecretName: newrelic-bundle-nri-metadata-injection-admission-token-5q4gh
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 2s (x31 over 5m3s) default-scheduler 0/6 nodes are available: 6 node(s) had taints that the pod didn't tolerate.

Special notes for your reviewer:

Don't know how to bump the chart version
Title is based on an active New Relic support ticket 464366

Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [mychartname])

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Isaac Abouganem seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

Hello since a merge to master triggers a deploy, each chart version should be bumped

CI seems to complain about lack of a version bump for the Pixie chart, could you handle that @abouganemi?
Bumping the patch should be fine.

Hi @roobre bumped the pixie chart patch version.
Cheers,

Seems like we are still missing some bumps: https://github.com/newrelic/helm-charts/runs/3483222064#step:7:57
Every chart that has been modified should have a patch bump for the CI to pass :)
Additionally if you could rebase the latest changes that would be great!

Hi @roobre rebase and pixie chart bump is done.
Thanks,

Hey there @abouganemi, thanks for following up on this. CI seems to have detected some syntax errors in the chart, could you check those out?
Thanks!

Thanks @roobre, just pushed the change. Let's try this one more time.
Cheers,

Hi @abouganemi we are allocating some time to work on this now, do you mind if I jump into your branch and add some commits to merge this PR? I think there are some lint errors and perhaps some versions needs to be bumped that has been outdated

I have removed the defaults values for tolerations, they should be added for cases that tolerations are needed, and we also avoid posible breaking on customers that already installed the charts.
I have also removed some of the style mods since they were introducing wrong indentations for some parameters.
I bumped modified charts.

@gsanchezgavier Thanks for the feedback and by all means feel free to modify my branch.
Let me know if you need something else from my part.

thanks @abouganemi for the effort and the contribution!


[Addition]: Cheater in Egem, Belgium (1pcs)

Hotspot b58 Addresses
11RRL4bJtV2JiHshjLw1mST7W9Git7mJ7pQsj2Vzj5YZHfcQqXA
Discord Handle
#nl-netherlands
Reason(s)
Proof:

Every beacon has -140 dBm RSSI and -20 dB SNR
Miner pretents to be in a 250 meter tower which is not actually there.
Receives beacons from more than 200 kilometer away.
9 HNT a day... No way!

This is a true location . It’s a 300 meter tower. Stop your hating 👌

Not hating.. But please explain why all beacons have the same RSSI/SNR values.
And provide some proof.

probably it is in the true location. however, the snr/rssi seems really suspicious. wherever the witness is the located, always snr=-20 dB and rssi=-140 dBm. really interesting. see the picture below.

He changed the lora configuration file, which is a cheater

well better than validator very well done :)
well come lambo

Thank you for your submission. This has been reviewed and may be considered for a future change to the denylist. If any change will be made, it'll likely be in the next 1-2 weeks assuming (1) it is proposed to be added, (2) denylist signers agree on the change, and (3) the release is published to all Hotspots. Please do not open additional issues regarding these Hotspots.

Its impossible...👉 Tricky Lava Lemur


Check if test ordering still causes failures.

Fixes # .
Changes proposed in this PR:

Closing this since I got nowhere with debugging. I will come back to the issue later.


Static Web Apps - Configuration does not allow duplicate route definitions

The Routes section of the documentation says that routes.json is deprecated and we should use staticwebapp.config.json.
The Configuration section of the documentation is showing a sample staticwebapp.config.json where multiple routes with the same path are defined (but different parameters such as method etc).
Relevant sample staticwebapp.config.json :
{
    "routes": [
        {
            "route": "/api/*",
            "methods": [
                "PUT",
                "POST",
                "PATCH",
                "DELETE"
            ],
            "allowedRoles": [
                "administrator"
            ]
        },
        {
            "route": "/api/*",
            "methods": [
                "GET"
            ],
            "allowedRoles": [
                "authenticated"
            ]
        }
    ]
}

Trying to run the default Build & Deploy Github Action with this configuration results in the following error :
Encountered an issue while validating staticwebapp.config.json: A duplicate route was found, it will not be evaluated. Please remove the duplicate route: /api/*
Renaming the file to routes.json and moving it in angular-app/assets results in the following build warning and does not apply the desired effect on the environment :
A 'routes.json' file was found in the 'assets' folder, but the file was invalid. Ignoring this file. Validation errors: Encountered an issue while validating routes.json: A duplicate route was found, it will not be evaluated. Please remove the duplicate route: /api/*
Worth noting that the Configuration docs section also seems to be missing from GitHub. So are the "deprecated" toasts on the Routes page.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 4bc86b95-7941-9673-2295-3d7cd20a8c4a
Version Independent ID: cace996e-10f0-fd0d-fde5-ae5f76df8149
Content: Configure Azure Static Web Apps
Content Source: articles/static-web-apps/configuration.md
Service: static-web-apps
GitHub Login: @craigshoemaker
Microsoft Alias: cshoe

Thanks for the feedback! I have assigned the issue to the doc author to update appropriately.

@mkarmark - is the following scenario happening because the routes.json and staticwebapp.config.json are in conflict with one another?

@craigshoemaker I don't think so. At first I only tried with staticwebapp.config.json, I saw the error, then I tried renaming it to routes.json and moved it to the assets FE folder. At no point were they defined at the same time.

@mkarmark, @miwebst - have you encountered this behavior before?

I believe @mkarmark has a fix for this and it will be released soon.

Yes, this is a known issue we are in the process of fixing. I'll post here when the fix is out.

This fix should have been rolled out a while ago, sorry for forgetting to update this thread, let me know if anyone runs into any issues!

Thanks, @mkarmark! @PiMihai I am going to #please-close this issue for now, but feel free to reopen if you feel more detail is required.


Translate a subset of Haskell to Bend

In this Reddit comment thread, the challenges around translating a subset of Haskell to Bend are discussed. In that thread, @augustss indicated interest in giving this a shot, and I wanted to create a ticket to tracks this progress, as I find it very interesting.
This is the ticket for both tracking progress around translating a subset of Haskell to Bend, and also a communication channel between the HVM developers and whoever wants to make an attempt at this translation — so that all relevant information around this venture is collected here.
I have purposefully left of which subset of Haskell to target, as I think any subset of Haskell is fine to begin with. Later, we may want to create new tickets for the translation of specific Haskell language features.

Open questions (from the Reddit thread):

I'm not clear how IO works, though. All examples seem to be programs that don't do any IO interactions.

Has there been any progress on this issue?
If not, is there anything I can do to help?


orion icons lib

https://orioniconlibrary.com/
:)

holy crap!! this is so amazing! what a nice demo! and so much for free!!! adding


Update install-dapr-cli.md

Thank you for helping make the Dapr documentation better!
Please follow this checklist before submitting:

[ ] Commits are signed with Developer Certificate of Origin (DCO - learn more)
[x] Read the contribution guide
[ ] Commands include options for Linux, MacOS, and Windows within codetabs
[ ] New file and folder names are globally unique
[ ] Page references use shortcodes instead of markdown or URL links
[ ] Images use HTML style and have alternative text
[ ] Places where multiple code/command options are given have codetabs

In addition, please fill out the following to help reviewers understand this pull request:
Description
Fix some command

@summer-espresso thanks! this has already been updated in the docs w another PR. closing.


404 "Domain not found." when trying to query Calendar Resources list.

I am using the Python client library in Python 3.5 on a Mac. I have created a project from a Google account with super-admin rights on the domain, created some Service Account credentials and downloaded them in JSON form to crr-service-secret.json, and granted all four scopes to the project ID. Yet every time I run the below code, I get an error that reads:
googleapiclient.errors.HttpError: <HttpError 404 when requesting https://www.googleapis.com/admin/directory/v1/customer/my_customer/resources/calendars?alt=json returned "Domain not found.">
Calls to other API endpoints work just fine. Is this a bug?
from oauth2client.service_account import ServiceAccountCredentials
from apiclient.discovery import build
import json
from httplib2 import Http

scopes = ['https://www.googleapis.com/auth/calendar',
		  'https://www.googleapis.com/auth/admin.directory.resource.calendar',
		  'https://www.googleapis.com/auth/admin.directory.resource.calendar.readonly',
		  'https://www.googleapis.com/auth/calendar.readonly']

credentials = ServiceAccountCredentials.from_json_keyfile_name(
	'crr-service-secret.json',
	scopes=scopes
	)
http = credentials.authorize(Http())
directory = build('admin', 'directory_v1', http=http)

response = directory.resources().calendars().list(customer='my_customer')
print(response.execute(http=http))

I'm not sure, you may have to use create_delegate using an administrator account first.
Either way, it's better to ask this question on stackoverflow, as unfortunately we do not maintain the APIs themselves, only the client library. This is an issue with API usage itself, and we unfortunately do not have expertise in every API that this client can access.
I'm closing this issue, but please feel free to comment if there is anything else I can help you with.

Thanks, I was able to reproduce the same symptom with the Ruby client so
it's either my fault or Google's.
On Apr 7, 2016 7:03 PM, "Jon Wayne Parrott"<EMAIL_ADDRESS>wrote:

I'm not sure, you may have to use create_delegate using an administrator
account first.
Either way, it's better to ask this question on stackoverflow, as
unfortunately we do not maintain the APIs themselves, only the client
library. This is an issue with API usage itself, and we unfortunately do
not have expertise in every API that this client can access.
I'm closing this issue, but please feel free to comment if there is
anything else I can help you with.
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/google/google-api-python-client/issues/214#issuecomment-207131452


Deprecate electron-prebuilt, better color support for Windows

Changed

Deprecates support for electron-prebuilt and replaces with the new offical electron package. This is a breaking change because of the inability to do peerDependencies to support both.  This is a breaking change and requires a major bump

Fixed

Fixed the color output on Windows by piping instead of inherit the output.

This actually fixes #6 bug

@bigtimebuddy Who usually reviews the Floss PRs?

@francoislaberge Usually @mbittarelli does


Cannot delete point where time > now()

Bug report
System info:
InfluxDB Version 1.2.4
Ubuntu 16.04.2 LTS
Steps to reproduce:

Insert point which has a timestamp > now(). E.g. test,id=123 value=2<PHONE_NUMBER>000000000
Try to delete this point. E.g. delete from test where time > now() or just delete from test
select * from test to see that the point is still there

Expected behavior:
Point is deleted
Actual behavior:
Point is still in the database

This will be fixed in 1.3.0 by #8329.


Partial revert "Finish pathlib migration (#245)"

This reverts commit 2c25aebfc7e1d313f30238a2bad8a7b68e952fc8 for the an incompatible change to src/ansible_compat_prerun.py, as the get_cache_dir() function is called externally with a string argument.
Closes: #258

It looks like reverting this is a bit harder than I thought, but I think the gist is right

The switch was on purpose, forcing consumers to do the switch. Just add a ceiling until they catch-up with the new code. Linter already fixed on main and release will be out soon. Molecule has a WIP PR to fix it too.


refactor(LinearAlgebra/BilinearForm/Basic): descope BilinForm to modules over commutative semirings

Require the module in the definition of the BilinForm structure to be over a commutative semiring.
This PR is a per-requisite for #11278. It supersedes #10422.
It's been pointed out elsewhere that the current definition over a non-commutative semiring doesn't make mathematical sense: https://github.com/leanprover-community/mathlib4/issues/10553#issuecomment-1944434170
Eventually the non-commutative situation may be considered in a mathematically meaningful way in the context of sesquilinear maps (e.g. something like https://github.com/leanprover-community/mathlib4/pull/9334#pullrequestreview-1880856848).
Co-authored-by: @Vierkantor

!bench

LGTM
maintainer merge


uninject should remove labels

Bug Description
kube-inject add label security.istio.io/tlsMode and kube-uninject did not remove it.
So, after uninject, pod with sidecar communicate with pod wihout sidecar by tls.
Version
client version: 1.13.2
control plane version: 1.13.2

Additional Information
$ k get -n istio-example deployments/details-v1 -o json | jq '.spec.template.metadata.labels'
{
"app": "details",
"version": "v1"
}
$ k get -n istio-example deployments/details-v1 -o yaml | istioctl kube-inject -f - | istioctl x kube-uninject -f - | grep tlsMode
security.istio.io/tlsMode: istio

I can try to fix it

/assign @xichengliudui


Implement NewRTPVP9CodecExt

This was omitted for some reason.
Note that the Ext variants are missing for all audio codecs.  I'm refraining from adding them right now, since the Unnamed SFU doesn't use any RTCP feedback for audio tracks, and hence I'm not able to test them easily.

Do you want me to tag a new version with this change?

Ot's not particularly urgent, it's for simulcasting only, and I'm not sure yet if I'm going to do codec agility (it has some serious drawbacks, due to needing to renegotiate when switching layers).  The change is just so I can experiment.


WIP: Billing unit tests

Unit tests WIP

Codecov Report
Attention: 5 lines in your changes are missing coverage. Please review.

Comparison is base (3f298cc) 68.42% compared to head (0773dee) 73.45%.
Report is 3 commits behind head on billing-release-002.

Files
Patch %
Lines

db/python/tables/bq/billing_filter.py
77.77%
2 Missing :warning:

db/python/tables/bq/generic_bq_filter.py
86.66%
2 Missing :warning:

test/test_bq_generic_filter.py
98.96%
1 Missing :warning:

Additional details and impacted files
@@                   Coverage Diff                   @@
##           billing-release-002     #656      +/-   ##
=======================================================
+ Coverage                68.42%   73.45%   +5.02%
=======================================================
  Files                      131      142      +11
  Lines                    10202    10857     +655
=======================================================
+ Hits                      6981     7975     +994
+ Misses                    3221     2882     -339

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Hi Michael, I had addresses most of your comment. The only left for the future PR is to use local BQ installation to run those tests against BQ tables. As well cost of query I will add to the response in a different PR.