don't propagate hotkey to current website

I defined hotkeys that have functionality on some websites and I would like to prevent that the hotkeys are also triggering that action on the website that is currently opened in Firefox. Is this possible?

Hi SpineEye,
I am not getting what is your issue here. Do you want to block the custom Spotify shortcuts in some websites or block other hotkeys that you have which are in conflict with the Spotify ones?

Hey,
I just figured this might be a Firefox restriction, I think it's better explained with an example: I have assigned one shortcut to shift+alt+x. When I press these keys while I'm on Wikipedia, instead of playing the next song, Wikipedia shows me a random article since this is apparently their hotkey for it. But I don't want their function to be executed, I just want to play the next song.

Hi,
Thank you for the example, now I understand what you are asking.
In the first place, I need to explain something: it is "theoricaly possible" to stop the propragation of the hoykeys/events but it is not really recommendable. In short, if, for example, the propagation of a shortcut stops, bugs and unexpected events can occur, since the events are global objects and the external code can depend on them. Dangers of Stopping Event Propragation
For the moment, I do not consider it appropriate to manage such cases for possible failures that may cause.
That said, I would recommend that you change the hotkey to another one that does not cause trouble.
I am sorry I can not be more helpful.

Using the default hotkeys (alt+shift) I have never encountered a conflict.
Also, as I said before, I am totally against interfering with the behavior of other websites if it is not essential.
However, I will look at some possible solution but I do not promise anything.


What's the difference between the three methods of epoch or iteration?

parser.add_argument('--train_epochs', default=10, type=int,
help= 'Number of epochs')
parser.add_argument('--fixed_number_of_epochs', default=None, type=int,
help= 'Fill a fixed number of train iterations to use that instead of early stopping based on a validation set')
parser.add_argument('--fixed_number_of_train_iterations', default=None, type=int,
help= 'Train for a fixed number of iterations, like in the localization stability paper')

Hi there @HZJ6 ,
My apologies for the extremely late reply. I've been focussed on other things for quite some time. I'm not sure what each parameter does in the code that I put here eventually (as mentioned, it's research code, not production code, so quite a bit of spaghetti code duct-taped together :))
However, one of the problems I faced was: when do you decide to stop with training when comparing several iterations of the active learning algorithm. Early stopping in ML theoretically should give you the best result for each epoch. On the other hand, what if you are just (un)lucky what the validation set of a certain experiment. If a validation set is particularly easy, this will result on an artificially high score, which doesn't necessarily generalise well.
In theory it shouldn't matter, you do enough runs of the same experiment, and you'll converge on which active learning method works better. My experiment runs where however quite computationally expensive, so in the end I wanted to reduce the number of parameters that influenced the result of the experiment (having a good or a bad validation set was one).


Lazily initialize ModuleInfo.BuildId

Contributes to #625
Some questions:

IDataReader.GetVersionInfo is a void method with an out parameter?

IDataReader.GetVersionInfo is a void method with an out parameter?

That's one of many things I want to change on IDataReader, but I also want to do them all as one checkin because I know at least one team already using ClrMD 2.0 with a custom datareader and I'd like to minimize impact.
Some other IDataReader problems:

Remove IsFullMemoryAvailable, EnumerateAllThreads, etc that aren't used.
Remove QueryMemory or put it on IMemoryReader.
GetVersionInfo should return a bool.
Consider changing IDataReader to an abstract base class, or make DataTarget's constructor take an abstract base class that contains a data reader instead of the current design.  Essentially I'd like to be able to add "optional" properties and functions to data readers without it being a breaking change.  Since we support desktop CLR, I can't use interface default methods...

It's on my todo list for the API review phase.  I'm wrapping up minidumps now.

@NextTurn This checkin may have conflicts with https://github.com/microsoft/clrmd/pull/635.  Please mark this PR as ready when it's ready for merge.  I'll be happy to merge this one first and resolve the conflicts if this one is done before https://github.com/microsoft/clrmd/pull/635.


Update Composer dependencies (2021-05-02-00-05)

Visual regression test passed!
View the visual regression test report


Cannot Get Decent Results in Unseen Images

Hi,
I am testing unseen images on the pretrained model daclip_ViT-B-32.pt and it seems that model is not working well. There is no or very slight changes in the images. As an example, here is the original image and the output image, respectively.

Is there a problem related to the pretrained model or is this a normal behavior on unseen images due to the limitations of the training dataset of the pretrained model?
Thanks.

Hi it's a normal result due to the dataset limitations (we didn't add the old photo recovering task in our training). For the above case, you can try this work.


U6 news detail

Summary
Layout for news detail has been developed, Like Status now updates when you push the Toggle Button in news list
Screenshot

Trello Card
https://trello.com/c/dnT1JLiQ/8-u6-frontend-and-backend-news-detail

fixes uploaded @lmiotti

changes uploaded


In InDesign, the built-in utils do not work

In InDesign, the built-in utils do not work.
Panel.vue loadUtils () -- gehenna() failed to load the built-in utils, because of the CSInterface.evalScript return "" in library<EMAIL_ADDRESS>tested under PS, evalScript return “undefined”,  loadUtils() without error.
You've noticed this problem<EMAIL_ADDRESS>async function evalScript(text, defs = {}) {
  if (!isBrowser) {
    let CS_Interface = new CSInterface();
    return new Promise((resolve, reject) => {
      CS_Interface.evalScript(`${text}`, (res) => {
        // For some reason this was returning errors in InDesign alone. No idea why
        resolve(isJson(res) ? JSON.parse(res) : res);
        // if (res) resolve(isJson(res) ? JSON.parse(res) : res);
        // else if (res.length) reject({ error: res });
      });
    });
  } else return defs;
}

But gehenna's dependent library version is still 0.07.

Will be looking into this very soon -- don't personally script for IDSN very often and just happened to catch this while doing testing for the themes in IDSN I believe. Let me know if you've already solved it on your end too!


SOAP to REST feature does not support generating OpenAPI3.0 swagger definitions

Description:
In the current implementation of SOAP to REST feature in 2.5 and 2.6, the generated swagger API is based on OpenAPI 2.0 specifications. It does not support generating OpenAPI 3.0 supported swagger APIs. It is because we are currently using openapi 2.x swagger parser in our implementation. When there is a requirement to have OpenAPI 3.0 in client side, according to the current implementation, the client has to maintain two OpenAPI definitions for client and backend (apim swagger definition and converted OpenAPI3 definition) .
Suggested Labels:
Improvement
Suggested Assignees:

Affected Product Version:
2.5.0, 2.6.0
OS, DB, other environment details and versions:
Steps to reproduce:
Related Issues:

Tagging https://github.com/wso2/product-apim/issues/7130


It seems that  no transport client function is available.

elastic.v5 (for Elasticsearch 5.x)
It seems that  no transport client function is available.

Transport Client is deprecated. We only support HTTP client.


D415 loses IR stream on restart...

I got my D415, and there are no issues with regards to grabbing IR and depth; however, I did have an issue with trying to write to a memory card on the same USB 3 hub as the sensor.  After a while, the camera stops returning video in the 100 msec time I expected it.  I suspect that the bus is busy writing video to disk, but its not this specific situation that is the problem.  What is the problem is that I decided that if this situation happens where the camera stops sending video, I’d like to be able to reset the connection and restart the video.  So I wrote a version of my code that grabs video, and then on the 50th frame, just decides to close the connection, deleting all pointers to RS objects, and then tries to reconnect from scratch.  On the restart, the particular video stream of IR video at full resolution and 30 fps is no longer listed as an available stream.  All the other resolutions and frame rates are still there, just not the one I was using before I triggered the reset.

Hi @drhalftone
Could you please specify what operating system you are using, and attach the output of rs-enumerate-device -m before and after the reset?

Hello @drhalftone,
Do you still need help with this issue?
Regards,
Jesus G.
Intel Customer Support

Yes, I will post a sample application to demonstrate the issue shortly
On Feb 15, 2018, at 6:18 PM, Jesus Garcia<EMAIL_ADDRESS>wrote:
Hello @drhalftone https://github.com/drhalftone,
Do you still need help with this issue?
Regards,
Jesus G.
Intel Customer Support
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/IntelRealSense/librealsense/issues/1164#issuecomment-366094851, or mute the thread https://github.com/notifications/unsubscribe-auth/AKL1oskhywWnuQ3Lr3x0TUYyAR5OqPJuks5tVLtQgaJpZM4SBJGU.

I have the D415.  Is there a function call for advanced mode that I’m missing in my code?
On Feb 20, 2018, at 1:24 PM, Geoff<EMAIL_ADDRESS>wrote:
It sounds like the camera is going out of advanced mode.
I've noticed that the IR streams on the D435 are only available when the device is in advanced mode.
You can programatically check if the device is in advanced mode.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/IntelRealSense/librealsense/issues/1164#issuecomment-367071052, or mute the thread https://github.com/notifications/unsubscribe-auth/AKL1ojSwnMEfAZLGJm51_GBDCDBnAiGMks5tWw3RgaJpZM4SBJGU.

Found the C++ version while looking for our own uses: https://github.com/IntelRealSense/librealsense/blob/9437bc24c0f4ce16193f1045ceea703a8151b96d/src/ds5/advanced_mode/advanced_mode.cpp

