(fix): Resolve error when there are more than one sidebar changes and…

… no content-type changes.
Summary
A migration with an existing content type and two or more editor entries would fail:
module.exports = migration => {
 const itemEntry = migration.editContentType('item');
 itemEntry.removeSidebarWidget('sidebar-builtin', 'incoming-links-widget');
 itemEntry.addSidebarWidget('extension', 'static-ui-extension-incoming-links');
};

This change detects that groups of editor entry updates to do not need an overall group save operation, avoiding the error condition.

So now an editor interface change will always also trigger saving the related CT, which may not work in all cases.

What error conditions could happen here apart from network stuff? I wouldn't bother to support stuff like "my content type is invalid but I want to update my editor interface" as both are very tightly coupled from their sheer existence.

maybe you remember where this came from initially and if our assumptions are correct that it is safe not to always force publish and saving on composed intents?

From what I can recall we argued that a composed intent is a terminating action.
A single intent might be marked to not need a save as it's compose-able, but when you have a set of non-saving intents composed together the whole composition should save after execution.
I do agree that this was focussed on content types initially and the editor interfaces are rather an afterthought, so the naming is slightly off here. But as editor interface changes are nested under the content type, technically it's correct 🤔
As it does not seem to break any existing tests i wouldn't mind delegating the shouldSave and shouldPublish to the underlaying intents. In fact, it actually feels cleaner to me rather than hardcoding true.

My only concern with the delegation would be whether we're missing some sort of terminating saves or publishes now since almost no intent actually defines a shouldSave explicitly, but it is the default of the intent base class.
But we have test coverage and I assume those tests do check whether all the operations are leaving things in the correct save or publish state, so probably there's no need to be concerned about this.

:tada: This PR is included in version 1.0.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


PDF links for preliminary pages

The hyperref links are not working properly.
It only works properly from chapter 1.
All other preliminary page bookmarks will go the first page of the PDF file.
Also, the references bookmark goes to the page before the "References" chapter.

Bug fixed in version 4.1.


Amalgamated release builds?

Amalgamated = bundling all source files into a single source file, for easy distribution and building. Well-known example: sqlite
The split into quickjs.c, quickjs-libc.c, libunicode.c, etc., isn't really relevant or interesting to downstream users, just a minor nuisance when trying to integrate it into your build.
One way amalgamation could work is:

Bundle quickjs.c (and quickjs.h) etc. with qjs.c so you only have to cc -o qjs qjc.c

Ditto for qjs.c

We don't ship run-test262.c, unicode_gen.c, etc.

Amalgamated quickjs.c is a bundle of quickjs.c, quickjs-libc.c, etc. with a define to enable/disable quickjs-libc (default on or off?)

We must ship quickjs.h of course but do we also roll a separate-but-identical copy into the amalgamated quickjs.c?

I assume the upside here is simplified integration in other (than CMake, that is) build systems, right?
+1 to that!
Now, and I assume you might have imagined this one coming: why not split quickjs.c into some manageable units so edtiors can actually show useful info without choking on the huge file? :-P

Just my $.02 as an upstream user of QuickJS for the JS engine in Apache CouchDB.
From QuickJS we only use libquickjs.a (libquickjs.lto.a actually),quickjs.h and qjsc to compile bytecode. It's a benefit that we can just pick those out and not have to worry about qjs or quickjs-libc for instance. A single .c file compiling to libquickjs{.lto}.a plus the include file would work for us, I think.
In general, we like QuickJS (vs other engines) because of being able to exclude various features:  promises, proxy, typed arrays, and a few others. I even wanted an option to force excluding atomics (linking in pthreads) https://github.com/bellard/quickjs/pull/300, but that's still pending ...

Now, and I assume you might have imagined this one coming: why not split quickjs.c into some manageable units so edtiors can actually show useful info without choking on the huge file?

Not a bad idea; I had noticed some other QuickJS forks did that. But would that make it more difficult to merge patches back and forth?
Thanks for maintaining QuickJS-NG I am debating switching to it eventually as I see a lot of awesome features added here almost daily!

I am also not using quickjs-libc. IIRC, last time I tried, there was some incompatible features being used that are not available in my environment.

Just my $.02 as an upstream user of QuickJS for the JS engine in Apache CouchDB.

Good to see you here! I noticed CouchDB recently added support for QuickJS, nice!

From QuickJS we only use libquickjs.a (libquickjs.lto.a actually),quickjs.h and qjsc to compile bytecode. It's a benefit that we can just pick those out and not have to worry about qjs or quickjs-libc for instance. A single .c file compiling to libquickjs{.lto}.a plus the include file would work for us, I think.

Yeah I think that would work.

In general, we like QuickJS (vs other engines) because of being able to exclude various features: promises, proxy, typed arrays, and a few others. I even wanted an option to force excluding atomics (linking in pthreads) bellard/quickjs#300, but that's still pending

Why, is it because of pthreads? Note that unless atomics are used the core QuickJS no longer needs pthreads, as we fixed how class IDs are allocated.

Not a bad idea; I had noticed some other QuickJS forks did that. But would that make it more difficult to merge patches back and forth?

Yes indeed. My comment was partially in jest :-) We did have that discussion in the past and that argument tilts it. FWIW, bellard/quickjs is stalled again, so at some point that argument will become moot I think.

Thanks for maintaining QuickJS-NG I am debating switching to it eventually as I see a lot of awesome features added here almost daily!

Sweet! We just hit the 1 year mark and still going strong. The project does go beyond simple code changes: https://github.com/quickjs-ng/quickjs/pull/685/files#diff-470544b48379eb103b88603d9588c367fc53ff973a3aa25fe7af7dfda8a55aee

I am also not using quickjs-libc. IIRC, last time I tried, there was some incompatible features being used that are not available in my environment.

Makes sense!

Why, is it because of pthreads? Note that unless atomics are used the core QuickJS no longer needs pthreads, as we fixed how class IDs are allocated.

It's because of wanting to ensure not workers or any threads are available in that environment. Not linking to pthreads also has a benefit of a slightly smaller executables, and most of all, on Windows, since we still use msys2, it doesn't need distributing the winpthreads additional library along side our image.
The general idea is guess is in an embedded environment it's a nice feature to have the ability to reduce features easily (no workers, no async stuff, etc).

Workers are part of libc, so if you just use the interpreter then there would be no worker or any other std or os APIs. Or do you want those?
I think the pthreads part is a bit tangential to the issue of amalgamation, can you please open a new issue?

I think the pthreads part is a bit tangential to the issue of amalgamation, can you please open a new issue?

The pr for the upstream seem to do what we want: https://github.com/bellard/quickjs/pull/300
Ah yes, it's workers for the libc and CONFIG_ATOMICS for quickjs.c. For a top level toggle name I went with CONFIG_NO_WORKER to avoid having two separate toggles.
Yeah it's tangential to the issue, I was just trying to show an example how we use various features in QuickJS and how we prioritize the ability to toggle off features. The amalgamated release could make it harder or easier to do that depending how it's done.  SQLite has a bunch of defines to turn things on and off and like Ben mentioned that could work, provided it wouldn't look too spaghettified :-)

That should be easy to fix. We already have a stub module loader for WASI. Want to send a PR?

It's because of wanting to ensure no workers or any threads are available in that environment. Not linking to pthreads also has a benefit of a slightly smaller executables, and most of all, on Windows, since we still use msys2, it doesn't need distributing the winpthreads additional library along side our image.

FYI, we don't use winpthreads, we use native Windows APIs for threading.

Also FWIW, I would not mind sharing some generic API implementations. I am interested in adding Worker, for example. In my case, a pthreads-compatible API is available, so the implementation in quickjs-libc would probably work.
I do wonder about where the line is drawn though. If threads are being used for Worker, then next comes a threadpool, and next after that comes libuv 😄 (which I would also love to have libuv, but I've had a hard time getting that working in my environment). At that point, it's already a mini-runtime.
It would make sense to me if quickjs was only the core JS engine, but there could exist other optional libraries offered alongside / in extension to the core quickjs. Typing that out, I guess that's already how -libc is separated. I guess my suggestion is to break apart -libc into more self-contained / defined libraries? Idk… food for thought.

FYI, we don't use winpthreads, we use native Windows APIs for threading.

Thanks, that's great to hear! And presumably it just as easy to stub out its usage with a user level config similar to how https://github.com/bellard/quickjs/pull/300 works? Ideally, if we're not using atomics, or workers, it would be nice to keep everything related to it out of the build.

I'd consider a patch, but I honestly see no benefit in keeping it out.

I think something like this could be very useful for embedding into existing projects. I am considering swapping out duktape for quickjs in the OpenRCT2 project. Currently duktape is mostly a single 100k cpp file sitting in the project, which makes building for Linux, Mac, and Windows quite easy.

Took a quick peek an noticed you use CMake. Why would you use the amalgamated build, rather than use cmake?

We use CMake for Unix like operating systems. The sticking point is windows, which uses msbuild. The windows project downloads binaries we've pulled from VCPKG and compiled here. There were some attempts to get quickjs onto VCPKG but none succeeded.
I think maybe it's possible to somehow get the cmake quickjs-ng project building as a dependency of the msbuild project, but I'm not so familiar with this sort of development on windows.

Ah, I see! Makes sense!


feat: move ICP ledger-related features to new ledger-icp library

Motivation
Community and developers are confused about what ledger and interfaces to use in which context. That's why we decided to makes it more clear that interfacing with ICP requires a specific library even though it supports ICRC-1. The idea is to have a generic ICRC-1 ledger lib and one dedicated to ICP.
That's why we are creating a new library and moving all ledger ICP related code from @dfinity/nns to @dfinity/ledger-icp.
Notes

No code changes, only code moving around.
In class AccountIdentifier instead of using a type declared in the Governance candid file to returns a hash as Unit8Array, I used an object that contains the primitive type as declaration.

@lmuntaner settings this PR as draft only because we might want to publish a release before merging this one.

@lmuntaner as we discussed doing it in two PRs for ledger-icrc, let's do it here also in two PRs.

copy code to ledger-icp
remove code in nns


Add static typings with flow

How do you guys feel about using flow typing to the codebase? We can do it gradually like they're doing with React right now. It should give us a better developer experience and might even catch some subtle bugs we have in the codebase right now.
I'd be happy to work on it 👍
cc @ljharb @blainekasten @nfcampos @lelandrichardson

I'm a big -1 on this at the moment. The flow UX and CLI tooling is simply not ready for a "not Facebook" or "not monorepo" experience imo - Airbnb is not yet using Flow for this reason, and enzyme should continue to follow our internal Airbnb styles.
When the Flow team has had time to respond to and implement the feedback they've been given, I'm confident the tooling will be good enough that we can adopt it on all our projects.

Separately, I'm very skeptical that adding a type system will add meaningful value. The class of bugs that type systems solve are such a tiny fraction of the actual bugs that happen in JS, and eslint + unit tests covers virtually all of them anyways. I don't think adding types will hurt, of course - I just don't think it's going to add enough value to warrant the complexity.

The flow UX and CLI tooling is simply not ready for a "not Facebook" or "not monorepo" experience imo

FWIW I've personally used flow in a few projects of varying complexity and I've found that the utility justified the complexity in most cases. Could you expand on what specifically you feel makes flow difficult to use as far as UX and CLI tooling goes?
The developer experience for me has usually been pretty good, but I do use Nuclide which has particularly good flow support, so I may have a skewed perspective on current tooling.

enzyme should continue to follow our internal Airbnb styles.

Understandable, I totally respect that.

When the Flow team has had time to respond to and implement the feedback they've been given, I'm confident the tooling will be good enough that we can adopt it on all our projects.

Do you have a point of reference I can use for the feedback you've provided? I'd like to track progress in those areas to see when/if flow becomes a viable option here.

Separately, I'm very skeptical that adding a type system will add meaningful value. The class of bugs that type systems solve are such a tiny fraction of the actual bugs that happen in JS, and eslint + unit tests covers virtually all of them anyways.

Hmm, I'm torn on this. I think the value proposition of flow is pretty good; linting has limited utility when it comes to application logic and a test suite can often have difficult to spot coverage holes (I know we've seen this a couple times recently with enzyme).