This seems like way overkill.  In my original application, I had no problem grabbing IR over depth.  I just couldn’t reset the camera to start over.  In the test application I posted, I have no problem grabbing IR over depth for those first 15 frames.  But it stops on the 16th.
Do you really think this is necessary to get basic functionality out of the camera?
On Feb 20, 2018, at 3:29 PM, ioreed<EMAIL_ADDRESS>wrote:
Found the C++ version while looking for our own uses: https://github.com/IntelRealSense/librealsense/blob/9437bc24c0f4ce16193f1045ceea703a8151b96d/src/ds5/advanced_mode/advanced_mode.cpp https://github.com/IntelRealSense/librealsense/blob/9437bc24c0f4ce16193f1045ceea703a8151b96d/src/ds5/advanced_mode/advanced_mode.cpp
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/IntelRealSense/librealsense/issues/1164#issuecomment-367108305, or mute the thread https://github.com/notifications/unsubscribe-auth/AKL1orOn6AxUBLK_er93xILiCPz9sLo6ks5tWyrbgaJpZM4SBJGU.

Just a user, not from Intel. As best we can tell, the code is a cpp implementation of advanced features like those in the RealSense viewer.  We are implementing some of these in our code. The response is an answer to your original question, "Is there a function call for advanced mode that I’m missing in my code?" The idea is to use the example as a starting point and implement what you need. There are some very useful features in there for noise reduction, etc.
We found that many lock-ups and other problems were solved by using USB 3.1 (not USB 3.0). There is a good Linux compatible card on Amazon at https://www.amazon.com/gp/product/B018YSB2I8/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1. We upgraded a five yr old Dell running Ubuntu 16.04 LTS with this and can run our D415 on a 3m USB cable without loss.

@drhalftone regarding the issue of streaming past 15 frames, this is expected behavior if you don't release frames. I confess I have not looked at your code so do not know if that is your specific issue, but it sounded familiar enough that I thought I would add that recommendation.

Interesting.  Which frame am I supposed to release.  I have the following line of code:
 rs2_frame *frames = rs2_pipeline_wait_for_frames(pipeline, 15000, &err);

followed by:
 rs2_frame *frame = rs2_extract_frame(frames, n, &err);

I later release "frame" with:
 rs2_release_frame(frame);

but not "frames"  How do I release "frames"

Hi @drhalftone
You should release frames in the same way. Alternatively, you can call rs2_keep_frame if you want to keep more then 16 frames at a time (at some minimal performance expense)

yes close it.
On Apr 15, 2018, at 11:18 PM, RealSense Customer Engineering<EMAIL_ADDRESS>wrote:
[Realsense Customer Engineering Team Comment]
@drhalftone https://github.com/drhalftone
Do you still have issue on this topic? Can I close it?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/IntelRealSense/librealsense/issues/1164#issuecomment-381469038, or mute the thread https://github.com/notifications/unsubscribe-auth/AKL1oqJdwhu_OYlN6fb1_IYwhy8GyuH3ks5tpA16gaJpZM4SBJGU.


python 3 compatibility: SimpleHTTPServer became http.server

python 3 compatibility: SimpleHTTPServer became http.server
see http://python-future.org/compatible_idioms.html
currently on py3 it fails with:
bin/python: No module named SimpleHTTPServer

LGTM


cannot locate the cursor correctly after toggling soft wrap

It seems like the plugin cannot locate the cursor correctly after toggling soft wrap. It somehow misses the lines with soft wrap. I am using Ubuntu 14.04

already fixed, use the latest version


Array reverse.java

bringing it all in

[x] Read all of the following instructions carefully. Name things exactly as described.
[x] Do all your work in a public repository called data-structures-and-algorithms.
[x] Create a new branch in your repo called array-reverse.
[x] Your top-level readme should contain a “Table of Contents” navigation to all of your challenges and implementations so far. (Don’t forget to update it!)
[x] This assignment should be completed within the challenges subdirectory of the repository (called mine java-code-challenges, will amend if necessary)
[x] On your branch, create: a file called ArrayReverse.java
[x] Include any language-specific configuration files required for this challenge to become an individual component, module, library, etc. (gradle / gradlew in place)

Feature Task

[x] Write a function called reverseArray which takes an array as an argument. Without utilizing any of the built-in methods available to your language, return an array with elements in reversed order.

[ ] Copy your photo into /assets (not necessary for assignment)

[ ] Give the image file the same name as the working branch (not necessary for assignment)

[ ] Embed the image in your README.md documentation (not necessary for assignment)

[x] Create a pull request from your branch to your master branch


GCE client: does not automatically reconnect after network disruption

I disconnected and reconnected to wifi while running itzo from my laptop.  After the reconnect, all GCE operations timed out.  I'd like to see if we can detect these types of problems and get the client to reconnect in a timely manner.

Is this still an issue?

Yes


Add Stargate USDC LP Polygon

This PR adds the Stargate USDC LP on Polygon to the app. API is already implemented.
Vault: 0x255F928DB1295FE67f757597aA2c9263B2702c63
Strategy: 0x756b54c6d6046F19C8Ded66ECbF78A7d4fF8c2e3

Sushi has almost no liquidity.

Will fix and open a new PR.


Get rid of  most make targets & put everything in the eden dir

A compiled eden should be enough for EVE management.
I suggest that all artifacts are stored in eden folder in config instead of ~/.eden so rm -rf ./eden removes everything including the config. Also this way we don't mix eden installations and do not have any stale artifacts.
Also this way it's much easier to debug what happens&

Big +1 to this!

Outdated as an issue. Right now we are satisfied with the behavior


Change get to new because otherwise Request.get already returns a response.

A little documentation bug which makes the example not work.

Thank you!


Poor diagnostics for new projects when IronPython is not installed

All IronPython project templates preset it as a default Python environment for the project. But when it's not installed, you end up with something that just says "Unknown Python 2.7" under Environments, and when you run it you get an error message about said unknown environment being missing or not installed - there's not a word about IronPython there anywhere past the New Project dialog. This is in contrast with regular templates where you get no weird nodes in Solution Explorer, and guidance on where to download Python from if you try to run it. We should do something like that in this scenario, as well (and probably also for other missing Python versions if someone opens an existing project with an explicit environment reference).

:( Again. We have a specific help page for this, but it keeps getting lost in other error handling.


Loader function example from docs not working

Following the example here I encounter the following error:
julia> d = DTable(CSV.File, files)
ERROR: MethodError: no method matching DTable(::Type{CSV.File}, ::Vector{String})

Closest candidates are:
  DTable(::Any, ::Any, ::Any)
   @ DTables ~/.julia/packages/DTables/DZcii/src/table/dtable.jl:13
  DTable(::Function, ::Vector{String}; tabletype)
   @ DTables ~/.julia/packages/DTables/DZcii/src/table/dtable.jl:142
  DTable(::Vector{Union{Dagger.EagerThunk, Dagger.Chunk}}, ::Any, ::Union{Nothing, Tables.Schema})
   @ DTables ~/.julia/packages/DTables/DZcii/src/table/dtable.jl:13
  ...

Stacktrace:
 [1] top-level scope
   @ REPL[58]:1

I think the issue is that DTable expects a function. The following runs without issue:
julia> d = DTable(x->CSV.File(x), files)
DTable with 3 partitions
Tabletype: unknown (use `tabletype!(::DTable)`)

For reference, here is the status of my environment:
  [6e4b80f9] BenchmarkTools v1.3.2
  [336ed68f] CSV v0.10.11
  [13f3f980] CairoMakie v0.10.6
  [20c56dc6] DTables v0.3.1
⌅ [d58978e5] Dagger v0.16.3
  [a93c6f00] DataFrames v1.6.0

Yeah, we should change the signature to accept Base.Callable instead. Do you mind filing a PR with a short test (just do the same thing you show here)?

Happy to submit a PR! I hadn't come across Base.Callable before and found this thread after some googling. Is it better to just remove the type specification for loader_function in the definition?

Yeah that should be fine!

Great! I'll give this a go and will submit a PR later today.

@jpsamaroo submitted a PR with the update.


Fixes 3144: check for orphan repo versions

Summary
during snapshot, and if one is found use that to continue.
This helps the situation where some issue occurs and the pulp repo sync is successful, but the task dies, panics, or the publication creation fails.  If the repo hasn't changed at the next snapshot time, no new snapshot gets created.  With this change, the previously created repo version is re-used if there isn't a new one during the sync.
Testing steps
I couldn't figure out a way to simulate this, so instead we can manually clear the db.  On a fresh empty db:

create  a repo with snapshotting enabled.  Wait for it to finish snapshotting
within the database delete the snapshot:    make db-cli-connect

 delete * from snapshots;

trigger the snapshot manually:

POST http://localhost:8000/api/content-sources/v1.0/repositories/659bc4b3-b1a8-4d02-8d73-f36fe2b47d00/snapshot/

Check the db and notice a new snapshot was created, pointing to the old repo version (1)

# select version_href from snapshots;

                                        version_href
---------------------------------------------------------------------------------------------
 /pulp/399c928e/api/v3/repositories/rpm/rpm/018cd9dd-d4bf-7683-9610-8299e4eccfd6/versions/1/

Checklist

[x] Tested with snapshotting feature disabled and pulp server URL not configured if appropriate

https://issues.redhat.com/browse/HMS-3144

/retest


Add a way to read all enabled extensions across all extension hosts

vscode.extensions.all or vscode.extensions.getExtension will only return extensions from the current extension host. The root cause for this is that the return type IExtension<T> exposes the .exports property, which represents the extension's exported API. Since extensions can export synchronous APIs, we can't automatically proxy it to make it available to other extension hosts.
Also, making vscode.extensions.getExtension return an extension running on a different extension host, has the potential to cause breakage in existing extensions.
We could add a new function to be able to get to extensions that are running on other extension hosts.
This came up before e.g. in #82633
cc @jrieken

The main motivation for me is to get access to the manifests of all extensions across extension hosts to find contributions such as jsonValidation.
The same issue came up with the new anycode contributions and the htmlLanguage contribution were exploring in #146731.

The simple API change is another overload of the vscode.extensions.getExtension-function, like

export function getExtension(extensionId: string, includeAllExtensionHost: boolean): Extension<unknown> | undefined;

Also add another property for the Extension-type that allows to tell "same-ext-host" extensions apart from "foreign-ext-host" extension. Maybe a boolean like Extension.isDifferentThanThisExtensionHost or some kind of extension host identifier which you can compare with something like vscode.env.thisExtensionHostIdentifier
Last, a good way to iterate over really all extension descriptions. Something like vscode.extensions.allAll to complement the all property. Or we review existing usages to decide for the breaking semantic change...

@alexdima I noticed in the change above, exports will always be undefined for extensions in other hosts. Will there be any way for extensions in different extension hosts to communicate (for example can they call each others registered commands)?

Yes, extension across different extension host can use commands to communicate with each other. However, arguments and returned values must be primitive or JSON-able

@jrieken perfect, thanks!

Thanks for taking care of this issue!
We also need support for this feature for our SemanticDiff plugin to properly support Dev Containers. To implement syntax highlighting, we currently enumerate grammars and themes contributed via extensions. When running in a dev container, however, in particular the vscode.* builtin extensions are not available.
Everything works correctly when using the allAcrossExtensionHosts property instead of all, so looking forward to get this proposal accepted.

I'm interested in when support comes for extension communication via the exports. We ran into this limitation with codeflow

Perfect! When will this API be stable?

When will this API be stable?

This api has had the tag api-finalization since April 2022 - is there anything we can do to help with the finalisation of the API?
In terms of feedback for the API, we have been using it with a few of our extensions, and the API itself seems fine, but there are a few comments on documentation.
Here is what is currently in vscode.d.ts
	export namespace extensions {

		/**
		 * Get an extension by its full identifier in the form of: `publisher.name`.
		 *
		 * @param extensionId An extension identifier.
		 * @returns An extension or `undefined`.
		 */
		export function getExtension<T = any>(extensionId: string): Extension<T> | undefined;

		/**
		 * All extensions currently known to the system.
		 */
		export const all: readonly Extension<any>[];

		/**
		 * An event which fires when `extensions.all` changes. This can happen when extensions are
		 * installed, uninstalled, enabled or disabled.
		 */
		export const onDidChange: Event<void>;
	}

.getExtension() doesn't make any mention that an installed extension might not be returned if it is in a different extension host.
.all says: "All extensions currently known to the system.", which is incorrect, even with the proposed api, since (according to this FR) you need to call .allAcrossExtensionHosts, in order to get the extensions on other hosts.
The name .all is also not ideal, but I do understand why you can't change that for backwards compatibility. (Although in that case, allowing multiple extension hosts initially was probably a breaking change too?)
It is also not clear if .all will include extensions which do not run in an extension host, eg language extensions. My understanding is that it will, but I think the docstring for this should explicitly state exactly what .all includes.
The event onDidChange may be a bit ambiguous once this API is finalised, will it fire for changes in other hosts?

Summary: Even if we don't finalise the API, I think the docstrings currently in vscode.d.ts should be updated, as they don't make it clear what will be returned by the APIs.

Thanks for adding this into the next milestone. I thought we should just follow up with some more findings as we are using separate extension hosts a lot more now and have seem a few differnt examples.
This is all just from our experiences, and there are likely additional cases that we haven't come across.

.getExtension and .all not returning extensions from other hosts has caused us issues. In particular we often have extensions wanting to read the manifest of another extension. Or we have an extension wanting to generate a list of all installed extensions. In both these cases we had to modify them to use the proposed API.

If an extension does not want to use .exports, we have not managed to come across any scenario where it would be beneficial not to return extensions from other hosts.
Even in the event that an extension does want to use the exports of another extension, there would not be any significant regression by changing the default behaviour to return the extension regardless of host. The change would be to go from it not working because the extension is not found, to not working because it is found but doesn't export anything.
In both situations the fix is the same, ensuring both extensions live in the same host.

The risk is in making a non backwards compatible change to the API. Currently you can do the following to programatically handle the extension not existing or being in a different host if you need access to exports.
const extension = vscode.extensions.getExtension<Foo>('myExtension');
if (extension) {
  extension.exports.bar();
}

Whereas if getExtension were to return an extension from another host, that code above would error as the check would not verify that the extension returns anything.
(But then there never actually was any guarantee in the first place, since the extension author manually specifies the type anyway.)
The question is how often is extension A going to call extension B, knowing with certainty that it exports something and of what type, without A listing B as a dependency, which pins them into the same host as far as I understand?

I think whilst this is also true for .all - it is very unlikely that anyone will be trying to access the exports of an extension from .all, especially without checking that they exist, so I think it would be safe to update .all to return all extensions. I think onDidChange should reflect what .all is.
I also think that a breaking change to the API is unavoidable.
vscode.extensions.all previously returned all extensions installed on that instance of VS Code. And the docstring says otherwise. Having .all not return extensions in other hosts is already a breaking change to the API, and I would argue is a bigger break, than having it return extensions in other hosts which have exports = undefined.

I would also consider modifying the proposal for getExtension to overload based on whether other hosts are requested, for example:
export function getExtension<T = any>(extensionId: string, includeDifferentExtensionHosts?: false): Extension<T> | undefined;
export function getExtension<T = any>(extensionId: string, includeDifferentExtensionHosts: true): Extension<T|undefined> | undefined;
export function getExtension<T = any>(extensionId: string, includeDifferentExtensionHosts: boolean|undefined): Extension<T> | Extension<T|undefined> | undefined;

This way if you call, getExtension<Foo>('my.extension', /*allHosts*/ true); you would get a vscode.Extension<Foo|undefined> making it clear that exports may not exist. But if you call getExtension<Foo>('my.extension', /*allHosts*/ false); then that would return the more previous Extension<T>. (You could argue whether true or false should be default.)

tl;dr - there is a breaking change the API whatever you do, but I think with .all, having it do what it says it does currently is the smaller break. With .getExtension you could easily argue both ways but it is less important since the ability to add a parameter mitigates this mostly.

Better name suggestion from @Tyriar allOnAnyExtensionHost

With regards to all or allOnAnyExtensionHost - is there an example you can think of where, you might call all and not want it to include all extensions across all hosts?

you might call all and not want it to include all extensions across all hosts?

I don't know but we don't want to alter/break existing behaviour because there is a difference in what we return here. "Remote" extension don't have the API object set and today, with all, you never have that case


Return sub-categories when searching by taxonomy terms

I am not sure if this belongs here or at https://github.com/codeforamerica/ohana-api
I use the AIRS taxonomy for indexing services.  I can search by taxonomy terms by searching by 'category[]=Soup Kitchens' where a service has an exact match for the code.
What I need to do is be able to search the children of a term.  Below is an example branch of codes.
lv 1 Basic Needs
lv 2 - Food
lv 3 - - Summer Food Service Programs
lv 3  - - Soup Kitchens
lv 3  - - Low Cost Meals
lv 3  - - Home Delivered Meals
lv 3  - - Congregate Meals
.
.
.
In our database we code only to the lowest level of the taxonomy, but we can search higher.  For example I might index one service as offering "Congregate Meals" and another as "Soup Kitchens", but a search for lv 2 "Food" includes all of the lower-level lv 3 categories.
While I 'could' add each higher-level term above the lowest level to work with the current search, but some location records already show 60+ codes for the services offered at the location. I submit that it makes sense to search child categories by default.
I've only recently started teaching myself RoR, so I'm not sure where or how to add this feature.  Any advice?  I do want to thank you as well for the great documentation on these projects.
Thanks,
Cory

Hi Cory (@cderenburger). Thanks for using Ohana. This issue fits better in Ohana API, but we can discuss it here first to see where the problem lies. From your description of the problem, it sounds like you haven't set up your taxonomy properly. Ohana expects a taxonomy to be hierarchical, and when it's set up properly, the admin interface will automatically add parent categories when selecting a sub category. More details are available in our Taxonomy Basics Wiki article.
When the taxonomy is set up properly, it's impossible to tag a service with only a sub category. The parent categories all the way up the chain are automatically included. You can try it out in our demo admin interface.
To confirm my suspicion, could you please send a screenshot of your categories section in your admin interface with a sub category checkbox checked?

@cderenburger it would be great to hear about your plans for using Ohana, and I'd be glad to share a bit about the Open Referral initiative. I'm at<EMAIL_ADDRESS>- hope to hear from you...

Unfortunately I've not been able to access the admin area.  I'm using the virtual machine, everything but the admin area has worked.  It reports 'bad password' and I've tried running $ script/users to reset the users but no luck.  Since I'm just exporting I haven't worried about getting the admin interface up and running.
Back to the api, when I run
GET http://localhost:8080/api/categories/BD-5000/children
The api does list out the child categories associated with the code.

When the taxonomy is set up properly, it's impossible to tag a service with only a sub category. The parent categories all the way up the chain are automatically included.

So here the higher level codes are always included.  I should be able to export my data to include the higher level codes.  This should solve this issue.
Is there a place to ask questions rather than opening an issue?  I may need to ask for clarification on a few other things as I go along.
Thanks @monfresh
@greggish My intention is to just export from our database into Ohana to act as a public search website as our current providers public site is not very user friendly, and their api is limited.  I was hoping that Ohana would give me the flexibility I need to provide more specialized searching for various contracts that could potentially come our way.

@cderenburger that sounds great. Perhaps at some point in the coming weeks we could chat by phone or skype. I know of a couple of prospective stakeholders in King County who might be interested in supporting your work on this, and there may other ways that we can be helpful to you all.

@cderenburger If the documentation is not clear, feel free to open an issue. We don't really have another place for project-related questions, so GitHub is fine for now.
As for the admin interface, is it possible that you are trying to sign in on the wrong page? The API has two portals that look similar. The one at the root is the developer portal, and should say "Ohana API Developers" in the top left. The admin interface is at the /admin path and should say "Ohana API Admin" in the top left. You should be able to sign in with username<EMAIL_ADDRESS>and password ohanatest.

Adding the parent categories has fixed the category[]= issue.  Also thanks for pointing out that I needed to go to the /admin path, that is what I had been doing wrong.


build: bumping algokit utils, pyteal; removing algoexplorer as api pr…

Proposed changes

Bumping latest algokit utils v2 with dispenser support in order to be able to update algokit generators
Removing algoexplorer as api provide - no longer exist

Removing associated test

@robdmoore can't seem to assign you in pr review - if possible please self assign for review

This looks good, but given it removes algoexplorer and does a major bump on utils it should probably at least bump minor version (not sure a build tag will do that)? I don't have permissions on this repo so can't merge it.


Remove CERTIFICATES

As of https://github.com/hyperium/tonic/pull/660, it is convenient to simply enable the tonic tls-webpki-roots crate feature.
With that feature enabled, one can omit tls_config() on the Channel and everything JustWorks:tm:

@shikhar Thank you for your suggestions.
It cannot be deleted right now. That's because the user must explicitly enable the tls-webpki-roots feature.
(Some people don't want to rely on webpki-roots crate.)
So I would like to consider how to use feature gate for this crate as well. This method allows the user to decide which to use.
How about that?

Not a big deal, users can just choose to not use the export. But I wonder in what situation a user would be ok with the certs exported by this crate but not webpki-roots.


Fix polymorphic type setter

Hey @lgebhardt!
We encounter a problem associated with the polymorphic relation. Here is an example in code:
Setup
Models:
class Conversation < ActiveRecord::Base
  has_many :topics
end

class Account::Template < ActiveRecord::Base
  has_many :topics
end

class Topic < ActiveRecord::Base
  belongs_to :document, polymorphic: true
end

Resources:
class Template < JSONAPI::Resource
  model_name 'Account::Template'
  has_many :topics
end

class Topic < JSONAPI::Resource
  has_one :document, polymorphic: true
end

Usage
Request: [ POST ] /topics
{
    "data": {
        "attributes": {
            "name": "Topic name",
        },
        "relationships": {
            "document": {
                "data": {
                    "type": "templates",
                    "id": "1"
                }
            },
        },
        "type": "topics"
    }
}

Problem
Newly created topic has the wrong name of document_type filed.
After typing topic.document_type it was Templates but in fact, the polymorphic type should be taken from a model name and it should look like Account::Template because it's the real name of the resource's model's class name.
Solution
I overwrite a method which assigns polymorphic type, and I created a method which looking for a real model class name of given relation's key_type.
I hope it will help :)

Nice catch. Can you add a test that fails without this fix and passes with it?

@barelyknown I added a test. I'm not familiar with the rails test framework (I used to use rspec) so feedback is welcome.

Nice and simple - thanks!


Clarify Tim and Oliver's job title

Remove brackets and add forward slash for consistency with other team documentation.

We're going to close this as we were just running through how to update the members.

You can preview this change here:
Built with commit f814201b81b152b41ac8ca734b2b169fde46393e
https://deploy-preview-1096--govuk-design-system-preview.netlify.com


[BUG] Networking HAVE_PFINET_SOCKETS always undefined

Description / Steps to reproduce the issue
Defconfig sim:userfs
nsh> userfs
ERROR: userfs_run() returned: -97

Address family not supported by protocol error from net_sockif of net_sockif.c due to HAVE_PFINET_SOCKETS being wrongly undefined. The necessary NET_UDP_HAVE_STACK and NET_TCP_HAVE_STACK are not being included by netconfig.h. NET_UDP_HAVE_STACK and NET_TCP_HAVE_STACK are defined in nuttx/net/udp/udp.h and nuttx/net/tcp/tcp.h.
A chain of partial fixes to very similar issues ended with this PR #14650
On which OS does this issue occur?
[OS: Linux]
What is the version of your OS?
Ubuntu 20.04
NuttX Version
master
Issue Architecture
[Arch: x86_64]
Issue Area
[Area: Networking]
Verification

[X] I have verified before submitting the report.

@PetervdPerk-NXP could you look at this issue?

Hi @liamHowatt , we've also encountered this bug and tried to post a fix, would you like to have a try? https://github.com/apache/nuttx/pull/14886

Thanks for addressing it @wengzhe :pray: I will take a look in ~20 hours and reply in your PR.

Glad to see it was merged. Working again in master. Thank you. The solution makes sense to me.


Add custom headers for AJAX request

Is there a way to add headers to the ajax requests? Previously the default JQuery settings appended them, but when I switch to this package they are not appended to the request.

It might be using a different instance of jQuery? Try DataTables.use(jQuery) (or whatever your local jQuery is). Or do:
ajax: {
  url: ...,
  headers: {
   ...
  }
}

in your DataTable initialisation.

Perfect, exactly what I needed. Thank you!


Kubernetes dark theme color issues

Version - master 3/4

[ ] Can't see Namespaces in the select drop-down

[ ] Can't see selected environment

[ ] Menu items are hard to see

[ ] Service, RCS, and PODs individual pop-up menus hard to see.  A little bit too opaque and the white text against the light blue is hard to see.

resolved in https://github.com/rancher/ui/pull/507

Version - master 3/4
Verified fixed


KAFKA-6263: Expose metrics for group and transaction metadata loading duration

JIRA

Add metrics to provide visibility for how long group metadata and transaction metadata take to load in order to understand some inactivity seen in the consumer groups
Tests include mocking load times by creating a delay after each are loaded and ensuring the measured JMX metric is as it should be

Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Can you also update the metrics documentation with these new metrics? They are at https://github.com/apache/kafka/blob/trunk/docs/ops.html

retest this please

ok, passed enough. Merging. Thank you for contributing, Anastasia!


normalization: spotify no longer uses a limiter by default, so librespot probably shouldn't either

The default normalization method in librespot is "dynamic". However, spotify has made some changes to conform to the commonly used standards that other services uses, so they no longer uses a limiter for the default setting "normal" in spotify, so I think librespot shouldn't either. I don't know which LUFS level that librespot targets by default, but the default should now be -14 dB LUFS with no limiting.
https://artists.spotify.com/en/help/article/loudness-normalization
https://www.youtube.com/watch?v=449C4NSVPzw

I am not a mastering engineer but I believe that this documentation by Spotify mixes up LUFS and dBFS.
When Spotify receives new music they calculate ReplayGain values targeting -14 LUFS, this is their baseline. These values are stored in a custom Ogg packet and we in fact retrieve those.
Then during playback (the normalization settings) Spotify does not recompute LUFS. It can only work in dB (FS). When choosing “Normal” levels they take the RG values as in the Ogg packet.
For “Loud” or “Quiet” it is just a matter of applying gain: +3/-9 according to that documentation. This is where the Spotify documentation gets it wrong. You cannot adjust sample values by X and expect the LUFS to change by the same X.
Adding to this I fact the documentation is outdated, as upon logon we receive configuration metadata which hints that the amount of gain is no longer as per the docs, and neither is the threshold.
All of this is currently in librespot, including those attack and release times.
Again I am not a mastering engineer, so if I’m wrong then do tell what we should change specifically and how.

Basically, as far as I can see from the source code, it seems like "Basic" is now more inline with the spotify defaults, not "dynamic".
However, as I don't really know the details of the source code a good implementation for fidelity adjust gains by the RG metadata, but if it is a very dynamic track that can't be increased by the amount in the RG tags without clipping, takes into concideration the max peak to ensure the maximum level of the track never clips. For very dynamic tracks this means that the volume target will not reach the target LUFS level, but the fidelity is fully preserved. This is, as far as I know, now the default behaviour for quiet and normal in official spotify clients. This is also how all good service implements it.
I am not saying that librespot does not do this correctly in the "dynamic" case, but what I'm saying is that there is no need for a limiter at all as the default, as long as you take into concideration the max peak tags which I assume exists also for spotify streamed content.
Previously in the default spotify "normal" case, spotify woult forcefully increase the track to the target level by limiting the peaks so the track could be increased by the amount indicated in the RG gain tag. This compromises fidelity and is no longer used. As far as I know spotify was the only streaming service that used limiting to force dynamic tracks up to the target levels so this change was very needed for the default setting.

If this were the case with Spotify then why specify attack, release and thresholds at all? Such parameters only make sense for a limiter.
From the docs I do not read that the official clients now work like the basic limiter. I didn’t want to watch the full 40 minutes of the YT video you posted but any particular things I should watch?
Last time we worked on the limiter was not so long ago, and we did some extensive auditioning against the Spotify client then to ensure the sound was alike. Especially on classical tracks with huge dynamic range this would have been very noticeable — for basic normalization the tracks would then be extremely quiet and they were not. When do you say this would have changed?

The limiter is still used for the "High" normalization target, so the parameters are still needed for some users. However, it could also be that Spotify is always running the limiter, but in contrast to other services that only uses the RG tags to decide on a volume target, spotify adapts the limiter parameters to make the limiter ineffective for the "normal" and "quiet" targets instead of entirely bypassing it. It seems convoluted when coming from other implementations, but makes some sense as the limiter is still in use for some users.
However, doing a null operation via the limiter makes me somewhat uncomfortable as an audio enthusiast and I personally would feel better if the audio never touched the "magic" limiter at all if the end result is supposed to be the same :)
The changes was implemented in the first half of 2021 I think, so if you say that the current implementations has been tested against very dynamic tracks and the dynamics have been preserved in it's entirety without clipping or limiting, the current implementation is probably correct.
Also my official spotify client now has been updated with the following description: "Volume level - Adjust the volume for your environment. Loud may diminish audio quality. No effect on audio quality in Normal or Quiet".
I do not know the spotify internals, so this issue was mainly targeting the need to have a limiter on by default when it is not supposed to do any limiting except in the "high" case.