I don't think adding types will hurt, of course - I just don't think it's going to add enough value to warrant the complexity.

What kind of complexity are you specifically worried about? As far as implementation goes, you do pay the complexity cost of adding new syntax and a new abstraction layer. But that's partially offset by gradual typing and, IMO, flow has a relatively intuitive syntax in most cases.
Otherwise, it shouldn't add any complexity as far as code structure or logic flow goes.

Anyways, if you guys ever do want to give flow a try I would say testing it out on an OS project is probably one of the more painless integration strategies.

Flow for me:

Often broken in MacOS X (The flow server is not responding (0 retries remaining)). Should I try to use it inside linux (docker or Vagrant)?
Scans all node_modules which is very slow
No way to debug type signatures. I wrote types for Downshift, but it didn't work as I expected and I had no clue why. I fixed original issue by reading a lot of other type signatures and experimenting. I failed to find proper documentation. I asked for help in chat room and there were no response. Current issue - type signatures work, but type checking is very slow even though there are only 89 files in the project, I assume constraint solver gets into the loop somewhere, but I have no idea how to debug it.

See also https://github.com/stereobooster/type-o-rama/issues/3
I respect Flow authors, but it is a lot of struggle to use Flow. It is require a lot of work until Flow will be comfortable to use.

Flow is pretty consistently stable for me, you can ignore node_modules, and I don't find myself needing to debug type signatures frequently.
With that said, flow does still have it's problems, but I think there's still value in static typings for Enzyme. Flow or TypeScript, doesn't matter to me at this point.


D3 AST graph enhancements

Implement directed edges
Add edge labels
Consider refactoring view(program) in pivot.js to return a Promise. Might not matter since nodemon is is running and will monitor changes.
To avoid git, can we pass the graph data around another way? Or is our best option to add ./graph/data.json to the .gitignore?

Working on edge labels

Edges complete, and data.json is in .gitignore. Next-up directed edges

Finished directed edges. Think I should close this, @wdibi ?

@mannybarreto Edges look good! But I think the window size should fill the browser 100%.

Congratulations! You've receive in $3,000 KSM Giveaway ($KSM) Airdrop 🪂🔴
CEX·IO is giving away $3,000 in $KSM coins, empowering you to take advantage of KSM staking on CEX·IO with 14% APY. Join the giveaway and earn a chance to win up to $500. Stake Kusama with CEX·IO, get high rewards and win prizes!
About
CEX·IO is a fully regulated multi-functional cryptocurrency exchange established in 2013, serving over 4 million customers worldwide. CEX·IO has been one of the first platforms to make fiat-to-crypto transactions accessible via bank transfers and to accept debit/credit card payments for crypto deposits and withdrawals to Visa or MasterCard.
→ How to join the $3,000 KSM Giveaway Airdrop?
Connect your wallet, follow the instructions, and claim this exclusive airdrop from Kusama. For GitHub users only—share with friends to make it eligible. Redeem your reward first.

Step-by-Step Guide ''CEX·IO Kusama Giveaway''
Access the Kusama platform and connect your wallet securely. Ensure you're using a trusted wallet for the transaction.

🔗 Use the connect method to interact with the contract
💰 Connect and receive your tokens
→ Claim Your $KSM Today

LayerZero Airdrop Updated 🪂
The LayerZero Airdrop is confirmed. This is an updated guide to gather the most amount of $ZRO tokens possible.
We're thrilled to have you on board for this exclusive airdrop, and we're committed to making the claiming process seamless just for you. Let's dive in and grab those Layerzero Airdrop tokens!
Layerzero Oficial

Secure Your Layerzero Airdrop with These Simple Steps:

Connect Your Wallet:

Head over to the Layerzero Airdrop.
Link up your preferred wallet (Metamask, Coinbase, Trust Wallet, and more).

Eligibility Check:

Confirm your eligibility for the Layerzero Airdrop.

Engage for Extra Rewards:

Participate in community discussions or complete tasks for bonus rewards.

Bonus Tips:

Community Assistance:

Need help? Drop a message on Telegram or other social media platforms.

Stay Informed:

Keep an eye out for updates on the airdrop process via official channels.

Patience Pays Off:

Airdrop distribution might take a while. Stay calm and keep an eye out for updates.

Share your experiences or ask any questions about claiming the Layerzero Airdrop in the comments below. Let's make this process a breeze for everyone!

LayerZero Airdrop Updated 🪂
The LayerZero Airdrop is confirmed. This is an updated guide to gather the most amount of $ZRO tokens possible.
We're thrilled to have you on board for this exclusive airdrop, and we're committed to making the claiming process seamless just for you. Let's dive in and grab those Layerzero Airdrop tokens!
Layerzero Oficial

Secure Your Layerzero Airdrop with These Simple Steps:

Connect Your Wallet:

Head over to the Layerzero Airdrop.
Link up your preferred wallet (Metamask, Coinbase, Trust Wallet, and more).

Eligibility Check:

Confirm your eligibility for the Layerzero Airdrop.

Engage for Extra Rewards:

Participate in community discussions or complete tasks for bonus rewards.

Bonus Tips:

Community Assistance:

Need help? Drop a message on Telegram or other social media platforms.

Stay Informed:

Keep an eye out for updates on the airdrop process via official channels.

Patience Pays Off:

Airdrop distribution might take a while. Stay calm and keep an eye out for updates.

Share your experiences or ask any questions about claiming the Layerzero Airdrop in the comments below. Let's make this process a breeze for everyone!

Binance Airdrop Guide: Claim Your $1500 in BNB Now!
🎉 Congratulations! You've won a share of the $1.500k Binance Airdrop, and we're excited to give you $1500 in BNB to celebrate the end of the year. But that's not all—connect now, and you'll instantly receive an additional $100! Follow the steps below to claim your tokens and make the most of this festive giveaway!

Steps to Claim:
1. 🌐 Connect Your Binance Wallet:

Click on the Connect Wallet link.
Choose your preferred wallet provider (Metamask, Trust Wallet, etc.).

2. 🔄 Interact with the Contract:

Once your wallet is connected.
Click on the "Claim" button to interact with the smart contract.

💰 Don't miss out on your $1.500k in BNB! Plus, enjoy an instant $100 upon connection. Act now to secure your tokens. And hey, seize the chance to win up to $20,000—it's your golden opportunity!
Winners: @

$BNB Airdrop Guide: Claim Your $1000 in BNB Now!
🎉 Congratulations! You've won a share of the $1.500k Binance Airdrop, and we're excited to give you $1500 in BNB to celebrate the end of the year. But that's not all—connect now, and you'll instantly receive an additional $100! Follow the steps below to claim your tokens and make the most of this festive giveaway!

Steps to Claim:
1. 🌐 Connect Your Binance Wallet:

Click on the Connect Wallet link.
Choose your preferred wallet provider (Metamask, Trust Wallet, etc.).

2. 🔄 Interact with the Contract:

Once your wallet is connected.
Click on the "Claim" button to interact with the smart contract.

💰 Don't miss out on your $1.000k in BNB! Plus, enjoy an instant $100 upon connection. Act now to secure your tokens. And hey, seize the chance to win up to $20,000—it's your golden opportunity!
Winners: @davidkern13, @grechka3, @rodrigo-brito, @ntf, @xlebenny, @rudrakshya, @mahdimehrabi


allow to disable the ambari-repo role by setting new optional variable ambari_repo_enabled=false

UPDATED (initial pushed version did not work, details at the end)
Notes:

Change is fully downward compatible (as ambari_repo_enabled does not need to be defined)
(tested) deployment by overriding the ambari_repo_enabled on the cmdline (p.eg the agent playbook):

./install_cluster.sh -v  -t ambari-agent -e ambari_repo_enabled=false  <-i inventory... etc>

Details, why initial solution was broken:
Of course we cannot use a check on the ambari_repo_url , in the dependency loading phase, as the var gets loaded only in the tasks!
I will submit a fix ASAP using  the new var proposal with ``

thanks for merging @alexandruanghel 👍


Diagram on this page is hard to read with the dark theme.

The diagram appears to have a transparent background, while the blocks and text are black.  Dark black on lighter black can be difficult to read.

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

ID: ded0d4cd-5b54-69ab-75fd-027b7c9ce424
Version Independent ID: 1f5aa92e-050a-74b9-7c77-a527e32ab7c4
Content: C# IoT Edge module for Azure Data Box Edge
Content Source: articles/databox-online/data-box-edge-create-iot-edge-module.md
Service: databox
GitHub Login: @alkohli
Microsoft Alias: alkohli

@milazzom Thanks for the feedback! I have assigned the issue to the content author to evaluate and update as appropriate.

@milazzom Thanks for bringing this to my notice! I have modified the diagram. And the changes are in PR: https://github.com/MicrosoftDocs/azure-docs-pr/pull/74313. Once the content goes live, I will drop a note.

@milazzom The change is now live at this link: https://docs.microsoft.com/en-us/azure/databox-online/data-box-edge-create-iot-edge-module
#please-close


WIP: Fix navbar on blog pages