I verified now. Everything good! Sorry for wasting your time! I was thrown off because I had volume differences between the official spotify client and librespot, when there should be none and then I saw that the limiter was on by default.
After you confirmed that it should work as the original spotify client even in dynamic mode I started looking at other culprits and found that a technicality related to the volume control implementation when librespot was in use on my streaming platform (ropieee xl) was the cause.

That’s fine. Good to have it somewhat independently verified now 😄


feat(ivc): impl FoldRelaxedPlonkInstanceChip::generate_challenge

Part of #32

@chaosma Could you give a bit of a squeeze on what exactly to prove instead of u_fold (which is u+r). Do I need to add r_val to each challenge or do I need to fold all of them together?

WIP: I will take into scope of this module development challenges folding & lookup folding

Will be part of #61


add missing fields to Deal, Source and User model

add missing fields to models:
Deal:

last_stage_change_at
last_stage_change_by_id
last_activity_at
estimated_close_date

Source:

resource_type

User:

deleted_at

@ppietr could you please add new fields here to have some minimal level of confidence: https://github.com/basecrm/basecrm-java/blob/master/src/test/groovy/com/getbase/services/BaseSpecification.groovy#L81


Add configuration for CORS allowed headers

This PR enhances the CORS middleware usage by allowing for the headers to be configured in app.ini.
Fixes #21746

Details

restarted

make L-G-T-M work


feat: Update Contributors.md

Added Github profile and updated list of maintainers

Related Issue
Closes: #issue_number

Description
The contributors.md file is updated and github profile is added to the contributor's' list
Screenshots

Checklist

[x] My code adheres to the established style guidelines of the project.
[x] I have included comments in areas that may be difficult to understand.
[x] My changes have not introduced any new warnings.
[x] I have conducted a self-review of my code.

@akshitagupta15june please review the pr and add relevant labels.
This contribution is under Hacktoberfest


fix(ui-bc): use matrixindex timesteps for row display

Don't know if the code is good but from an user perspective it works well :)


[SPARK-16542][SQL][PYSPARK] Fix bugs about types that result an array of null when creating DataFrame using python

What changes were proposed in this pull request?
This is the reopen of https://github.com/apache/spark/pull/14198, with merge conflicts resolved.
@ueshin Could you please take a look at my code?
Fix bugs about types that result an array of null when creating DataFrame using python.
Python's array.array have richer type than python itself, e.g. we can have array('f',[1,2,3]) and array('d',[1,2,3]). Codes in spark-sql and pyspark didn't take this into consideration which might cause a problem that you get an array of null values when you have array('f') in your rows.
A simple code to reproduce this bug is:
from pyspark import SparkContext
from pyspark.sql import SQLContext,Row,DataFrame
from array import array

sc = SparkContext()
sqlContext = SQLContext(sc)

row1 = Row(floatarray=array('f',[1,2,3]), doublearray=array('d',[1,2,3]))
rows = sc.parallelize([ row1 ])
df = sqlContext.createDataFrame(rows)
df.show()

which have output
+---------------+------------------+
|    doublearray|        floatarray|
+---------------+------------------+
|[1.0, 2.0, 3.0]|[null, null, null]|
+---------------+------------------+

How was this patch tested?
New test case added

Can one of the admins verify this patch?

ok to test

Test build #78775 has started for PR 18444 at commit 58b120c.

Test build #78775 has finished for PR 18444 at commit 58b120c.

This patch fails PySpark 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/78775/
Test FAILed.

While I am here, I just ran some tests as below:
from array import array

from pyspark.sql import Row

spark.createDataFrame([Row(floatarray=array('f',[1, 2, 3]))]).show()
spark.createDataFrame([Row(unicodearray=array('u',[u"a", u"b"]))]).show()

Before
>>> spark.createDataFrame([Row(floatarray=array('f',[1,2,3]))]).show()

+------------------+
|        floatarray|
+------------------+
|[null, null, null]|
+------------------+

>>> spark.createDataFrame([Row(unicodearray=array('u',[u"a", u"b"]))]).show()

+------------+
|unicodearray|
+------------+
|      [a, b]|
+------------+

After
>>> spark.createDataFrame([Row(floatarray=array('f',[1, 2, 3]))]).show()

+------------------+
|        floatarray|
+------------------+
|[null, null, null]|
+------------------+

It looks still filling null (but the type looks being float from double).
>>> spark.createDataFrame([Row(unicodearray=array('u',[u"a", u"b"]))]).show()

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File ".../spark/python/pyspark/sql/session.py", line 537, in createDataFrame
    rdd, schema = self._createFromLocal(map(prepare, data), schema)
  File ".../spark/python/pyspark/sql/session.py", line 401, in _createFromLocal
    struct = self._inferSchemaFromList(data)
  File "...spark/python/pyspark/sql/session.py", line 333, in _inferSchemaFromList
    schema = reduce(_merge_type, map(_infer_schema, data))
  File ".../spark/python/pyspark/sql/types.py", line 1009, in _infer_schema
    fields = [StructField(k, _infer_type(v), True) for k, v in items]
  File ".../spark/python/pyspark/sql/types.py", line 981, in _infer_type
    raise TypeError("not supported type: array(%s)" % obj.typecode)
TypeError: not supported type: array(u)

I think we should not drop this support. I guess the same thing would happen to c too.

@HyukjinKwon Thanks for figuring that out. I will fix those issues.

Test build #78802 has started for PR 18444 at commit b91dd55.

Test build #78802 has finished for PR 18444 at commit b91dd55.

This patch fails PySpark 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/78802/
Test FAILed.

@HyukjinKwon It is strange that the float array does not work and pyspark unit tests fails. This patch was created more than a year ago and and it worked well at that time. Maybe some changes in spark's internal things break this patch. I didn't follow spark's internal changes so I have no idea on how to fix this right now. Please allow me some time to figure things out and if you have an idea on what is the problem, please let me know.

Btw, seems like array module in Python 2 doesn't have array.typecodes attribute.
Traceback (most recent call last):
  File<EMAIL_ADDRESS>line 2266, in test_array_types
    unsupported_types = set(array.typecodes) - int_types - float_types
AttributeError: 'module' object has no attribute 'typecodes'

In my local environment, this patch for floatarray looks working well:
df = spark.createDataFrame([Row(floatarray=array('f',[1,2,3]), doublearray=array('d',[1,2,3]))])
df.printSchema()
df.show()

root
 |-- doublearray: array (nullable = true)
 |    |-- element: double (containsNull = true)
 |-- floatarray: array (nullable = true)
 |    |-- element: float (containsNull = true)

+---------------+---------------+
|    doublearray|     floatarray|
+---------------+---------------+
|[1.0, 2.0, 3.0]|[1.0, 2.0, 3.0]|
+---------------+---------------+

@HyukjinKwon Could you check this again please?
I guess we need to compile EvaluatePython.scala file.

Ahhh.. there was a Scala change here. I checked this again and you are right @ueshin. I will read and make a clean build carefully next time ... I also updated https://github.com/apache/spark/pull/18444#issuecomment-311603019.

@zasdfgbnm, I am sorry for a false alarm.

Test build #79006 has started for PR 18444 at commit bd8e111.

Test build #79006 has finished for PR 18444 at commit bd8e111.

This patch fails Python style 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/79006/
Test FAILed.

Test build #79008 has started for PR 18444 at commit 930d16b.

Test build #79010 has started for PR 18444 at commit 1b1c419.

Test build #79010 has finished for PR 18444 at commit 1b1c419.

This patch fails Python style 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/79010/
Test FAILed.

Test build #79008 has finished for PR 18444 at commit 930d16b.

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

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

Merged build finished. Test FAILed.

Test build #79022 has started for PR 18444 at commit c4b09f5.

Test build #79022 has finished for PR 18444 at commit c4b09f5.

This patch fails Python style 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/79022/
Test FAILed.

Test build #79024 has started for PR 18444 at commit 1a6b243.

Test build #79024 has finished for PR 18444 at commit 1a6b243.

This patch fails Python style 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/79024/
Test FAILed.

Test build #79025 has started for PR 18444 at commit e9f02b0.

Test build #79025 has finished for PR 18444 at commit e9f02b0.

This patch fails Python style 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/79025/
Test FAILed.

Test build #79026 has started for PR 18444 at commit fe035a6.

Test build #79027 has started for PR 18444 at commit 7b05669.

Test build #79028 has started for PR 18444 at commit cca2d6a.

Test build #79027 has finished for PR 18444 at commit 7b05669.

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/79027/
Test FAILed.

Test build #79028 has finished for PR 18444 at commit cca2d6a.

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/79028/
Test FAILed.

Test build #79026 has finished for PR 18444 at commit fe035a6.

This patch fails Spark unit tests.
This patch does not merge cleanly.
This patch adds no public classes.

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/79026/
Test FAILed.

@ueshin @HyukjinKwon I think I'm done now. There are still fails in tests, but it doesn't looks to be something related to my change....

@zasdfgbnm if the failures are unrelated you can ask jenkins to re-run the tests with "jenkins retest this please".
One thing is even though github reports this merges jenkins report it has conflicts, so to be safe I'd update to the latest master.

jenkins retest this please

Jenkins, retest this please

retest this please

I'm not sure if Jenkins would listen to me :(

I think you could push an empty commit to retrigger the Jenkins build as a workaround, for example,  git commit --allow-empty -m "Retrigger the build" if the test blocks what you are working on. I can't trigger the build too.

Test build #79045 has started for PR 18444 at commit 37e28a4.

Test build #79045 has finished for PR 18444 at commit 37e28a4.

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/79045/
Test FAILed.

Jenkins, retest this please.

Test build #79059 has started for PR 18444 at commit 37e28a4.