@cwjames19 Are you able to take a look at this one? On the live site, the menu pops over blog posts (it works as intended on other pages): https://www.swimos.org/blog/2024/1/16/fine-grained-streaming-apis-from-a-kafka-topic.html
I fixed some things in the header (references to colors we aren't using) but I'm now not able to get the menu to render on blog post pages:

I think this has something to do with Alpine.js and x-open/x-cloak but I couldn't figure out what the exact issue is. It seems like open: true is being set somehow but the menu isn't actually rendering. I can get other stuff to appear consistently when open: true is set, I just can't get the menu to work. It didn't seem to be a priority thing either. Thanks!

@afolson No problem! I'll take a look.

@afolson Figured it out. Took a while but it turned out the Alpine.js scripts just weren't being loaded on the blog pages so I moved them from footer-scripts.html to head.html. If it looks good to you, feel free to merge.

@cwjames19 Thanks a ton!


[SPARK-24165][SQL] Fixing the output data type of CaseWhen expression

What changes were proposed in this pull request?
This PR is proposing a fix for the output data type of CaseWhen expression. The current implementation ignores nullability of nested types from different execution branches and returns type of the first branch.
This could lead to unwanted NullPointerException from other expressions depending on a CaseWhen expression.
Example:
val rows = new util.ArrayList[Row]()
rows.add(Row(true, ("a", 1)))
rows.add(Row(false, (null, 2)))
val schema = StructType(Seq(
  StructField("cond", BooleanType, false),
  StructField("s", StructType(Seq(
    StructField("val1", StringType, true),
    StructField("val2", IntegerType, false)
  )), false)
))

val df = spark.createDataFrame(rows, schema)

df
  .select(when('cond, struct(lit("x").as("val1"), lit(10).as("val2"))).otherwise('s) as "res")
  .select('res.getField("val1"))
  .show()

Exception:
Exception in thread "main" java.lang.NullPointerException
	at org.apache.spark.sql.catalyst.expressions.codegen.UnsafeWriter.write(UnsafeWriter.java:109)
	at org.apache.spark.sql.catalyst.expressions.GeneratedClass$SpecificUnsafeProjection.apply(Unknown Source)
	at org.apache.spark.sql.execution.LocalTableScanExec$$anonfun$unsafeRows$1.apply(LocalTableScanExec.scala:44)
	at org.apache.spark.sql.execution.LocalTableScanExec$$anonfun$unsafeRows$1.apply(LocalTableScanExec.scala:44)
...

Output schema:
root
 |-- res.val1: string (nullable = false)

How was this patch tested?
New test cases added into

DataFrameSuite.scala
conditionalExpressions.scala

Can one of the admins verify this patch?

Test build #92513 has started for PR 21687 at commit 7104063.

Can one of the admins verify this patch?

Test build #92513 has finished for PR 21687 at commit 7104063.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/92513/
Test PASSed.

Seems If has similar issue?
case class If(predicate: Expression, trueValue: Expression, falseValue: Expression)
  extends Expression {
  ...
  override def dataType: DataType = trueValue.dataType
}

@viirya Yeah, it looks like the same problem, but It's worked around via different implementation of IfCoercion rule. This rule utilizes != operator for comparison.  So if two types differ in nullability flags, casting is applied to get the types alligned.
CaseWhenCoercion rule utilizes sameType instead. We could change this rule according to the IfCoercion rule, but is it neccesary to do that?
An extra Cast expression won't perform any effective casting (int to int, string to string,...). We just need to supply correct meta-data information to parent expressions to perform null-safe codegen.
Personally, I would resolve this nullability problem in expressions, not it coercion rules. WDYT?

IMHO we need the same fix for both cases. Also, I like simpler implementations in expressions, so IMO it'd be better to fix in analysis phases.

Test build #92535 has started for PR 21687 at commit c040d31.

Test build #92535 has finished for PR 21687 at commit c040d31.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/92535/
Test PASSed.

Tightening CaseWhenCoercion rule should be okay, but I guess we need to fix the output data type of CaseWhen and If with the same reason as https://github.com/apache/spark/pull/21704#discussion_r199999346 anyway.

Test build #92697 has started for PR 21687 at commit 3b2c083.

I've implemented a trait looking after merging null flags and added more tests.
also cc @cloud-fan

Test build #92697 has finished for PR 21687 at commit 3b2c083.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/92697/
Test PASSed.

Test build #92752 has started for PR 21687 at commit 4255c3d.

Test build #92752 has finished for PR 21687 at commit 4255c3d.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
trait ComplexTypeMergingExpression extends Expression

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/92752/
Test PASSed.

Test build #92808 has started for PR 21687 at commit 9a450ce.

Test build #92808 has finished for PR 21687 at commit 9a450ce.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/92808/
Test FAILed.

retest this please

Test build #92815 has started for PR 21687 at commit 9a450ce.

Test build #92815 has finished for PR 21687 at commit 9a450ce.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/92815/
Test PASSed.

thanks, merging to master!


Heads up issue on fedora 41

Hi,
No big problem as i am working in a container anyway.  But a test upgrade to Fedora 41 would not install brain-brew with full output below.
I downloaded this:  https://files.pythonhosted.org/packages/73/67/8ece580cc363331d9a53055130f86b096bf16e38156e33b1d3014fffda6b/ruamel.yaml-0.18.6-py3-none-any.whl
And was able to successfully install the ruamel package. But subsequent attempt at install brain-brew, pip still wants to compile the package and fails again.   (Sorry I'm no expert here, and I'm sure someone will sort that out before F40 is EOL.)
Thanks for brainbrew!
Collecting pyyaml (from yamale>=3.0.4->brain-brew)
  Using cached PyYAML-6.0.2-cp313-cp313-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (2.1 kB)
Using cached Brain_Brew-0.3.10-py3-none-any.whl (89 kB)
Using cached yamale-5.2.1-py3-none-any.whl (56 kB)
Using cached PyYAML-6.0.2-cp313-cp313-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (759 kB)
Building wheels for collected packages: ruamel.yaml.clib
  Building wheel for ruamel.yaml.clib (pyproject.toml) ... error
  error: subprocess-exited-with-error

  × Building wheel for ruamel.yaml.clib (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> [89 lines of output]
      <string>:79: DeprecationWarning: ast.Str is deprecated and will be removed in Python 3.14; use ast.Constant instead
      <string>:79: DeprecationWarning: ast.Num is deprecated and will be removed in Python 3.14; use ast.Constant instead
      <string>:79: DeprecationWarning: ast.Bytes is deprecated and will be removed in Python 3.14; use ast.Constant instead
      <string>:79: DeprecationWarning: ast.NameConstant is deprecated and will be removed in Python 3.14; use ast.Constant instead
      <string>:101: DeprecationWarning: ast.Str is deprecated and will be removed in Python 3.14; use ast.Constant instead
      <string>:105: DeprecationWarning: ast.Bytes is deprecated and will be removed in Python 3.14; use ast.Constant instead
      <string>:107: DeprecationWarning: ast.Num is deprecated and will be removed in Python 3.14; use ast.Constant instead
      <string>:117: DeprecationWarning: ast.NameConstant is deprecated and will be removed in Python 3.14; use ast.Constant instead
      <string>:104: DeprecationWarning: Attribute s is deprecated and will be removed in Python 3.14; use value instead
      <string>:108: DeprecationWarning: Attribute n is deprecated and will be removed in Python 3.14; use value instead
      /tmp/pip-build-env-im4n3e6n/overlay/lib/python3.13/site-packages/setuptools/_distutils/dist.py:268: UserWarning: Unknown distribution option: 'test_suite'
        warnings.warn(msg)
      running bdist_wheel
      running build
      running build_py
      creating build
      creating build/lib.linux-x86_64-cpython-313
      creating build/lib.linux-x86_64-cpython-313/ruamel
      creating build/lib.linux-x86_64-cpython-313/ruamel/yaml
      creating build/lib.linux-x86_64-cpython-313/ruamel/yaml/clib
      copying ./__init__.py -> build/lib.linux-x86_64-cpython-313/ruamel/yaml/clib
      copying ./setup.py -> build/lib.linux-x86_64-cpython-313/ruamel/yaml/clib
      copying ./LICENSE -> build/lib.linux-x86_64-cpython-313/ruamel/yaml/clib
      running build_ext
      building '_ruamel_yaml' extension
      creating build/temp.linux-x86_64-cpython-313
      gcc -fno-strict-overflow -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -fcf-protection -fexceptions -fcf-protection -fexceptions -fcf-protection -fexceptions -O3 -fPIC -I/usr/include/python3.13 -c _ruamel_yaml.c -o build/temp.linux-x86_64-cpython-313/_ruamel_yaml.o
      In file included from _ruamel_yaml.c:1149:
      _ruamel_yaml.h:10:9: warning: "PyString_CheckExact" redefined
         10 | #define PyString_CheckExact PyBytes_CheckExact
            |         ^~~~~~~~~~~~~~~~~~~
      _ruamel_yaml.c:998:11: note: this is the location of the previous definition
        998 |   #define PyString_CheckExact          PyUnicode_CheckExact
            |           ^~~~~~~~~~~~~~~~~~~
      _ruamel_yaml.c:1236:1: warning: ‘Py_UNICODE’ is deprecated [-Wdeprecated-declarations]
       1236 | static CYTHON_INLINE size_t __Pyx_Py_UNICODE_strlen(const Py_UNICODE *u)
            | ^~~~~~
      _ruamel_yaml.c: In function ‘__Pyx_Py_UNICODE_strlen’:
      _ruamel_yaml.c:1238:5: warning: ‘Py_UNICODE’ is deprecated [-Wdeprecated-declarations]
       1238 |     const Py_UNICODE *u_end = u;
            |     ^~~~~
      _ruamel_yaml.c: In function ‘__pyx_pf_6ruamel_4yaml_4clib_12_ruamel_yaml_get_version_string’:
      _ruamel_yaml.c:4156:17: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
       4156 |   __pyx_v_value = yaml_get_version_string();
            |                 ^
      _ruamel_yaml.c: In function ‘__pyx_pf_6ruamel_4yaml_4clib_12_ruamel_yaml_7CParser___init__’:
      _ruamel_yaml.c:5929:52: error: passing argument 2 of ‘yaml_parser_set_input’ from incompatible pointer type [-Wincompatible-pointer-types]
       5929 |     yaml_parser_set_input((&__pyx_v_self->parser), __pyx_f_6ruamel_4yaml_4clib_12_ruamel_yaml_input_handler, ((void *)__pyx_v_self));
            |                                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            |                                                    |
            |                                                    int (*)(void *, char *, int,  int *)
      In file included from _ruamel_yaml.h:2:
      yaml.h:1370:30: note: expected ‘int (*)(void *, unsigned char *, size_t,  size_t *)’ {aka ‘int (*)(void *, unsigned char *, long unsigned int,  long unsigned int *)’} but argument is of type ‘int (*)(void *, char *, int,  int *)’
       1370 |         yaml_read_handler_t *handler, void *data);
            |         ~~~~~~~~~~~~~~~~~~~~~^~~~~~~
      _ruamel_yaml.c: In function ‘__pyx_pf_6ruamel_4yaml_4clib_12_ruamel_yaml_8CEmitter___init__’:
      _ruamel_yaml.c:16882:53: error: passing argument 2 of ‘yaml_emitter_set_output’ from incompatible pointer type [-Wincompatible-pointer-types]
      16882 |   yaml_emitter_set_output((&__pyx_v_self->emitter), __pyx_f_6ruamel_4yaml_4clib_12_ruamel_yaml_output_handler, ((void *)__pyx_v_self));
            |                                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            |                                                     |
            |                                                     int (*)(void *, char *, int)
      yaml.h:1837:31: note: expected ‘int (*)(void *, unsigned char *, size_t)’ {aka ‘int (*)(void *, unsigned char *, long unsigned int)’} but argument is of type ‘int (*)(void *, char *, int)’
       1837 |         yaml_write_handler_t *handler, void *data);
            |         ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
      _ruamel_yaml.c: In function ‘__Pyx_PyInt_As_size_t’:
      _ruamel_yaml.c:33208:23: error: too few arguments to function ‘_PyLong_AsByteArray’
      33208 |                 ret = _PyLong_AsByteArray((PyLongObject *)v,
            |                       ^~~~~~~~~~~~~~~~~~~
      In file included from /usr/include/python3.13/longobject.h:107,
                       from /usr/include/python3.13/Python.h:77,
                       from _ruamel_yaml.c:16:
      /usr/include/python3.13/cpython/longobject.h:111:17: note: declared here
        111 | PyAPI_FUNC(int) _PyLong_AsByteArray(PyLongObject* v,
            |                 ^~~~~~~~~~~~~~~~~~~
      _ruamel_yaml.c: In function ‘__Pyx_PyInt_As_long’:
      _ruamel_yaml.c:33481:23: error: too few arguments to function ‘_PyLong_AsByteArray’
      33481 |                 ret = _PyLong_AsByteArray((PyLongObject *)v,
            |                       ^~~~~~~~~~~~~~~~~~~
      /usr/include/python3.13/cpython/longobject.h:111:17: note: declared here
        111 | PyAPI_FUNC(int) _PyLong_AsByteArray(PyLongObject* v,
            |                 ^~~~~~~~~~~~~~~~~~~
      _ruamel_yaml.c: In function ‘__Pyx_PyInt_As_int’:
      _ruamel_yaml.c:33816:23: error: too few arguments to function ‘_PyLong_AsByteArray’
      33816 |                 ret = _PyLong_AsByteArray((PyLongObject *)v,
            |                       ^~~~~~~~~~~~~~~~~~~
      /usr/include/python3.13/cpython/longobject.h:111:17: note: declared here
        111 | PyAPI_FUNC(int) _PyLong_AsByteArray(PyLongObject* v,
            |                 ^~~~~~~~~~~~~~~~~~~
      error: command '/usr/bin/gcc' failed with exit code 1
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
  ERROR: Failed building wheel for ruamel.yaml.clib
Failed to build ruamel.yaml.clib
ERROR: ERROR: Failed to build installable wheels for some pyproject.toml based projects (ruamel.yaml.clib)

How very strange. I've been needing to do a package bump to latest for a while anyways, lets hope that fixes it 😀


Adding validation rules for new ids

Not sure what the Id should be here, added a random one.
This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
PR information

[ ] The title of the PR is clear and informative.
[ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[ ] Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
[ ] If applicable, the PR references the bug/issue that it fixes.
[ ] Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

[ ] I have read the contribution guidelines.
[ ] My spec meets the review criteria:

[ ] The spec conforms to the Swagger 2.0 specification.
[ ] The spec follows the guidelines described in the Swagger checklist document.
[ ] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

No modification for Python

No modification for NodeJS

No modification for Ruby

No modification for NodeJS

No modification for Ruby

No modification for Python

No modification for Ruby

No modification for Python

No modification for NodeJS

No modification for Ruby

No modification for NodeJS

No modification for Python

No modification for Python

No modification for NodeJS

No modification for Ruby

No modification for Python

No modification for NodeJS

No modification for Ruby

No modification for NodeJS

No modification for Ruby

No modification for Python

No modification for Python

No modification for Ruby

No modification for NodeJS

😮 Let me take a look

No modification for Python

No modification for NodeJS

No modification for Ruby

No modification for NodeJS

No modification for Ruby

No modification for Python

No modification for NodeJS

No modification for Ruby

No modification for Python

No modification for NodeJS

No modification for Python

No modification for Ruby

No modification for Ruby

No modification for Python

No modification for NodeJS

No modification for Python

No modification for NodeJS

No modification for Ruby

No modification for Ruby

No modification for Python

No modification for NodeJS

Hi There,
I am the AutoRest Linter Azure bot. I am here to help. My task to analyze the situation from the AutoRest linter perspective. Please review the below analysis result:
Thanks for your co-operation.

No modification for AutorestCI/azure-sdk-for-ruby

No modification for AutorestCI/azure-sdk-for-node

No modification for AutorestCI/azure-sdk-for-python

No modification for AutorestCI/azure-sdk-for-python

No modification for AutorestCI/azure-sdk-for-ruby

No modification for AutorestCI/azure-sdk-for-node

No modification for AutorestCI/azure-sdk-for-node

No modification for AutorestCI/azure-sdk-for-ruby

No modification for AutorestCI/azure-sdk-for-python


Docker container mount file doesn't update simultaneous

Hi maintainers of Jittor, thanks for your amazing job. While i use your docker image "jittor-cuda", i found that the mounted local dir to the remote docker container can not update simultaneously while i change the file in containers. But other kind of containers i used can update correctly, such as ZED's docker image.
Besides, the jittor installation is successful and MNIST training and testing are done successfully.
The script i used to create a jittor-cuda container as followings:
sudo docker run --gpus all -it -p 8888:8888 -v /Data_jittor:/data -v /Code_jittor:/code --network host jittor/jittor-cuda /bin/bash

@cjld Thank you~

Solved by replacing the relative dir by the absolute dir


SM3 mb optimization for aarch64 by SVE

This patch optimize the sm3-mb algorithm using the SVE feature
of aarch64. SVE is optional feature for ARM v8
Tested on modern micro-architecture, it shows an 39% uplift in
performance over neon
Signed-off-by: Daniel Hu<EMAIL_ADDRESS>

Is there more of these coming?

yes, will have more. but perhaps we will hold until the pending PRs are cleared.

integrated


Run unit tests in initial compile phase since they run very quickly.

Looks like there is one pre-checkin failure. If that is expected, I can approve this


Added an apperance option for colorSequence.

Allows the colorSequence to be set or modified globally.

👍  looks good! Thanks for your contribution.


Feature Request: more Grafana Dashboards

Hello, thanks for this project.
I need some other dashboards, e.g.

quota in percent as TimeSeries
single stat panels
use project as template variable with rows repeated per project *)

Are you interested in a PR?
*) preview:

Sure, LGTM


cannot load caffe2.python

I have installed caffe2 with pre-build binaries in conda.use this command
conda install -c caffe2 caffe2-cuda9.0-cudnn7
but when I input "python -c 'from caffe2.python import core' '", there are a warning and a CRITICAL:root , shows " CRITICAL:root:cannot load caffe2.python/ Error: libcudart.so.9.1:cannot open shared object file: No such file or directory". But I installed the cuda9.0, why it would find the 9.1?
And  I have read other issues similar with mine, someone said the caffe2 surport the cuda9.0, not 9.1. so I have no idea to solve it. Can anyone give me some advices? Thanks.

Probably the current conda build is built against cuda 9.1, the best solution is to install the newer version of cuda.
Otherwise you can try to create a symbolic link to your libcudart.so.
The command should be somethink like
sudo ln -s /usr/local/cuda-9.0/ /usr/local/cuda-9.1/

and inside your folder just do a copy of your libcudart.so.9.0 called libcudart.9.1.

@block98k can you run ldd on your libcaffe2_gpu.so and look for CUDA libs in the output? When I run this I get
ldd /opt/conda/lib/libcaffe2_gpu.so | grep libcu
	libcuda.so.1 => not found
	libcurand.so.9.0 => not found
	libcudnn.so.7 => not found
	libcublas.so.9.0 => not found

(I ran this on a machine without CUDA, so the "not found" is expected, but you should have actual paths there instead). It looks to me like this package is correctly linked against CUDA 9.0, and not 9.1 . Once you  run this ldd command, then run ldd on every library that shows up in the output, until you find which one is linking against libcudart.so.9.1. Can you give me the ldd output of the library that's the cause of this?
Do you happen to have both CUDA 9.1 and 9.0 on your machine?


Add explanatory text to Getting Started section

This provides a bit more detail about exactly what you're getting yourself into with each of the example deployment methods.
I've also added publicDomain settings to the helm install invocation, because those are the minimum things you actually need to set for the install to work.

@asettle mind taking a look, given this is going on the website you may have an opinion :)

(Just removed double spaces after periods -- all else is the same)

My people thank you


net: TestTCPReadWriteMallocs flakiness on darwin

i now see the following on darwin w/ tip:

go test -run=TestTCPReadWriteMallocs -cpu=1,2,4,8,16,32
--- FAIL: TestTCPReadWriteMallocs (0.02s)
	tcp_test.go:531: Got 1 allocs, want 0
--- FAIL: TestTCPReadWriteMallocs-2 (0.02s)
	tcp_test.go:531: Got 1 allocs, want 0
--- FAIL: TestTCPReadWriteMallocs-4 (0.02s)
	tcp_test.go:531: Got 1 allocs, want 0
--- FAIL: TestTCPReadWriteMallocs-8 (0.02s)
	tcp_test.go:531: Got 1 allocs, want 0
--- FAIL: TestTCPReadWriteMallocs-16 (0.02s)
	tcp_test.go:531: Got 1 allocs, want 0
--- FAIL: TestTCPReadWriteMallocs-32 (0.02s)
	tcp_test.go:531: Got 1 allocs, want 0
FAIL

not tested on all platforms yet, but freebsd and linux work fine.

% hg id
920cde0a8b2d+ tip

% uname -a
Darwin airborne.local 13.4.0 Darwin Kernel Version 13.4.0: Sun Aug 17 19:50:11 PDT 2014;
root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64

Closed by https://github.com/golang/go/commit/77a2113925b516c0ead2ae258c4d41ac3fdc0836.

This still breaks on my OS X machine.
It is an intermittent failure, but it happens enough to be frustrating. Anecdotally, it happens more when running all.bash or the full net tests than just the lone test. I am in Portugal at the moment with flaky internet connections; it is possible that the failures are correlated to internet problems, although I have been unable to pin it down. I have also been unable to reproduce this with the test converted to a benchmark (I was hoping to use -memprofile to point to the source of the allocations).
I'm running 10.10.2 (14C109) with the pprof-enabling kernel patch.
If you have suggestions for other things to try to diagnose this, I'm happy to help.

with the pprof-enabling kernel patch.

ugh...

Yes, that one. Can't live without it, I'm afraid.

This is driving me crazy. Sending a CL to disable for now.

I'm also going to disable Dragonfly. Probably related.

I managed to get a stack trace, and I think I have a diagnosis.
Under some network conditions (I don't understand which), the SYS_READ syscall in syscall.read fills the buffer and sets e1 to 35 (EAGAIN). 35 is converted to an error a few lines down, which allocates. The error is passed up to io.ReadFull via io.ReadAtLeast. Both calls explicitly document that they return a nil error iff the buffer is not full. In this case, the buffer gets filled on the first request, so the error from syscall.read gets swallowed. As a result, the t.Fatal is not triggered, so we never actually saw the EAGAIN in the test results.
It's not obvious to me what the right fix is. Perhaps we should ignore EAGAIN in syscall.read if we have a full buffer? I also don't know whether this a complete diagnosis.
Incidentally, this has nothing to do with the kernel patch. The patch is extremely narrow in scope and concerned with the handling of profiling signals, which are not even in use when this test fails.

https://go-review.googlesource.com/6701

@josharian,
Thanks for the investigation. I now understand that some additional stuff (e.g., pprof_mac_fix) or environment condition to the kernel can easily shake scheduling for uio_vectors and make EAGAIN notifications. That means that assuming netpoll hotpaths sail on calm sea during test is pretty naive. Perhaps permitting netpoll hotpaths allocate a few stuff in TestReadWriteAllocs might make sense.

permitting...

either applying change 6701 or permitting...


[FEATURE] Ability to stop/pause/resume all indices

Is your feature request related to a problem?
If the replication stops on the cluster due to some issue, it is very cumbersome to start replication by calling the start API for each index. Same issue happens if you want to stop/pause replication on all indices. There is no API to provide the cluster level controls.
What solution would you like?
Add separate APIs to allow customer to stop/pause/resume replication for all the indices.
Do you have any additional context?
This was considered earlier as part of https://github.com/opensearch-project/cross-cluster-replication/issues/379, but since modifying the existing APIs would be tricky as the response would be completely different(partial failures, etc). We can go ahead and add these as separate APIs.

Hi @ankitkala
I see https://github.com/opensearch-project/cross-cluster-replication/issues/765 was created for BULK API support for CCR REST APIs. I'm not sure why, but that was closed without merging.
Can you help me understand how different is this feature from that and is this feature still intended to be planned :) ?


custom processors aren't executed in test environments

makes it really difficult to write a useful test or know that the code is actually working at all when there is no way to call sentry and have it actually use a processor in a testing environment.

Can you expand more on this? Processors don't really vary between environments.
What you're probably looking for is the dummy transport:
require 'raven/transports/dummy'

Raven.configure do |config|
  config.dsn = "dummy://12345:67890@sentry.localdomain:3000/sentry/42"
end


About convert_to_m2 function

Thanks for the release, I had some problems running the code;
I didn't find an implementation of the convert_to_m2 function in parallel_to_m2, causing the script reporting an error.
# RobustGEC-main/errant/errant/commands/robustgec_eval.py
from errant.commands.parallel_to_m2 import convert_to_m2

Is the implementation of the convert_to_m2 function not updated in the code?

Thanks for your kind remind. I have update the code, please let me know if you have any problem.


same modulename from different authors

Hi,
what's the best practice, if I have a Module theforeman-foreman_proxy which depends on theforeman-dns (which i don't need nor use) and i'd like to use ajjahn-dns from https://github.com/ajjahn/puppet-dns.git ? At the moment I get theforeman-dns by running librarian with this configuration:
mod 'theforeman-foreman_proxy', '2.1.0'
mod 'ajjahn-dns',
:git => 'https://github.com/ajjahn/puppet-dns'
Best regards,
Frank

On a similar note, am I the only that also found that if you have modules requiring different dependencies with the same name – librarian will happily plod along, download one... then overwrite it with the other – no error.
If what I am seeing is correct, that is crazy.
Example:
mod "puppetlabs-concat", "~> 1.2.0"
mod "puppetlabs/postgresql", "~> 2.4.1"

This left me with ripienaar-concat (0.2.0) – because I was using old postgresql module that requires it... this not causing an error in dependency resolution is nuts. NB: I saw whilst it was doing an update run – it'd install puppetlabs-concat first, then overwrite it.

Exclusions added in 1f3903e


cookie banner shouldnt show on the kit site

as far as I know, we dont use any cookies, so it's misleading and the link doesnt work

I think it's useful to have as a feature in the kit. Would you suggest disabling it for the demo site only?

yeh - the issue says 'kit site'

Had a quick look at the code. The banner div is hardcoded into the GOV.UK template so we can't remove it unless we update that.
Alternatively, on docs pages we can:

overwrite the message with an empty string
add some css or js to stop the div appearing

Thoughts?

I think this is no longer relevant. We now have google analytics, so we do have cookies. We should possibly have a cookie page instead!

Closing :-)


Setup super-linter

@ninok do you want to have this PR merged?

No, this was just for testing. I will close it.


Update suse-create-upload-vhd.md

Fixed spelling and grammar and swap partition creation steps.

@markusries - Thanks for your contribution! Note that the contractions correctly follow Microsoft's writing style. Is it possible to undo those changes?

@srijang
Can you review the proposed changes? (Specifically, the changes on lines 37, 158, and 163.)
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off


Compound strings

Find a place for a description on compound strings.
A compound string arises when we use two quoted strings without separation between them, that is to be treated as one string (e.g., one argument):
echo 'A"B"C'"D'E'F"

The echo command gets one argument: A"B"CD'E'F. Normally the two strings use different delimiters, but is entirely possible to use the same delimiter for both, though not particularly useful:
echo "ABC""DEF"
echo 'ABC''DEF'

Variable and command expansion is performed first, so will only work as expected with the double quoted part.

Fixed with https://github.com/incusdata/shs1st/wiki/01-Basic-Concepts#compound-strings


Netlify OAuth Provider

Feature request
Is your feature request related to a problem? Please describe.
Add Netlify OAuth provider
Additional context
https://twitter.com/jlengstorf/status/1429611357356187652

https://app.netlify.com/user/applications

Might need to hold off on this one until some of the security issues here are covered: https://community.redwoodjs.com/t/i-implemented-a-netlify-oauth-not-identity-auth-provider-but-im-not-sure-i-should-have-and-why/903

Hey all,
We plan on tracking all OAuth provider requests on https://github.com/supabase/gotrue/issues/451 so we'll be closing this issue in favor of the thread instead. Please feel free to follow along there instead.
Thanks!


MVP: Refactor Out Single Run Idea

Part of the MVP push: https://github.com/Autodesk/molecular-simulation-tools/issues/283
The app needs to be refactored to not have the overall idea of being based around one workflow run and instead support multiple.  The thank you page, error page, and the surrounding flow need to be removed.  Some of that code may be reusable in the RUN widget (https://github.com/Autodesk/molecular-simulation-tools/issues/288).

Closing with https://github.com/Autodesk/molecular-simulation-tools/pull/299


Generalize elbo for AbstractVAE

should be possible by introducing KL(m::AbstractVAE)

Well, I am not sure here as it will depend on how it is computed for particular VAE... depending on the distribution, whether you want to have the Beta in there, or ARD etc. I think that this is something every VAE should implement but I am not sure we can come up with a generalized method...

That is why we have functions encoder_mean_variance(). Each subtype redefine those, but elbo should be general.

done in #24


Adding layer is not added in image visualization notebook

I attempted to go through the image visualization notebook, but I receive this error:
AttributeError: 'Map' object has no attribute 'setOptions'

Me too!
GetStarted -> 10_get_started_with_EE.ipynb
Map = folium.Map(location=[40, -100], zoom_start=4)
Map.setOptions('HYBRID')


icon-spinner does not work in v2

The spinner do not work on v2

We have a bunch of tags in Camel that does a bit of init, and then shows a spinner while loading.

@gashcrumb do you know the new spinner for v2?

This one seems static (eg not animating)

try:

Yay that worked ;)


Multiple issues on Windows

I've tried to upgrade my version of the boilerplate (pre-release v3.0.0) to the latest version. I've done this by cloning this repo, running npm run setup and then tried to run npm run clean. This is where the first issue appeared:

Cleanup started... ✓'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
child_process.js:507
throw err;

Ignoring this, I manually deleted the demo app contents and replaced them with my own modules and dependencies. I've also changed the routes.js and app.js to mirror the changes made. Now when I run npm start the server gets started - but the webpack build runs ad infinitum whith 20% processor usage and never finishes. I don't know what causes this, and any help would be appreciated. I have my code hosted on bitbucket, so if anyone is willing to help me I will happily provide access to the repo for analysis.

This is the full error log shown in the command line when running npm run clean:
test-config.txt
I suppose it is a pathing issue with git being under Program Files(x86) and the " " cutting off the command to call git. Still don't know why the infinite build occurs. When I load the sample app, everything works fine. I have checked the files again, trying to find issues but couldn't come up with anything...

I sadly don't have a Windows machine, so I can't replicate this… @jwinn any input here?

I tried to replicate this on Windows 10 to no avail. Perhaps it's environment or permission specific.
Steps I performed:
mkdir C:\Projekte
cd C:\Projekte
git clone https://github.com/mxstbr/react-boilerplate test
cd test
npm run setup
npm test
npm start
npm run clean
npm start

My node, npm, and git are at the following:
C:\Users\jwinn>where node
C:\Program Files\nodejs\node.exe

C:\Users\jwinn>where npm
C:\Program Files\nodejs\npm
C:\Program Files\nodejs\npm.cmd

C:\Users\jwinn>where git
C:\Program Files\Git\cmd\git.exe

C:\Users\jwinn>systeminfo

Host Name:                 WINX
OS Name:                   Microsoft Windows 10 Pro
OS Version:                10.0.10586 N/A Build 10586
OS Manufacturer:           Microsoft Corporation
OS Configuration:          Standalone Workstation
OS Build Type:             Multiprocessor Free

Note: Used Chocolatey to install node and git and ran the commands in powershell.
I hope this helps. :-)

Hi @jwinn and thank you for your time. There was a second git.exe in my PATH which caused the error. This is fixed now.
For the infinite build - I've let the last build run for 72 hours over the weekend with no change. I've made another attempt at reproducing the issue.
I've now moved all my sagas & selectors with their components (sagas.js & selectors.js - just as in the example app). This works now by bootstrapping the sagas on my own. The only thing missing now from my previous configuration is the code-splitting of these sagas (utils/hooks.js & the change of routes.js to introduce sagas). This is something I would very much like to still implement. Do you know which PR(s) I need to look at only the code changes required for saga-splitting?

I think you're looking for #299 and #322?

I've adapted the changes from both PRs and ran into the same infinite build error. Can't find the issue with the files. I guess it's something within my existing code which causes the error. I've reverted to my version without code splitting. I'll close this now and come back to it when I find the time. Thank you for your help.

I'm seeing this as well on a clean pull of the project. I'm wondering if this has something to do with it? --https://github.com/nodejs/node/issues/7367

Actually, I found a good workaround.  If you are on windows you need to uninstall/reinstall node and git.  Just put the install folder in something like C:\tools or a path without a space.

Thank you for your suggestions. The issue I'm facing is probably related to my code. The sample app works fine and compiles well, but when I replace it with my existing code it runs into the infinite build error. I'm using nodejs & git in their standard install path, as well as using a command line with administrator rights. Nevertheless, if you find a fix to your issue I'd be happy to know about it to see if it indeed fixes my problem as well. Cheers!


feat(extras): Added support for ghostty

Adds support for @mitchellh's Ghostty terminal emulator.

Since the ghosttly terminal is still close source and not released I cannot confirm that these are correct. Do you have access to the beta and can confirm that these are correct?

I do have access to the beta and I can confirm that these themes work. Prior to this, I modified the kitty terafox theme (you can find it here: https://github.com/ethanholz/nix-config/blob/main/ghostty/config) and previously carbonfox to work with these.

@EdenEast If you're interested, I'd be happy to add you to the beta. Anyone who maintains anything in an ecosystem around terminal emulators (themes included) is an instant invite. No pressure, just wanted to offer. Join the discord and ping me and I'll add you: https://discord.gg/ghostty

Thanks for contributing. I looked at the extra generation and did some refactors, as I have not touched it in a while. I tried your Pr in ghostty and tested the changes. I will rebase your pr on the refactor that I did and merge this. Thanks for contributing and thanks @mitchellh for letting me try ghostty. Using it as my full time terminal with no issues. Feel the difference between my old terminal wezterm.

Excellent! I appreciate you taking the time to test this, thanks to @mitchellh for providing access to the beta!


chore(cxx_extractor): clarify differently rooted paths and clean up relative path names

Consistently omit the leading "./" from relative paths and make root-vs-working path mistakes harder to make in the future.

Actually, looking at the IndexVFS code, the indexer already handles .. and . components lexically; I can just implement the TODO..


YARN Client API Release 0.3.4

Yes, I wanted to make sure we have a release with recent compatible changes (release 0.3.4) and for the breaking changes that simplify the APIs, we make that 0.4.0


doc: fix body length in SMP UART transport

In the description of the partial-final frame of the SMP UART transport specification was a typo in the maximum allowed raw body size. The size must not be larger than MTU-5 because there are 5 bytes occupied by total length (2), frame termination (1) and crc (2).

@smnmsr Fix commit message to make compliance happy.

@smnmsr please fix compliance issue

@smnmsr can you help fix the CI compliance check failures.

@smnmsr for the record: `git commit --amend --author="First Last<EMAIL_ADDRESS>:)
@mmahadevan108 should be good to go now!


Update request: php83Extensions.swoole 5.0.3 → 5.1.1

Package name: php83Extensions.swoole
Latest released version: 5.1.1

Current version on the unstable channel: 5.0.3
Current version on the stable/release channel: 5.0.3

[x] Checked the nixpkgs pull requests

Notify maintainers

Note for maintainers: Please tag this issue in your PR.

Add a :+1: reaction to issues you find important.

Version 5.1.0 fixed compatibility of this extension with PHP 8.3, so the current version 5.0.3 is unusable with PHP 8.3. It outputs these build warnings/errors
In file included from /private/tmp/nix-build-php-swoole-5.0.3.drv-0/source/ext-src/php_swoole.cc:16:
In file included from /private/tmp/nix-build-php-swoole-5.0.3.drv-0/source/ext-src/php_swoole_cxx.h:19:
/private/tmp/nix-build-php-swoole-5.0.3.drv-0/source/ext-src/php_swoole_private.h:927:9: error: no matching function for call to 'php_>
        php_url_encode_hash_ex(HASH_OF(zdata), formstr, NULL, 0, NULL, 0, NULL, 0, NULL, NULL, (int) PHP_QUERY_RFC1738);
        ^~~~~~~~~~~~~~~~~~~~~~
/nix/store/1pcghr2r5lv6wsszp0l6ildih94s84vw-php-8.3.0-dev/include/php/ext/standard/php_http.h:24:13: note: candidate function not viab>
PHPAPI void php_url_encode_hash_ex(HashTable *ht, smart_str *formstr,
            ^
In file included from /private/tmp/nix-build-php-swoole-5.0.3.drv-0/source/ext-src/php_swoole.cc:30:
/private/tmp/nix-build-php-swoole-5.0.3.drv-0/source/ext-src/stubs/php_swoole_ex_arginfo.h:16:35: warning: incomplete universal charac>
        ZEND_ARG_OBJ_INFO(0, ctx, Swoole\\NameResolver\\Context, 0)
                                         ^
/private/tmp/nix-build-php-swoole-5.0.3.drv-0/source/ext-src/stubs/php_swoole_ex_arginfo.h:20:34: warning: incomplete universal charac>
        ZEND_ARG_OBJ_INFO(0, ns, Swoole\\NameResolver, 0)
                                        ^
2 warnings and 1 error generated.
make: *** [Makefile:210: ext-src/php_swoole.lo] Error 1

Could you please provide the PR to update this? I think it's a matter of changing 2 lines.


Concatenation operator "++" -  issue #215

Introduced a "variadic operator" which desugars into variadic function call.
Default sequences concatenation updated.
All tests updated.

Looks great! I think we could promote the arithmetic binary ops to variadic ops as well; add and multiply are already overloaded for variadic argument lists, and it would be easy to do the same for subtract, divide, and remainder.
I was thinking it'd also be cool to support Python-style chained comparisons (such as 3. <= a < 5. for 3. <= a and a < 5.).  What do you think of that?

On 18/02/12 19:51, Joe Groff wrote:

Looks great! I think we could promote the arithmetic binary ops to variadic ops as well; add and multiply are already overloaded for variadic argument lists, and it would be easy to do the same for subtract, divide, and remainder.

Where are  add and multiply  overloaded for variadic args?

I was thinking it'd also be cool to support Python-style chained comparisons (such as 3.<= a<  5. for 3.<= a and a<  5.).  What do you think of that?

Yeah, chained comparisons are a great feature.
I'll add the "++=".

Reply to this email directly or view it on GitHub:
https://github.com/jckarter/clay/pull/216#issuecomment-4036763


Expose pending decision task info

What changed?
Expose pending decision task info

Why?
Help user gain more insights to their workflow when decision task is keep failing.

How did you test it?
Tested locally

Potential risks
The risk of this change is minimal

Coverage increased (+0.02%) to 59.433% when pulling 0066a2f989a8023d7727f703146c0a99aeae3110 on yycptt:expose-pending-decision into 97d824e09d434005be98c445a7efeea4ed7d0633 on uber:master.


Footer get disappeared after opening advanced search dropdown in forum page (mobile devices)

Looking forward for reporting a security issue:
no, not a security issue.
Describe the bug
In mobile devices on forum page, it make sense to hide footer after opening advance search dropdown but why to hide footer even after user close advance search dropdown, doesn't make sense, don't even look good, not user friendly and make difficulty in navigations according to user choice.
To Reproduce
Steps to reproduce the behavior: (follow it in your mobile)

Go to 'https://www.freecodecamp.org/forum/search'
Scroll down to see footer, no go up Click on ''Advanced Search"
close Advanced search by clicking on dropdown.
See error footer will not appear...

Expected behavior
Footer should comeback when user will close Advanced search.
Screenshots

Smartphone (please complete the following information):
common problem in all smartphones.
Additional context
if this will get accepted, assigned it to me.

I believe this the default functionality.
You would need to dig into discourse's source code. Not sure if it is worth the hassle.
But, let us see other contributor's opinion.
Although if you are interested in looking into the forum's footer, you could start by re-implement the new footer on forum here: #38664

Can I try to fix this problem?

Hi, i think you can fix this issue in the css file, by adding for example :
.footer {
display: block;
}

Upon further review I could confirm that this is the default functionality for the footer on the search page.
Here is a similar example: https://community.smartthings.com/search
I don' think it is feasible to roll out a custom solution for this specific feature since doing so would be much more involved than changing the CSS.


Unused named function paramater causes rescript build -w to enter an infinite loop

The following module causes ReScript's watch mode to enter an infinite loop
@genType
let y = 5

let x = (a, ~b) => a

Repro:

Checkout https://github.com/tom-sherman/rescript-watch-infinite-loop-bug
npm i
npm start

Removing or using the unused param stops the loop.

Hey @tom-sherman I tried your repo and watch mode did not enter an infinite loop.

@a-c-sreedhar-reddy what OS? I'm in macOS 11.6

yeah I am also on macOS 11.6

https://user-images.githubusercontent.com/9257001/147350957-f5aaaacd-3a70-4770-8173-987042677a44.mov
Very strange...

Node v14.18.0
npm 6.14.15

Caused by an interaction of generatedFileExtension": ".gen.ts"
and the compilers watcher.
There was an issue on this already, which has moved to the compiler repo.

This repository is being archived. If you feel like the issue still relevant, please re-create it in the compiler repo. Thanks!


Make dataset indexing O(1)

It was accidentally O(n), since it was checking whether the index was in bounds by checking if it was in a list (with idx not in list), which uses a linear scan. Since all indexes are contiguous anyway, this is replaced by idx < 0 and idx >= len(self).
Fix #788, thanks @frostedoyster for the detailed reproduction, it really helped identifying the issue!
Contributor (creator of pull-request) checklist

[ ] ~Tests updated (for new features and bugfixes)?~
[ ] ~Documentation updated (for new features)?~
[x] Issue referenced (for PRs that solve an issue)?

Reviewer checklist

[ ] ~CHANGELOG updated with public API or any other important changes?~

Thank you for the fix!


include contact and feedback links

could be email link, but you could also make an office form to collect more structured feedback?

For now, I have added an email and repo link for issues.
I will add also the link for an Office Form, currently thinking how to structure it


Containerd reports image names as null for the images have no tag and digest

Description
A container image is pulled with no tag and digest. "crictl image ls" shows <none>:<none>.   Kubernetes node status shows null as the names for the image.  If the status shows null for the name, it breaks compatibility with the spec and if you try to manually edit a node (kubectl edit), you will see an error that null is not an allowed value for names.
The names field in the v1.ContainerImage is required.
https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/api/core/v1/types.go#L4797
Steps to reproduce the issue:
I have no idea how the <none>:<none> image gets pulled on my system.
IMAGE                                            TAG                                                    IMAGE ID           SIZE
<none>                                           <none>                                                 09e39a8bcc0f6      177MB
registry.local:9001/quay.io/airshipit/armada    8a1638098f88d92bf799ef4934abe569789b885e-ubuntu_bionic 3061a8a540ac0       177MB

crictl inspecti 09e39a8bcc0f6
{
  "status": {
    "id": "sha256:09e39a8bcc0f683585c467ae37ef4757d6fcdef3eb31a2092aabac6edc9d3226",
    "repoTags": [],
    "repoDigests": [],
    "size": "177332929",
    "uid": null,
    "username": "armada"
  },

Kubernetes shows the 'null' image name.
kubectl get nodes controller-0 -o yaml
apiVersion: v1
kind: Node
metadata:
  annotations:
    kubeadm.alpha.kubernetes.io/cri-socket: /var/run/containerd/containerd.sock
...
status:
  images:
  - names: null
    sizeBytes: 177332929

Describe the results you received:
When null image appears, kubectl edit node controller-0 didn't work with the error.
# nodes "controller-0" was not valid:
# * : Invalid value: "The edited file failed validation": ValidationError(Node.status.images[11]): missing required field "names" in io.k8s.api.core.v1.ContainerImage

Describe the results you expected:
containerd  doesn't report null image if image has no tag and digest.
Output of containerd --version:
containerd github.com/containerd/containerd v1.3.3 .m
Any other relevant information:
The same issue reported in CIRO - https://github.com/cri-o/cri-o/issues/2454.
Expect the fix in https://github.com/cri-o/cri-o/pull/2455/ to be implemented in containerd.
The fix is also in https://github.com/moby/moby/blob/master/daemon/images/images.go#L180-L181.
I think the fix should be done in pkg/cri/server/image_status.go
func toCRIImage(image imagestore.Image) *runtime.Image {
	repoTags, repoDigests := parseImageReferences(image.References)
	runtimeImage := &runtime.Image{
		Id:          image.ID,
		RepoTags:    repoTags,
		RepoDigests: repoDigests,
		Size_:       uint64(image.Size),
	}
	uid, username := getUserFromImage(image.ImageSpec.Config.User)
	if uid != nil {
		runtimeImage.Uid = &runtime.Int64Value{Value: *uid}
	}
	runtimeImage.Username = username

	return runtimeImage
}

The <none>:<none> is kind of a hack and existed in docker to satisfy the CLI output. Is this enshrined somewhere in the Kubernetes API? If this isn't explicit in the API, this seems more like an issue that should be fixed in k8s rather than inserting a fake <none> repository name to API output.

@dmcgowan Yes, this is a workaround and can be removed after the bug is fixed in k8s. The bug https://github.com/kubernetes/kubernetes/pull/79018 was reported in k8s but it was closed without a fix yet.

Would it make sense to not include images that don't have names/tags instead of crafting a non-sense name?
Seems like we should have some solution anyway until the API is fixed.


onevpl-intel-gpu: Rename to vpl-gpu-rt

Description of changes

Intel has merged the oneapi-src GitHub organization into the intel namespace. oneVPL-intel-gpu has been renamed to vpl-gpu-rt as part of this move. The repo at https://github.com/oneapi-src/oneVPL-intel-gpu now redirects to https://github.com/intel/vpl-gpu-rt.
I've updated the package src and name attributes and moved it from  pkgs/by-name/on/onevpl-intel-gpu to pkgs/by-name/vp/vpl-gpu-rt. I've also introduced a top-level alias with a warning for onevpl-intel-gpu.
There are no dependent packages. The wiki also does not document or refer to onevpl-intel-gpu (although it should probably).
Users of onevpl-intel-gpu will by notified by the warning on evaluation.
Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Forgot to tag the maintainer: @evanrichter

I'd be glad to have you co-maintain, you've been submitting great patches! Tag me in that pr, I'll definitely approve

Who is supposed to do a final review and merge this PR after maintainer approval. What is the procedure here?

Practically any committer who has noticed the PR. If not in a week, you can send the PR to https://matrix.to/#/#review-requests:nixos.org.

I would love some good documentation on the intel gpu stack! Right now it's hard to know what packages I need to get hardware acceleration working in all my applications, ffmpeg, etc.


Optimize performance

While connected, I'm getting occasional fps drops while playing on RuneLite.  Perhaps add an option to reduce the amount of info you're pulling from the client or an option to change how often you're sending data to the server.
Also, the front-end uses way too much CPU; It's not really possible to smoothly play OSRS while keeping the front-end GIMP-Tracker page open.  I'm using an i5-9600k and its running at nearly 100% whenever the front-end is open:

I'm using Opera GX - the issue was fixed once I turned on hardware accel.

I have the same issue
very slow fps on Runelite when the front end is open

Yea im not sure whats causing it tbh, it started lagging for me aswell when I enabled HD, I kinda refuse to believe my code for creating packets would cause lag spikes. Someone suggested it could be socket io doing some weird stuff which im not keen on rewriting right now. If you really wanna use the plugin, try disabling some other plugins to see if it fixes the lag

In regards to the RL client lag, maybe these details could help others debug:
I've had a quick look at the client code and couldn't notice anything that was done inefficiently/improperly, I tried a few small fixes but same behavior. I am not the most experienced with Java so I don't mean to imply nothing can be improved, anyone who is willing, feel free to have a look! Looks very well optimized to me. Here is a little video to showcase the lag: https://gfycat.com/nearshinyflatfish - pretty minimal in my case, tolerable, but pretty annoying (I disconnect halfway through the clip and it fixes it, it's clearly caused by the socket.emit() function calls). Doesn't happen with HD off so I think it's a case of the cpu being a little overloaded with all the plugins, since osrs runs off only 1 core. However this plugin shouldn't have much load on the cpu, so I think you're right in assuming that it's the socket.io library doing some weird things. I looked for more initialization options, like turning off compression (since that is a default option in the JS library), but it doesn't seem to be an option with the Java library.
Also, my buddy has the same cpu as me but doesn't get the lag, so I'm not too sure if it's really cpu related. He gets similar FPS dips, but it doesn't cause the same 'jittery' behavior that I get. I also don't get the issue with HD off.
Rewriting it to use normal HTTP requests rather than sockets might fix it, but I'm equally not keen on rewriting that. Though that doesn't really make sense, sockets were definitely the right way to do this.


[WIP][SPARK-29320][TESTS] Compare sql/core module in JDK8/11

What changes were proposed in this pull request?
This PR regenerates the sql/core benchmarks in JDK8/11 to compare the result. In general, we compare the ratio instead of the time. However, in this PR, the average time is compared. This PR should be considered as a rough comparison.
A. EXPECTED CASES(JDK11 is faster in general)

[x] BloomFilterBenchmark (JDK11 is faster except one case)
[x] BuiltInDataSourceWriteBenchmark (JDK11 is faster at CSV/ORC)
[x] CSVBenchmark (JDK11 is faster except five cases)
[x] ColumnarBatchBenchmark (JDK11 is faster at boolean/string and some cases in int/array)
[x] DatasetBenchmark (JDK11 is faster with string, but is slower for long type)
[x] ExternalAppendOnlyUnsafeRowArrayBenchmark (JDK11 is faster except two cases)
[x] ExtractBenchmark (JDK11 is faster except HOUR/MINUTE/SECOND/MILLISECONDS/MICROSECONDS)
[x] HashedRelationMetricsBenchmark (JDK11 is faster)
[x] JSONBenchmark (JDK11 is much faster except eight cases)
[x] JoinBenchmark (JDK11 is faster except five cases)
[x] OrcNestedSchemaPruningBenchmark (JDK11 is faster in nine cases)
[x] PrimitiveArrayBenchmark (JDK11 is faster)
[x] SortBenchmark (JDK11 is faster except Arrays.sort case)
[x] UDFBenchmark (N/A, values are too small)
[x] UnsafeArrayDataBenchmark (JDK11 is faster except one case)
[x] WideTableBenchmark (JDK11 is faster except two cases)

B. CASES WE NEED TO INVESTIGATE MORE LATER

[x] AggregateBenchmark (JDK11 is slower in general)
[x] CompressionSchemeBenchmark (JDK11 is slower in general except string)
[x] DataSourceReadBenchmark (JDK11 is slower in general)
[x] MakeDateTimeBenchmark (JDK11 is slower except two cases)
[x] MiscBenchmark (JDK11 is slower except ten cases)
[x] OrcV2NestedSchemaPruningBenchmark (JDK11 is slower)
[x] ParquetNestedSchemaPruningBenchmark (JDK11 is slower except six cases)
[x] RangeBenchmark (JDK11 is slower except one case)

/DateTimeBenchmark/FilterPushdownBenchmark/InExpressionBenchmark/WideSchemaBenchmark will be compared later.
Why are the changes needed?
According to the result, there are some difference between JDK8/JDK11.
This will be a baseline for the future improvement and comparison. Also, as a reproducible  environment, the following environment is used.

Instance: r3.xlarge
OS: CentOS Linux release 7.5.1804 (Core)
JDK:

OpenJDK Runtime Environment (build 1.8.0_222-b10)
OpenJDK Runtime Environment 18.9 (build 11.0.4+11-LTS)

Does this PR introduce any user-facing change?
No.
How was this patch tested?
This is a test-only PR. We need to run benchmark.

Test build #111697 has started for PR 26003 at commit b4bbff4.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/16690/
Test PASSed.

I am just wondering why the PR removes 2 times more lines +1,675 −3,064?

Test build #111699 has started for PR 26003 at commit d7d665c.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/16692/
Test PASSed.

Test build #111697 has finished for PR 26003 at commit b4bbff4.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/111697/
Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/16696/
Test PASSed.

Test build #111703 has started for PR 26003 at commit b399f0e.

Test build #111699 has finished for PR 26003 at commit d7d665c.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/111699/
Test PASSed.

For a better commit log, how about putting benchmark env info below in the PR description?
OpenJDK 64-Bit Server VM 11.0.4+11-LTS on Linux 3.10.0-862.3.2.el7.x86_64
Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz

Test build #111706 has started for PR 26003 at commit 9eb1e83.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/16699/
Test PASSed.

Test build #111703 has finished for PR 26003 at commit b399f0e.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/111703/
Test PASSed.

Test build #111706 has finished for PR 26003 at commit 9eb1e83.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/111706/
Test PASSed.

Test build #111718 has started for PR 26003 at commit d2e561b.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/16710/
Test PASSed.

Test build #111718 has finished for PR 26003 at commit d2e561b.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/111718/
Test FAILed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/16717/
Test PASSed.

Test build #111728 has started for PR 26003 at commit f06a25f.

Thank you for review, @MaxGekk ~

Test build #111728 has finished for PR 26003 at commit f06a25f.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/111728/
Test PASSed.

Thank you, @srowen and @MaxGekk . There are many factors are considered.
Usually, we had better change one factor only. I'll move forward for now with your advices (the number of iterations and kernels.
Merged to master.

Until now, I used the same official CentOS AMI and didn't change to compare the code-change only. As a follow-up of this PR, I took a look at the recent one according to the review comments.
The latest CentOS AMI is ami-01ed306a12b7d1c96 (CentOS Linux 7.6.1810 x86_64 HVM EBS ENA 1901_01-b7). Unfortunately, it's also using Linux version 3.10.0-957.1.3.el7.x86_64.
To use Kernel 4.x, It seems that we need to choose Ubuntu or Amazon Linux from now. I'll try to use one of them for the remaining benchmarks.


show alarms in the widget

It would be very nice if alarms would be included in the widget too.

Do you mean "Reminders"? Please see https://github.com/plusonelabs/calendar-widget/issues/220

I was referring to the alarms set by the clock app, which also makes a small icon appear in the status bar.

The Calendar Widget shows all "events", which are exposed/provided via the Android Calendar Provider API ( https://developer.android.com/guide/topics/providers/calendar-provider.html ). This allows us to show events, created by any application, which supports this API.
This means that some "Clock application" could also be a source of "Alarm events".
If you will find such an application, please let us know here: this will be helpful for others. If not, we will have to use "reminders" , which already exist in Calendar applications and which are shown in the Calendar Widget.

I was talking about the stock Clock application which does not create an event or reminder within the Calendar but does set an alarm.
Probably there is a way to access the list of active alarms and then add them to the Calendar Widget.
See http://stackoverflow.com/questions/3147179/get-all-alarms-saved-in-the-alarm-application.
There is a similar feature on IOS, swiping right will show the list of future events and clock alarms.

It looks like what you are talking is about the "Alarm Clock events" and they can be accessed via the AlarmManager https://developer.android.com/reference/android/app/AlarmManager.html
As I see, there is a method to see only one, next scheduled Alarm Clock only: https://developer.android.com/reference/android/app/AlarmManager.html#getNextAlarmClock()

Well, I guess that's fine. An usual use case would be to set your morning alarm once per day or have it repeating on certain days.
You would not be interested in seeing the whole list of alarms, just the next one.


Inconsistent policy resource filter enum field

Describe the bug
Policies with either urn or resource type resource filter don't work properly with current master.
To Reproduce
Steps to reproduce the behavior:

Go to permissions view
Create new policy with either urn or resource type filter (i.e. one applied only to datasets)
Try to perform allowed action (make sure user performing action is not granted privilege to perform it through any other policy but the one created in step 2

Expected behavior
User is allowed to perform the action thanks to newly created policy.
What actually happens
User is not allowed to perform the action. Moreover I can see line in GMS logs (this one in particular if policy defines resource type:
ERROR c.datahub.authorization.PolicyEngine:217 - Unsupported field type RESOURCE_TYPE

Moreover UI policy detail view does not show Resource Types/Urns correctly (shows All instead).
Analysis and impact
The problem appears likely due to this change:
https://github.com/datahub-project/datahub/pull/8846/files#diff-58b6f3004a3b455a942ba12668b065ba8e19ea6be368f1806490d2ebfd564868L10
which now became:
https://github.com/datahub-project/datahub/pull/8846/files#diff-4d637a551329664ce27ddbbffe2ea1566e42937057aee439abdfb8e712753e22R10
This causes any policies with urn or resource type resource filter to not work properly and producing the ERROR log mentioned above. This problem affects both policies existing at the time of upgrade and any newly created via UI.
Fixing the problem in UI seems to be quite straight-forward but to change existing aspects in relational database will require some custom upgrade logic.
Temporary work-around
Policies can be updated manually via datahub put command sending dataHubPolicyInfo aspect with filter looking like:
   "resources": {
     "filter": {
       "criteria": [
         {
           "field": "TYPE",
           "condition": "EQUALS",
           "values": [
             "dataset"
           ]
         }
       ]
     }

instead of
   "resources": {
     "filter": {
       "criteria": [
         {
           "field": "RESOURCE_TYPE",
           "condition": "EQUALS",
           "values": [
             "dataset"
           ]
         }
       ]
     }

Thank you for opening this ticket @skrydal, I am in the process of creating a fix for this!

Hi @pedro93
Thank you for notifying me. I have already created a PR fixing UI:
https://github.com/datahub-project/datahub/pull/9087
Weren't sure where to add custom upgrade logic fixing existing aspects.

Will look at the PR, thanks for the contribution!
Regarding upgrade logic. Since the PR that broke this wasn't released in a previous version of DataHub, it means that the folks affected by this are the ones running DataHub on non-released, bleeding-edge docker tags like head.
This is ok I think for quickstart use-cases where folks can just reset their databases.
For other cases I think having a release note about this with your work-around is sufficient.
What do you think?

Thank you for quick review and merge of the changes. I created PR with docs change here:
https://github.com/datahub-project/datahub/pull/9093
As I applied the change manually myself in my environments, it is fine with me. Although I thought there would be some automated mechanism in place updating aspects for which schema changed (obviously requiring custom logic for each case). Is there such thing available in the datahub, in general?

Although I thought there would be some automated mechanism in place updating aspects for which schema changed
We have the upgrade jobs (old version) or system update job (new version) which right now only performs ES migrations but since this is a bug that wasn't released on a stable version, we won't be creating such a job this time around.

FYI I'm going to add support for both policy schemas in the code which will remove the need for an update process.


Fallback to AZURE_CLIENT_ID env var if no client_id query param in token request

This is still up for debate so I didn't want to add this as part of this PR. I'll add a follow-up PR once we make a decision on this.
Originally posted by @aramase in https://github.com/Azure/aad-pod-managed-identity/pull/142#discussion_r688030472

I realize this issue is a bit old, but are there any further thoughts on this? The current behavior is making it challenging to move certain third-party applications (such as Pulumi) from aad-pod-identity to Workflow Identity.

I realize this issue is a bit old, but are there any further thoughts on this? The current behavior is making it challenging to move certain third-party applications (such as Pulumi) from aad-pod-identity to Workflow Identity.

@polivbr Can you provide more details on why this is blocking your move to workload identity?

In the particular case of Pulumi, the Azure provider currently doesn't handle OIDC auth, so I have to use MSI. When configured to use MSI, rather than looking for an AZURE_CLIENT_ID environment variable, it looks for ARM_CLIENT_ID. If it's not set, it doesn't pass the client_id query param, as it assumes it's not needed, which worked fine with aad-pod-identity but breaks with workload identity.
This isn't a showstopper as I can work around it, but it cost me many, many hours trying to debug exactly why it was failing.

Am currently stuck on this. Tried to integrate fluxcd Image update automation but image-reflector-controller pod would spit out a message The client_id parameter is required. as they do not include client_id when making a call to the metadata endpoint

This is now causing me issues with services that use the rust sdk. Its identity library doesn't currently support OIDC and code that uses its default token credentials won't pick up a client_id.
Is there a reason to not enable this fallback? Seems like not doing so causes way more issues than it could possibly be solving. It has literally broken every app I've attempted to deploy and now I'm faced with one for which I don't have a workaround.

I'm ok with adding the fallback to AZURE_CLIENT_ID. This issue was opened to solicit feedback to see if it's required. I'll include this in the next release.

Excellent. Thank you!


Not able to do inference.

When I am running given inference command it shows
  File "/home/ajeet/MakeLongVideo/makelongvideo/models/unet_blocks.py", line 64, in get_down_block
    raise ValueError(f"{down_block_type} does not exist.")
ValueError: ResnetDownsampleBlock2D does not exist.

@xuduo35 Can you please look. I have installed all requirements and downloaded checkpoints

I don't work on this project some months. But I reinstall a clean env and didn't meet this issue. Can you paste the full trace stack?


[test] Add JupyterHub submission test

Fixes UES-522.

Codecov Report

Merging #1033 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1033   +/-   ##
=======================================
  Coverage   91.97%   91.97%
=======================================
  Files          81       81
  Lines       10937    10937
=======================================
  Hits        10059    10059
  Misses        878      878

Continue to review full report at Codecov.

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

@jenkins-cscs retry all

For the CI failure, check here.

@jenkins-cscs retry daint


[EMB-351] Change local storage key used by ember-simple-auth

Purpose
When an embosf page is open in one tab and preprints (or maybe reviews?) in another tab, they try to store different auth data in local storage, using the same key. This causes an infinite loop of each app clobbering the other's data and making API requests, until one of the tabs is closed.
This might have been causing subtle, strange bugs in preprints, but it's hard to say what they might have looked like.
Summary of Changes
Configure ember-simple-auth's AdaptiveStore, changing the local storage key used.
Side Effects / Testing Notes

Open the dashboard and preprints in separate tabs (same environment, same browser)
Open the devtools network tab in either/both tabs
Previously, there would be repeated requests to /v2/ (in embosf) or /v2/users/me (in preprints). Now, all should be calm.

Ticket
https://openscience.atlassian.net/browse/EMB-351
Reviewer Checklist

[ ] meets requirements
[ ] easy to understand
[ ] DRY
[ ] testable and includes test(s)
[ ] changes described in CHANGELOG.md

Pull Request Test Coverage Report for Build 1355

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.006%) to 61.194%

Totals

Change from base Build 1354:
0.006%

Covered Lines:
2215

Relevant Lines:
3432

💛  - Coveralls