Test build #79059 has finished for PR 18444 at commit 37e28a4.

This patch fails PySpark 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/79059/
Test FAILed.

test fails due to a § in comment...

I guess you can define source code encoding to the top of the file like:
# -*- coding: utf-8 -*-

Or, we could just remove that character ...

Test build #79218 has started for PR 18444 at commit 9bcf2e1.

Test build #79220 has started for PR 18444 at commit 4af97af.

Test build #79220 has finished for PR 18444 at commit 4af97af.

This patch fails Python style 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/79220/
Test FAILed.

Test build #79221 has started for PR 18444 at commit aaf66f1.

Test build #79222 has started for PR 18444 at commit 385ab1f.

Test build #79218 has finished for PR 18444 at commit 9bcf2e1.

This patch fails PySpark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class AlterFunctionPreEvent(database: String, name: String) extends FunctionEvent
case class AlterFunctionEvent(database: String, name: String) extends FunctionEvent

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/79218/
Test FAILed.

Test build #79221 has finished for PR 18444 at commit aaf66f1.

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/79221/
Test FAILed.

Test build #79222 has finished for PR 18444 at commit 385ab1f.

This patch fails PySpark 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/79222/
Test FAILed.

Test build #79237 has started for PR 18444 at commit 8352dab.

Test build #79237 has finished for PR 18444 at commit 8352dab.

This patch fails PySpark 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/79237/
Test FAILed.

Test build #79242 has started for PR 18444 at commit 9612f77.

it is strange...
The test pass at python3, but at python2 with typecode l,<PHONE_NUMBER>854775807 becomes -1 after creating DataFrame and

Test build #79242 has finished for PR 18444 at commit 9612f77.

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

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

Merged build finished. Test FAILed.

There seems to be another bug in spark on somewhere:
rdd = sc.parallelize([array('l',[9223372036854775807])])
print(rdd._to_java_object_rdd().collect()[0][0])

The above code gives -1 on python2

Maybe the bug is in py4j

Hmm, seems like net.razorvine.pickle.objects.ArrayConstructor handles 'l' as int instead of long in Python 2.
https://github.com/irmen/Pyrolite/blob/master/java/src/main/java/net/razorvine/pickle/objects/ArrayConstructor.java#L73

I believe #18553 will fix the problem.

Test build #79286 has started for PR 18444 at commit f2774c6.

Test build #79286 has finished for PR 18444 at commit f2774c6.

This patch fails PySpark 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/79286/
Test FAILed.

Jenkins, retest this please.

Test build #79314 has started for PR 18444 at commit f2774c6.

LGTM, pending Jenkins.
@HyukjinKwon, @holdenk, Do you have any other concerns?

Thanks for asking @ueshin. Sounds OK to me too. I currently have some pending review comments for minor nits. Let me finish mine within today.

Test build #79314 has finished for PR 18444 at commit f2774c6.

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/79314/
Test FAILed.

Jenkins, retest this please.

Test build #79324 has started for PR 18444 at commit f2774c6.

Test build #79324 has finished for PR 18444 at commit f2774c6.

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

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

Merged build finished. Test FAILed.

Test build #79345 has started for PR 18444 at commit 5ebc33f.

Test build #79345 has finished for PR 18444 at commit 5ebc33f.

This patch fails PySpark 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/79345/
Test FAILed.

net.razorvine.pickle.PickleException: for c/u type must be 18/19/20/21
	at net.razorvine.pickle.objects.ArrayConstructor.construct(ArrayConstructor.java:154)
	at org.apache.spark.api.python.SerDeUtil$ArrayConstructor.construct(SerDeUtil.scala:75)
	at net.razorvine.pickle.Unpickler.load_reduce(Unpickler.java:707)
	at net.razorvine.pickle.Unpickler.dispatch(Unpickler.java:175)
	at net.razorvine.pickle.Unpickler.load(Unpickler.java:99)
	at net.razorvine.pickle.Unpickler.loads(Unpickler.java:112)
	at org.apache.spark.api.python.SerDeUtil$$anonfun$pythonToJava$1$$anonfun$apply$1.apply(SerDeUtil.scala:162)

strange

@zasdfgbnm Hmm, I agree that this is a bug of ArrayConstructor.
I guess we should use 'c' -> 19 for line 60 and 'c' -> 18 for line 64.

Test build #79466 has started for PR 18444 at commit af9a411.

Test build #79466 has finished for PR 18444 at commit af9a411.

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

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

Merged build finished. Test FAILed.

Test build #79539 has started for PR 18444 at commit 5e3128c.

Test build #79540 has started for PR 18444 at commit 9ee439f.

For some reason, I can not reproduce the error on my machine. I run the test using the following command:
PYSPARK_PYTHON=$(which python2) ./bin/spark-submit python/pyspark/sql/tests.py SQLTests.test_array_types 2>/dev/null

and I always get a pass...
So I have to commit and push to let Jenkins run the test to see if it will pass...

Test build #79539 has finished for PR 18444 at commit 5e3128c.

This patch fails PySpark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
class ArrowSerializer(FramedSerializer):
class AstBuilder(conf: SQLConf) extends SqlBaseBaseVisitor[AnyRef] with Logging
class CatalystSqlParser(conf: SQLConf) extends AbstractSqlParser
class SparkSqlParser(conf: SQLConf) extends AbstractSqlParser
class SparkSqlAstBuilder(conf: SQLConf) extends AstBuilder(conf)
class VariableSubstitution(conf: SQLConf)

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/79539/
Test FAILed.

Test build #79544 has started for PR 18444 at commit 38a8bef.

Test build #79540 has finished for PR 18444 at commit 9ee439f.

This patch fails PySpark 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/79540/
Test FAILed.

Test build #79544 has finished for PR 18444 at commit 38a8bef.

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

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

Merged build finished. Test FAILed.

Test build #79547 has started for PR 18444 at commit 9ee439f.

Test build #79547 has finished for PR 18444 at commit 9ee439f.

This patch fails PySpark 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/79547/
Test FAILed.

Test build #79586 has started for PR 18444 at commit 7522aff.

Test build #79586 has finished for PR 18444 at commit 7522aff.

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/79586/
Test PASSed.

Finally, all tests pass...
I'm happy that my test case helps find two more bugs and thank @ueshin for fixing these two bugs :)

@HyukjinKwon, @holdenk, Could you double-check the way to handle an array of typecode 'c' please?
I'm not exactly sure this can cover all cases.

I will help double check within coming three or four days (for me it takes a quite while to debug and double check this case ...)

BTW, I wouldn't mind if we go merge this meanwhile. I trust @ueshin's judgement.

BTW, I guess it'd be nicer if we get a sign-off from @davies if you have some bandwidth to deal with this meanwhile.

Test build #79613 has started for PR 18444 at commit e0cced0.

Test build #79613 has finished for PR 18444 at commit e0cced0.

This patch fails Python style tests.
This patch merges cleanly.
This patch adds no public classes.

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

Merged build finished. Test FAILed.

Test build #79615 has started for PR 18444 at commit 788b0da.

Test build #79616 has started for PR 18444 at commit a87bc9e.

Test build #79618 has started for PR 18444 at commit 6c49a48.

Test build #79615 has finished for PR 18444 at commit 788b0da.

This patch fails SparkR 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/79615/
Test FAILed.

Test build #79616 has finished for PR 18444 at commit a87bc9e.

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/79616/
Test PASSed.

Test build #79618 has finished for PR 18444 at commit 6c49a48.

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/79618/
Test PASSed.

I updated my code according to @HyukjinKwon's suggestion

@HyukjinKwon all done

Test build #79705 has started for PR 18444 at commit cafa5fd.

Test build #79705 has finished for PR 18444 at commit cafa5fd.

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/79705/
Test PASSed.

By the way, I'm traveling tomorrow and will be back next Tuesday. During traveling, I may not be able to answer any comments, questions, etc.

Sure, take your time @zasdfgbnm. Thanks for your quick response.

LGTM.

@HyukjinKwon Take a look at my newest commit. I think I find a better way to solve the problem that keeps all the hacking code for  SPARK-21465 in a single place, making it easier to be removed in the future. What do you think?

Test build #79736 has started for PR 18444 at commit 88091ea.

Okay. LGTM.

LGTM, too. pending Jenkins.

Test build #79736 has finished for PR 18444 at commit 88091ea.

This patch fails PySpark 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/79736/
Test FAILed.

Looks to be an unrelated error.
Sent from my OnePlus ONEPLUS A3000 using FastHub

Sounds actually related:

======================================================================
ERROR: test_array_types (pyspark.sql.tests.SQLTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/jenkins/workspace/SparkPullRequestBuilder/python/pyspark/sql/tests.py", line 2402, in test_array_types
    assertCollectSuccess(t, 2 ** (ctypes.sizeof(ctype) * 8) - 1)
  File "/home/jenkins/workspace/SparkPullRequestBuilder/python/pyspark/sql/tests.py", line 2352, in assertCollectSuccess
    self.assertEqual(df.first()["myarray"][0], value)
  File "/home/jenkins/workspace/SparkPullRequestBuilder/python/pyspark/sql/dataframe.py", line 994, in first
...

Py4JJavaError: An error occurred while calling o1194.collectToPython.
: org.apache.spark.SparkException: Job aborted due to stage failure: Task 2 in stage 101.0 failed 1
 times, most recent failure: Lost task 2.0 in stage 101.0 (TID 429, localhost, executor driver):
net.razorvine.pickle.PickleException: unsupported datatype: 64-bits unsigned long
	at net.razorvine.pickle.objects.ArrayConstructor.constructLongArrayFromUInt64(ArrayConstructor.java:302)
...

Yea, it's related to typecode 'L' in pypy environment.
We might need to handle it as the same as we did for typecode 'c' or override constructLongArrayFromUInt64().

Btw, now I'm wondering Python 3 can handle array like array('L', [9223372036854775807]).

I just tested this with Python 3.6 to help:
from pyspark.sql import Row
import array

row = Row(myarray=array.array('L', [9223372036854775807]))
df = spark.createDataFrame([row])
df.show()

Master:
...
net.razorvine.pickle.PickleException: unsupported datatype: 64-bits unsigned long
...

After this PR:
...
TypeError: not supported type: array(L)
...

He tested other cases as well - https://github.com/apache/spark/pull/18444/files#r128131853.

@HyukjinKwon Oh, I was missing his test for 'L'. Thanks for testing!

Hmm, how was 'L' supported in master python 2? Why there was no such an error there?
Sent from my OnePlus ONEPLUS A3000 using FastHub

@ueshin Maybe we don't have to do the same thing. If this is the problem, then I think in pypy environment, 'L' was originally unsupported and there is no need to support it now.

Test build #79758 has finished for PR 18444 at commit cdc7257.

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/79758/
Test PASSed.

Test build #79774 has started for PR 18444 at commit a340745.

fixed

Test build #79774 has finished for PR 18444 at commit a340745.

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/79774/
Test PASSed.

Thanks! merging to master.


Mobile activation

As an iOs user how am I able to use mobile notifications? Are there any guides how to enable it?

I'm not quite sure how that whole thing works either.
If you launch with the "Server mode" checked at the bottom, then why go to mobile and enable?
.... since you're already in server mode.
And whats that barcode scan for?
And whats the URL for?
And why on OS X does another window popup when I click the URL, but it doesn't update?


Textures don't work when initialised with pixel manipulation support

There's currently a crash when attempting to use memcpy() in Texture.cpp (used for pixel manipulation) -  for the timebeing I have simply disabled pixel manipulation in that method.

This works now. Think the problem was due to freeing (or not freeing) the temporary SDL_Surface in the wrong place or something, fixed a while back


is gitter channel the right place to direct people to for discussion?

the last post to gitter channel is from 2017.  Most of the content referenced in these guidelines seems to originate with Rust RFCs which references

official Discord server
developer discussion forum

Having recently discovered this repo, and as a relative newcomer to Rust, it would be nice to be directed to a specific channel on Discord, where it seems there are a lot of other and possibly related active Rust conversations.  Though if I've misunderstood, just close this and I'll hop on gitter next time I drop by :)

Hi @ultrasaurus :wave:
Welcome to the community! We've been a bit quiet on this repo for a while, but are starting to try revive some discussion. We've enabled GitHub Discussions here, which is now the right place to go to talk about API guidelines 🙂


test: fix

add pytest.mark.enable_console

I see this one remaining test fail a lot too.  Usually if I rerun it it goes away (will try now), but any idea what's going on there?

Just curious, were you able to figure out where/when this marker got added in napari?

Just curious, were you able to figure out where/when this marker got added in napari?

Nope, not sure what changed in napari's last week release that affected this behavior (for sure not the make_napari_viewer method though, it has not been recently modified)...

for my tastes, this fix is to specific to something that napari is internally doing in their tests, and may well break again in the future.  I just think we shouldn't be using make_napari_viewer... will update

pushed a change that stops using make_napari_viewer


Load Testing Prep

Explore what we need to be ready for the upcoming load testing.
Kitchen sink form, test idirs, etc.

focus on test legacy forms
Load testing - ways to test scenarios on live forms
set up load testing
Identify all things we can do top prepare
make separate ticket on action item coming out of this exploration

Moving to waiting until we have a budget to 'right size' pods


Trait annotations saved on the IntegrationKit resource

What happened?
The IntegrationKit resource seems to save the trait annotations that have been used to build the kit. Some trait annotation configs do not influence the kit and get saved, too. This is a problem because subsequent integrations that resolve to that IntegrationKit inherit the trait annotation config and this influences the integration runtime.
As an example you can use trait.camel.apache.org/knative-service.enabled: 'false' annotation. When the integration that triggers the kit build uses this annotation it gets saved to the IntegrationKit resource:
apiVersion: camel.apache.org/v1
kind: IntegrationKit
metadata:
  annotations:
    camel.apache.org/operator.id: camel-k
    trait.camel.apache.org/knative-service.enabled: 'false'

This is a problem because every integration that uses this IntegrationKit will also inherit the annotation trait config leading to the Knative service trait being disabled for the all integrations that use the kit.
Steps to reproduce

Start an integration that uses trait.camel.apache.org/knative-service.enabled: 'false'
Make sure that the IntegrationKit is build for this integration and see the Knative service condition being disabled explicitly

status:
  conditions:
    - lastTransitionTime: '2024-06-11T15:59:40Z'
      lastUpdateTime: '2024-06-11T15:59:40Z'
      message: explicitly disabled
      reason: KnativeServiceNotAvailable
      status: 'False'
      type: KnativeServiceKnativeServiceAvailable

Start an integration that matches the previously built kit but does not use the trait annotation at all
See the Knative service trait also being disabled for this 2nd integration because it is explicitly disabled by trait config inherited from the integration kit
We would expect the Knative service being enabled for the 2nd integration because this is the default behavior when Knative serving is available on the cluster

Relevant log output
No response
Camel K version
2.3.3

Yeah, that's a bad side effect of using trait into annotations. Probably those annotations should be completely filtered out. If you notice, the IntegrationKit, by design has only a subset of traits:
https://github.com/apache/camel-k/blob/489f42ede99ccd91b64bb9efdc28e9593d3770f0/pkg/apis/camel/v1/integrationkit_types.go#L82 and they are populated in the Quarkus trait when creating a new IntegrationKit.

I'm working on the fix, and I've realized the usage of traits in annotations can be simplified a lot in general. However, I am wondering if for Integrations, IntegrationKits and IntegrationPlatforms it does make sense to have the possibility to use also annotations to provide such a configuration. I think it's fine in Pipes, but cannot figure it out the use case for Integrations (ie, if the user can create an annotation, it should be able to edit easily the Integration spec as well).
@lburgazzoli I see this was introduced to support Pipes (well, KameletBindings [1]) but was moved automatically to the others custom resources. I'd be inclined to deprecate, unless there is any valid reason to keep it.
[1] https://github.com/apache/camel-k/pull/2338

I'm working on the fix, and I've realized the usage of traits in annotations can be simplified a lot in general. However, I am wondering if for Integrations, IntegrationKits and IntegrationPlatforms it does make sense to have the possibility to use also annotations to provide such a configuration. I think it's fine in Pipes, but cannot figure it out the use case for Integrations (ie, if the user can create an annotation, it should be able to edit easily the Integration spec as well).
@lburgazzoli I see this was introduced to support Pipes (well, KameletBindings [1]) but was moved automatically to the others custom resources. I'd be inclined to deprecate, unless there is any valid reason to keep it.

No, I don't think there is any more reason to use traits as annotations on  resources other than Pipes


Inability to drag and drop blocks into and out of conditionals.

Describe the Bug with repro steps

Setup a conditional action.
Add a compose action outside of the conditional.
Drag and drop the compose action into the conditional.

What type of Logic App Is this happening in?
Consumption (Portal)
Are you using new designer or old designer
New Designer
Did you refer to the TSG before filing this issue? https://aka.ms/lauxtsg
Yes
Workflow JSON
No response
Screenshots or Videos
https://github.com/Azure/LogicAppsUX/assets/3086302/63e281b3-9f15-411d-a73f-31d1004b059a
Browser
Edge
Additional context
No response
AB#24546552

@jaimereyesmx  or @ek68794998
We fixed this to work fine in Logic Apps, any idea why it wouldn't be working yet in PA?
https://github.com/Azure/LogicAppsUX/assets/13208452/4d58f350-331f-445a-855a-aa6072a9fd87

Is there any dynamic content within the Set Variable or Delay 2 action?

@eric-b-wu I just tested that scenario as well and it works, it shouldn't make a difference in this case. unless the dependent is in the same scope. I tried a few different combinations and it's working as it should for us.


Extension Bisect should not re-enable most extensions throughout the process

This is directly related to #111669 in which the OP describes how bisect is unable to find any "bad" extensions if there is more than one.
According to the docs, bisect re-enables the extensions it considers "fine". This is problematic because if you have more than one "bad" extension, it will never be able to narrow down the problem to a single extension, and it will incorrectly tell you the problem may be with VS Code.
This could be fixed by bisect not re-enabling any extensions it has removed from the problem set until one of the "bad" ones are found. This would allow you to keep finding problematic extensions by repeatedly running the bisect tool until none remain, instead of the tool only working at all when there is only one "bad" extension.
Detailed Design
Here is the example from the docs on how bisect works now:

Bisect divides 24 extensions into two halves of 12 extensions each, and it disables all 12 extensions of the second half.
In this sample, the 8th extension is the "bad" one, so it is the first half and not disabled. Things are still not working as we'd expect. Because there is still an issue, extension bisect repeats the process, dividing the first 12 extensions into two parts: 6 are enabled and 6 are disabled. All other extensions are also re-enabled.
...

That very last part is what is problematic. If we eliminate that step, the tool would be able to uncover any number of problematic extensions. I will give two examples of my own: one with one bad extension, and one with two. (I am not sure what bisect does when there are an odd number of extensions, so for my examples I will assume it will give the remainder to the upper half when partitioning an odd number)

An enabled extension: …
A disabled extension: X
A "bad" extension: ☢

Example: 12 extensions with 1 bad extension

The bad extension is no. 3; bisect disables the upper half of all 12

—
—
☢
—
—
—
X
X
X
X
X
X

There is still a problem So bisect disables the upper half of the lower 6

—
—
☢
X
X
X
X
X
X
X
X
X

There is still a problem So bisect disables extensions 2 and 3

—
X
X (☢)
X
X
X
X
X
X
X
X
X

Problem gone, so bisect disables the non-problematic extension (no. 1), and then re-enables the lower half of the previously disabled set (so, just the 2nd one)

X
X
☢
X
X
X
X
X
X
X
X
X

Bisect can correctly identify no. 3 as the problematic extension

Example: 12 extensions with 2 bad extensions

The bad extensions are no. 4 and 12; bisect disables the upper half of all 12

—
—
—
☢
—
—
X
X
X
X
X
X (☢)

There is still a problem, so bisect disables the upper half of the lower 6

—
—
—
X (☢)
X
X
X
X
X
X
X
X (☢)

There is still a problem So bisect disables the lower half of the lower 6 (the first 3). Now we are working with extensions 4-6. Bisect re-enables the lower half of this group, which is just no. 4

X
X
X
☢
X
X
X
X
X
X
X
X (☢)

A problem is found with only one extension enabled, so this round of bisecting completes with a "bad" extension identified. However the user still experiences a problem so they start a new bisect. Let us assume the user has removed the first bad extension so there are now 11 extensions left, and the 11th one is the problematic one. Bisect disables the upper half of all 11 extensions (6-11)

—
—
—
—
—
X
X
X
X
X
X (☢)

The user no longer experiences the problem, so bisect disables the un-problematic half entirely and re-enables the lower half of the remaining extensions. This repeats until the 10th extension is the only one still enabled, still no problem.

 And the user does experience it with only the 11th extension enabled, so bisect identifies it as the problem to the user.

X
X
X
X
X
X
X
X
X
X
☢

Another scenario worth noting is that in the worst case, where the first and second extensions are the bad ones, the user will choose "I can reproduce" every single time. The current implementation takes this opportunity to tell the user that it could not detect a bad extension and that the problem might be with VS Code itself. In cases like this where we cannot be 100% sure that a singular extension is the problem, my new approach should probably include that same disclaimer when it identifies a potentially problematic extension.
While imperfect, this is still more useful than not identifying any extensions at all. I can think of several improvements that can be made as well; for example we could modify the algorithm to test both halves of a set of extensions for problems when a problem is encountered on one half and alert the user. This could save time by letting the user know that both halves of some set of extensions (which may be all of them if it is the first try) reproduce the problem, and let them choose to continue bisecting or not.

An example of a use case for this: when I open VS Code in my home folder, my CPU usage spikes dramatically for several minutes. I quickly found out that something was searching the entire contents of my home folder, which is rather large, so it seemed to go on indefinitely.
Looking at the logs, there were about 3 of my ~30 extensions doing recursive "find in workspace" for some file **/foo.ext. With those extensions disabled, my CPU usage did not spike any longer. (This particular issue isn't a major one per se, but I definitely want those 3 extensions disabled in my home folder workspace, and I wanted bisect to help me find them)
Bisect was totally useless because it couldn't narrow down the problem to a single extension. A version of bisect that gives you a best guess (or allows you to choose whether you want a certain answer or a best guess) would be way more useful

@jrieken I think you created Extension Bisect, so maybe have an opinion about this.


SHACL abstract syntax

Add support for SHACL abstract syntax.

It has already been implemented in https://github.com/weso/shapes-rs/tree/master/shacl_ast


Add Weights and Biases to Experiment Tracking section

Hi @dnth, thanks for your pull request. Unfortunately we don't include Weights and Biases on the list. Because, although it comes in an open source flavour, it doesn't meet the batteries included criterion. Weights and Biases open source requires a license key to use, doesn't allow commercial usage, and not all of the core features are open source.


Support tags in RPC server tasks

Describe the feature
The rpc server should accept an arbitrary set of key/value pairs for non-builtin task methods. These tags should be semantically meaningless, but should also be returned in the output of the ps and poll methods.
Example rpc call:
{
	"jsonrpc": "2.0",
	"method": "run",
	"id": "123",
	"params": {},
	"tags": {
	    "branch": "fix/orders",
	    "commit": "#abc123"
	}
}

Resulting ps output:
{
    "result": {
        "rows": [
            {
                "task_id": "7226e841-a870-4a52-96da-32cad6f78f2b",
                "request_id": "123",
                "request_source": "<IP_ADDRESS>",
                "method": "run",
                "state": "success",
                "start": "2019-10-10T13:41:56.389109Z",
                "end": null,
                "elapsed": 0.91682,
                "timeout": null,
                    "tags": {
                        "branch": "fix/orders",
                        "commit": "#abc123"
                    }
            }
        ]
    },
    "id": "123",
    "jsonrpc": "2.0"
}

Resulting poll output:
{
    "result": {
        "results": [...],
        "generated_at": "2019-10-10T13:41:57.282238Z",
        "elapsed_time": 0.8061051368713379,
        "logs": [...],
        "status": "success"
        "tags": {
            "branch": "fix/orders",
            "commit": "#abc123"
        }
    },
    "id": "123",
    "jsonrpc": "2.0"
}

Putting this data at the top level would violate the json-rpc spec. Could we put it into params, instead?

yes, that definitely works!


test: Job Info (bulk)

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#1032  👈
#1031
#1030
#1029
#1028
#1017 : 1 other dependent PR (#1018 )
#1010
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @Cobalt0s and the rest of your teammates on  Graphite


write permisions outside instead of workspace attributes

Description
Move permissions attribute outside instead on in workspace attributes
Issues Resolved

Screenshot

Testing the changes

Check List

[ ] All tests pass

[ ] yarn test:jest
[ ] yarn test:jest_integration
[ ] yarn test:ftr

[ ] New functionality includes testing.
[ ] New functionality has been documented.
[ ] Update CHANGELOG.md
[x] Commits are signed per the DCO using --signoff

Codecov Report

Merging #79 (d03934c) into workspace (e14f696) will decrease coverage by 23.26%.
The diff coverage is 0.00%.

@@              Coverage Diff               @@
##           workspace      #79       +/-   ##
==============================================
- Coverage      65.66%   42.41%   -23.26%
==============================================
  Files           3341     1604     -1737
  Lines          64591    32519    -32072
  Branches       10271     6098     -4173
==============================================
- Hits           42414    13793    -28621
+ Misses         19618    17684     -1934
+ Partials        2559     1042     -1517

Flag
Coverage Δ

Linux_1
?

Linux_3
42.41% <0.00%> (-0.01%)
:arrow_down:

Windows_1
?

Windows_2
?

Windows_3
?

Windows_4
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Changed
Coverage Δ

src/core/public/workspace/workspaces_client.ts
1.35% <ø> (-13.52%)
:arrow_down:

...e/server/saved_objects/serialization/serializer.ts
0.00% <0.00%> (-94.74%)
:arrow_down:

...ore/server/saved_objects/service/lib/repository.ts
1.37% <0.00%> (-82.82%)
:arrow_down:

...rver/saved_objects/service/saved_objects_client.ts
3.84% <ø> (-53.85%)
:arrow_down:

src/core/server/workspaces/workspaces_client.ts
0.00% <0.00%> (-10.72%)
:arrow_down:

... and 2290 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


bcachefs-tools: 1.4.1 -> 1.7.0

Description of changes

Update: bcachefs-tools: 1.4.1 -> 1.7.0
Changelog: https://github.com/koverstreet/bcachefs-tools/compare/v1.4.1...v1.7.0
Adding myself as maintainer
Change the license to gpl2Only matching upstream

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

[x] 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

[x] 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
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 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

[x] Fits CONTRIBUTING.md.

Pinging maintainers: @davidak @Madouura

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

@ofborg eval
@ofborg build bcachefs-tools

@ofborg build bcachefs-tools

@Mic92 @alyssais is this ready to be approved? Latest bcachefs fixes and features also depend on bcachefs-tools package.

Please squash the latest commit into the update, so there's not an intermediate point where it's using IFD.

@alyssais is this fine now? I decided to keep the last two commits separately, for obvious reasons.

Test failure on x86_64-linux should probably be investigated.  Is it just racy perhaps?

Test failure on x86_64-linux should probably be investigated. Is it just racy perhaps?

When I ran the test locally it did not actually "fail", it tested everything including in a VM, but then it took a lot of time at the finishing stage, leading to the timeout.

@Mic92 @alyssais do I need to make any other changes or is this ready to be merged?

Result of nixpkgs-review pr 304761 run on x86_64-linux 1

1 package built:

bcachefs-tools

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/3871

Thank you!


application update forced

Considering the issue I created -- change from applicationUpdateForce=false to applicationUpdateForce=true

https://github.com/sbt/launcher/issues/12#issuecomment-517756976


Fixed issue with finding submodule repo when gitPath is specified

Ran into this issue in a project where I want to include submodule commit information.
Issue occured when the local submodule repository is stored in a parents git directory (.git/modules) and the current working directory is a parent of the submodule working directory.

Thank you!


Add AWS HoC tracking events

Adds analytics events for AWS HoC buttons/links.
Please sanity check if any snowplow or schema things may break with this in production.
Please check if the values given to trackEvent make sense.
A single user may trigger any of these multiple times, so for the ones where we want unique counts we'll need to do aggregation with that in mind.

Coverage increased (+0.007%) to 62.228% when pulling 37f227ff7725a8f3955abf98084987a1c40efd38 on aws-hoc-tracking into e4d384f2119cf221be414908067045f09b21e778 on master.

Coverage increased (+0.01%) to 62.234% when pulling 580663765c112b962ac46f51af0bd1aaeff2ddb0 on aws-hoc-tracking into e4d384f2119cf221be414908067045f09b21e778 on master.

Coverage remained the same at 62.221% when pulling 2e4adb986c2c5873ce42589a56b67da88c9b15c1 on aws-hoc-tracking into e4d384f2119cf221be414908067045f09b21e778 on master.