Email appear by hover the link with the mouse

I use "hex" encode and on my localhost server, when I hover the link with my mouse, email appears in clear mode with my browser inspector.
Is that enough secured against spam ?

If you inspect the link using the browser's developer tools, you'll see that the email address is hex encoded.  Any email harvester would have to go through the extra effort of decoding it in order to get the actual address.  It's not bulletproof.  The usefulness/effectiveness of this method is debatable.  That's why it was removed from Rails.

If you inspect the link using the browser's developer tools, you'll see that the email address is hex encoded. Any email harvester would have to go through the extra effort of decoding it in order to get the actual address. It's not bulletproof. The usefulness/effectiveness of this method is debatable. That's why it was removed from Rails.

Thank you for your answer. I agree that email address is well hex encoded when I click on the link, when I see the source code of the page and when I see the link with the browser's developer tools. But my question is about when I just mouseover on the link without click on it. In this case, the email address appear in clear mode at the bottom left of the browser's screen.

Well the browser is smart enough to decode the links.  If it didn't, users might get confused if they saw the encoded link when they hovered over it.
This encoding feature isn't meant to have any effect on anybody actually visiting your site in a browser.  It's meant to deter scripts that grab your site's source code and parse it looking for email addresses.


folders and -fPIC

Hi!
Thanks for the code. I modified makefile this way to create missing folders and add a flag which had to add to be able to compile it.
Also a comment, it would be nice if there was a variable for tblis path.
makefile.txt

Do you mean I would use a variable that contains and replaces the use of ../tblis in the file?

regarding my comment tblis, yes, just the path, to be able to set it on top of the makefile, as people have different relative paths to tblis.
More importnatnly, everyone will have the problem with the missing folders.

I see. I did not create the makefile with other users in mind. But I can add it. No problem.


Affinity support in image building

This is a proof-of-concept implementation for fixing #1282 supporting scheduler options in image building. The code pulls the options from buildargs, similarly to how container creation pulls options from the container's environment variables.
My code assumes that the following PR will get merged into the dockerclient repository. After that happens, Godeps will have to be updated.
https://github.com/samalba/dockerclient/pull/177
I'm looking forward to your feedback. I've only seen positive response on #1282, so I hope you're OK with overloading buildvars.

Sent from Yahoo Mail on Android
On السبت, أكتوبر ١٧, ٢٠١٥ at ١١:٥٦ ص, Victor<EMAIL_ADDRESS>wrote:
This is a proof-of-concept implementation for fixing #1282 supporting scheduler options in image building. The code pulls the options from buildargs, similarly to how container creation pulls options from the container's environment variables.
My code assumes that the following PR will get merged into the dockerclient repository. After that happens, Godeps will have to be updated.
samalba/dockerclient#177
I'm looking forward to your feedback. I've only seen positive response on #1282, so I hope you're OK with overloading buildvars.
You can view, comment on, or merge this pull request online at:
https://github.com/docker/swarm/pull/1310
Commit Summary

PoC: affinity support in image building.

File Changes

M api/handlers.go (6)
M cluster/swarm/cluster.go (6)
A cluster/swarm/utils.go (31)
A cluster/swarm/utils_test.go (21)

Patch Links:

https://github.com/docker/swarm/pull/1310.patch
https://github.com/docker/swarm/pull/1310.diff

—
Reply to this email directly or view it on GitHub.

I removed the "proof of concept" label, because the PR I needed in dockerclient got merged. Also, I tested this PR manually, and it seems to work as intended. I got the output below on a swarm with 2 nodes.
pwnage:swarm pwnall$ docker build --build-arg=constraint:node==swarm-agent-3 .
Error response from daemon: unable to find a node that satisfies node==swarm-agent-3
pwnage:swarm pwnall$ docker build --build-arg=constraint:node==swarm-agent-1 .
Sending build context to Docker daemon 46.47 MB
Step 1 : FROM golang:1.5
(snip)

Can someone please take a look? /cc @vieux @jimmyxian

@pwnall Cool, thanks.
Also, can you write some integration tests? :)
Related to https://github.com/docker/swarm/issues/1312 (support --build-args)

@jimmyxian Done, can you please take another look?
Thanks for pointing me in the right direction w.r.t. testing!

ping @vieux

LGTM I like the idea

Thanks for adding the tests @pwnall
LGTM

Thanks everyone!!! :heart:

@pwnall Thanks. :laughing:

Is there a  related PR to add docs for this, or an open issue to add them?

@dnephin I'd be happy to put that together. Can you please point me to a model PR that I can follow? I'll poke around on my own, as well, but a good model might save some back-and-forth.

I'm not sure about a PR, but I would guess the docs would go into https://github.com/docker/swarm/blob/master/docs/scheduler/filter.md

@dnephin Thank you! Opened #1371


csv export needs to include owner-/collaborator-supplied metadata

csv exports are working and I'm getting hourly updates right now, which is great.
However, the export doesn't contain any information that allows me to link the subject ids from Panoptes back to the information I originally uploaded in the manifest, such as the image name(s), so I don't know what classifications go to which subject in a meaningful way for me to make sense of my results.

closed by #792


Revert missing utf-8 encoding for logged sample files (#2027)

closes #2027
when switching to EvaluationTracker an open(..., encoding="utf-8") was mistakenly dropped, causing issues for tasks where sample content might not be ascii. This PR fixes that. Tested to resolve the issue on BoolQ reported in #2027 .

cc @lintangsutawika this is ready for review!


Suggest: Add metasrc.com

This page is different regions(na, eu, etc.) and updated pretty fast, I think this page better than lolflavor, only reason: Not only plat, dia,. It has information from bronze to challenger.

Dup. https://github.com/dustinblackman/Championify/issues/113


How to evalaute norfair on my own dataset ?

Hello ,
I am trying to implement norfair along with yolov4 with my own dataset. I want to know how well norfair is tracking objects in my dataset ? can you please help me in evaluating norfair ?

The first step would be to generate videos and check the results by looking at them. A more sophisticated solution would be to make your data compatible with https://github.com/tryolabs/norfair/tree/master/demos/motmetrics4norfair and get the results there.

Hello @joaqo, I see that a ".ini" extension file is needed as an input to the motmetrics4orfair.py, can I know what contains in that file ? how to create it? My dataset contains videos, so how to generate the ".ini" file from the videos I have?

Hello @joaqo  , do I need to have the ground truth and detection files for the video data that I have and then use the above script to check the results ? what are the files that are necessary to check the performance of norfair on my dataset ? could you please elaborate in detail

Hi @vis58 , that is exactly it. You need detections and labels. Regarding the format, you just need to format your data in the same way that MOTChallenge people do. The easiest way to see this is to download the detections and labels on their 2017 datasets as is detailed in the link I provided above. Here is the relevant command though:
curl -O https://motchallenge.net/data/MOT17Labels.zip  # To download Detections + Ground Truth (9.7 MB)
unzip MOT17Labels.zip

Hello @joaqo , below is the example of how gt file looks like , there are in total 10 values, The values are 1., 2.,3.<bb_left>, 4.<bb_top>, 5.<bb_width>, 6.<bb_height> , what are 7th, 8th and 9th values ?

I think @aguscas can help you with this, as he was in charge of writing the parsing for these files. Agus, any idea on what these values mean?

Hellos @vis58, the 7th value is a confidence score (it can only be 0 or 1). A value of 0 as you have, means that the instance will be ignored in the evaluation (i.e. the object is marked as inactive), so it will neither count as a true positive, nor a false negative (for example, you may want this if the object corresponds to a reflection). If you want to set that particular instance as active (so that you take it into account), this value should be set as 1.
The 8th value is there to indicate the class of the object annotated. You can find a table with the corresponding value to each class in the following paper:  https://arxiv.org/pdf/1906.04567.pdf
The 9th value is the visibility ratio of the bounding box (your box may be occluded by other object, or it might be cropped by the frame boundary).

thankyou @aguscas , I have a couple of doubts regarding the script that helps in evaluating norfair on the MOT challenge dataset. They are ,

If I run the script like this "!python motmetrics4norfair.py --save_pred train" multiple text files are generated where it contains information about the predictions of each different MOT challenge dataset in the train folder, right ? So my question is how these predictions are generated ? is it a new prediction made by norfair? if yes, then how these predictions are generated as we only have 'gt' and 'det' files present in each folder?

if I run the script like this " !python motmetrics4norfair.py --save_metrics", what is happening here ? it is comparing the "gt" and "det" files and generating results for each folder? if yes, then what is the involvement of norfair in this as we already have a "det: file available?

I have multiple videos where I am running norfair, so how to evaluate norfair on my own dataset? I know we need to use the motmetrics4norfair.py script, but how to make my dataset suitable for this script to generate results? do I need to have "gt(grount_truth)" and "det(detection) " files?

Right, when using --save_pred you will save your predictions in multiple text files (one text file for each sequence). The predictions are made by a norfair tracker, using the detections provided by the challenge (the det.txt files). The gt.txt files are only used to compute the metrics (after all the predictions were generated). These predictions are stored in the format described in https://motchallenge.net/instructions/ . As we are doing only 2D tracking, the last 4 columns are all set to -1.
When using --save_metrics, it will save a text file with the results of the metrics obtained by comparing your predictions with the ground truth files. It is not comparing the 'gt' with the 'det' files, instead, it is comparing the predictions (produced by norfair using the 'det' files) with the 'gt' files. If you don't use --save_metrics, it will compute these metrics anyway and the results will be displayed on terminal, but won't be saved in a text file.

Thank you @aguscas, but how do I test the norfair on my own dataset because I only have the gt.txt file, which I labeled, but not the det.txt files?

Right now, norfair doesn't provide a direct way of doing this, but of course there is always a way :) . I will assume you already have a detector and that you also have a python script in which you are creating your predictions with a norfair tracker. Also, for each video you are processing, you should have a folder (I will call the path to this folder as input_path) in which you should have

/input_path/seqinfo.ini     (this is a file providing basic information of the video as you can see in the MOT challenge dataset, in this case you only need a line specifying in a variable seqLength the total number of frames in your video, for example seqLength=600)
/input_path/gt/gt.txt      (the text file with your annotations)

So, to test norfair with your predictions, you can initialize an Accumulators instance before you start processing every video (Accumulators class is defined in metrics.py, see https://github.com/tryolabs/norfair/blob/master/norfair/metrics.py). So at the beginning of your script you should have a line like accumulator = Accumulators().
After that, for every video you should do accumulator.create_accumulator(input_path), where input_path is the folder containing the seqinfo.ini file that we described before. For every frame in the video, you should update the accumulator with the predictions given by norfair, as accumulator.update(predictions).
When you finish processing every video, you should tell the accumulator to compute your metrics and to display them (or save them in a file). In order to do this, you should do accumulator.compute_metrics() to compute the metrics, and then accumulator.print_metrics() to print them (or accumulator.save_metrics() if you want to save your metrics in a text file).
If you want to check it, this is the exact same way we used the Accumulators class in https://github.com/tryolabs/norfair/blob/master/demos/motmetrics4norfair/motmetrics4norfair.py

Hello @aguscas , thankyou. I am trying the same way to evaluate norfair , but I have encountered the following error when updating predictions , can you please help me with this ?

That seems to be an error with rich (the progress bar and general cli tool we use), it seems it can't access somewhere to print its output. It looks to be unrelated to the metrics issues being discussed here. Are you running things on a Jupyter notebook? Maybe you reached un weird unstable state in your notebook and rich is having issues with that?

Hello @joaqo  ,yes I was using jupyter notebook , but now even I tried in visual studio code and encountered the same issue.

@vishnuvardhan58  @vis58   how did u solve the error which you were facing can you please give more details ?
@dekked  i am also getting same error as @vis58


Aperez/CVE 2023 5574

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

[x] The toolchain has been rebuilt successfully (or no changes were made to it)
[x] The toolchain/worker package manifests are up-to-date
[x] Any updated packages successfully build (or no packages were changed)
[x] Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
[x] Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
[x] All package sources are available
[x] cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
[x] LICENSE-MAP files are up-to-date (./SPECS/LICENSES-AND-NOTICES/data/licenses.json, ./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md, ./SPECS/LICENSES-AND-NOTICES/LICENSE-EXCEPTIONS.PHOTON)
[x] All source files have up-to-date hashes in the *.signatures.json files
[ ] sudo make go-tidy-all and sudo make go-test-coverage pass
[ ] Documentation has been updated to match any changes to the build system
[ ] Ready to merge

Summary
Add patch https://github.com/advisories/GHSA-79x6-r5x5-fvqw to xorg-x11-server ver 1.20.10
Change Log
Changes to be committed:
new file:   https://github.com/advisories/GHSA-79x6-r5x5-fvqw.patch
modified:   xorg-x11-server.spec
Does this affect the toolchain?
NO
Links to CVEs

https://nvd.nist.gov/vuln/detail/CVE-2023-5574

Test Methodology

Pipeline build id: xxxx

I polluted my tree with 2.0 branch


Add the possibility to allow blueprints to add custom keywords

For instance, for the VueJS blueprint, it can add the clientFramework value vuejs
@pascalgrimaud this one deserves a bounty

@MathieuAA are you working on this one?

The need for this GH issue is this: I'm a blueprint dev and I don't want the JDL parsing system to throw an error if the JDL content contains any value (option value, app value, anything a blueprint can add) related to the blueprint.
A simple example so that you get the full picture: the vuejs blueprint adds the "vuejs" (or Vue, I don't remember) app value for the "client framework" option. Pierre had to add the string as a valid value back then, but this isn't a good solution as you can guess...
The issue is a possible solution, but it's not definitive. I'm working on the "add the blueprints keyword" right now, and this issue may or may not be relevant after adding the keyword.
All ideas are welcome.

I started to implement this one, because I had an idea on how to implement it.
The concept is done.
I will created a draft PR to you take a look.
If this is already in progress, then I will close it.

The blueprint jdl will be loaded like I did at https://github.com/jhipster/generator-jhipster/pull/11337.

Alright I'll have a look then!


Record timestamp of changes related to work items

The goal of this change is to add 2 columns in the work_items table, one for the timestamp of the latest addition/removal of a child comment and the other one for timestamp of the latest addition/removal of a link (the work item being the source or the target of the link).
Having these extra data, we will be able to generate an ETag response header that will change upon addition/removal of comments/links, which should eventually solve #1370.

Note: the filling of these new columns can be performed by triggers, which will avoid extra SQL requests from the application.


Fleet overview

Fleets should be sort by every kind of load.

Total cargo or Max? Or something else?

Min cargo and max cargo but for all seperat. So i can check for most kolonists or most ironium etc.


secure text entry?

Does this support secure text entry?

sorry didn't see the password input field #mybad

sorry didn't see the password input field #mybad


Crash on Calling Collection Reload

Hi , i have used ur library in my collection view, i have mad my custom collection view have a single image on cell. I have passed all the data source and delegate this is my code,
//Collection View Reload         self.knowledgeCollectionView.collectionViewLayout = CardsCollectionViewLayout()         self.knowledgeCollectionView.isPagingEnabled = true         self.knowledgeCollectionView.showsHorizontalScrollIndicator = false         self.knowledgeCollectionView.reloadData()
` override func collectionView(_ collectionView: UICollectionView, numberOfItemsInSection section: Int) -> Int {
return cardsArray.count
}
override func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell {

    let cell = knowledgeCollectionView.dequeueReusableCell(withReuseIdentifier: "knowledgeCell", for: indexPath) as! KnowledgeCVC

    cell.cardImage.image = cardsArray[indexPath.row]

    return cell
}`

But when i call my VC the app crashes on a delegate written in ur library,
` // MARK: - UICollectionViewDelegateFlowLayut
@objc open func collectionView(_ collectionView: UICollectionView, layout collectionViewLayout: UICollectionViewLayout, sizeForItemAtIndexPath indexPath: IndexPath) -> CGSize {
    guard let cellWidthValue = cachedCellWidths?[indexPath.row] else {
        fatalError("cachedCellWidths for \(indexPath.row) must not be nil")
    }
    return CGSize(width: cellWidthValue, height: collectionView.frame.size.height)
}`

Error is Thread 1: Fatal error: Index out of range . How i can get rid of this?

Hi @Hamza123Imran,
Are you sure that you are speaking about the code from my library?
My library only includes CardsCollectionViewLayout.swift and there are no lines of code that you have  mentioned.


mixed concrete types with pointer receivers are unsupported.

I have a resolver returning a list of resolvers like this:
type resolver struct {}

func (r *resolver) Foos() ([]fooResolver, error) {
   // ...  implementation
}

type fooResolver struct{}

func (r *fooResolver) ID() graphql.ID

When I try to query with the schema above, I get an error like this:
parsing scheme: resolver.projectResolver does not resolve "Foo": missing method for field "id" (hint: the method exists on the pointer type)
        	returned by (*resolver.resolver).Foos

The code mapping these types shouldn't care whether or not there is a pointer when validating if a type implements an interface.  However, I'd like to use a pointer receiver on these methods to avoid the copy for each method.
To make this code work with a pointer receiver, I'd have to return a slice of pointers, which doesn't really make a whole lot of sense, unless there is expense to copying the type or they are shared in some way.
There are two points of inefficiency:

When creating a slice of pointers, we now have an allocation for each member of the slice, as well as the slice allocation. There should only be a single allocation for a shallow resolver type when creating a slice.
Additional cache pressure on the unnecessary layer of pointer lookups.

While these seem like small issues, they can contribute to performance problems by generating additional allocations and slow performance on cache line misses.
It looks like the issue is https://github.com/graph-gophers/graphql-go/blob/e582242c92cc545085df10b3598575a912e118a2/internal/exec/resolvable/resolvable.go#L233. It seems to make the assumption that a type can only have a method if it is a pointer type, when it should not care.

As far as I understand it, when a type is nullable in the GraphQL schema, then it needs to be a pointer in Golang. Am I missing something?

As far as I understand it, when a type is nullable in the GraphQL schema, then it needs to be a pointer in Go. Am I missing something?

Nullability doesn't really come into play here. If you want to represent a null slice, you just set it to null. While you can have a schema with nullable elements, it doesn't make a lot of sense in practice. In the case of this schema, the elements are not declared as nullable, so allowing a concrete resolver should be allowed.
Put into an example, we should be able have the following work, without modifying the type of the receiver:
type fooResolver struct{}

func (f *fooResolver() MyNullableBars() []*barResolver
func (f *fooResolver() MyConcreteBars() []barResolver

type barResolver struct{}

func (r *barResolver) MyField() string { return "bar" }

With the above, we have a barResolver that can be used in a nullable or non-nullable context. With implementation the way it currently is, I'd have to implement one with a pointer receiver and one with a concrete receiver, which shouldn't matter.
This lets us avoid copying for method calls and control nullability.

With implementation the way it currently is, I'd have to implement one with a pointer receiver and one with a concrete receiver, which shouldn't matter.

Well, how often do you need nullable and non-nullable version of the same resolver in the same schema? Again, the fact that it hasn't happened to me doesn't mean that it is not a real issue.

This lets us avoid copying for method calls and control nullability.

How does this let us control nullability?
I am still not convinced that this is a real issue.

I ran into the same situation. I tried to implement a schema with non-nullable resolvers, but had to re-implement my pointer receivers as value receivers, which comes with performance hits.

@jbacon out of curiosity what was the performance hit? Also, why did you have to change the resolver's pointer receivers? You could as well dereference the pointer in the resolver.

just ran into a similar problem - an example below
schema:
type Query {
  helloWorldOne: HelloWorld
}

type HelloWorld {
  hello: String!
}

resolver:
func (r *rootResolver) HelloWorldOne() *HelloWorldResolver {
	return &HelloWorldResolver{}
}

type HelloWorldResolver struct {
	// empty in this example
}

func (hw *HelloWorldResolver) Hello() string {
	return "Hello World"
}

Everything above works fine. However, if we I want to add a second query which returns non-nullable type
type Query {
  helloWorldOne: HelloWorld
  helloWorldTwo: HelloWorld!
}

func (r *rootResolver) HelloWorldTwo() HelloWorldResolver {
	return HelloWorldResolver{}
}

I get the following error:
panic: HelloWorldResolver does not resolve "HelloWorld": missing method for field "hello" (hint: the method exists on the pointer type)
        used by (*resolvers.RootResolver).HelloWorldTwo

In my project, I ran into this problem with some custom scalar involved and got a super vague panic message - took me a while to find out this root cause
Since GoLang makes the pointer receiver method accessible to both pointer & concrete types, I think it should be the same behavior for resolving both nullable & non-nullable fields in graphql.
To rephrase: I think ideally the method on pointer type can also be resolved by concrete type.
@pavelnikolov do you think it makes sense? If so, I can start looking into making the update


feat: support virtual fields

converted to draft until cds^5.5 is available

You can implement virtual field handling by substituting them:

thx for the hint, we just plugged into the core logic and got this going :)


Wrong format of time_start parameter in Java

Doing a call with the Java SDK i get this Error:
Caused by: java.lang.RuntimeException: the response code for url is an ERROR code:
	url = /v1/ohlcv/COINBASE_SPOT_BTC_USD/history?period_id=3YRS&time_start=2019-05-06T17:06:29.688072100Z
	response code = 400
	response body error = Wrong format of time_start parameter

I guess the problem is the Z and precision added from the toString() from the Instant class. The docs do not specify this as acceptable: https://docs.coinapi.io/?java#time
(There are 9 positions of millis but only 7 are documented)

No more than 7 are accepteble, can you make a pr?
Sent from my iPhone

On 6 May 2022, at 19:41, Roman Meier @.***> wrote:

Doing a call with the Java SDK i get this Error:
Caused by: java.lang.RuntimeException: the response code for url is an ERROR code:
url = /v1/ohlcv/COINBASE_SPOT_BTC_USD/history?period_id=3YRS&time_start=2019-05-06T17:06:29.688072100Z
response code = 400
response body error = Wrong format of time_start parameter
I guess the problem is the Z and precision added from the toString() from the Instant class. The docs do not specify this as acceptable: https://docs.coinapi.io/?java#time
(There are 9 positions of millis but only 7 are documented)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.


Remove josekit

🚧  WIP  🚧

We're only using josekit for it's data structures
We roll our own cryptography
Negative externalities outweigh benefits

Esoteric code
No less overhead
OpenSSL!

The goal here is not to build generalized JOSE solutions, it's to build JOSE solutions relevant to web5

Once we remove reqwest then both openssl and ring will be entirely removed from the dep chart, and thereafter we can remove the openssl build code from the two musl dockerfile's

interestingly enough, even though we are hand-rolling our own jose here, just glossing over the code diff it seems to me like there's far more code removal in this PR than code additions... speaks loudly IMO


Error on nextjs

Failed to compile
./node_modules/react-images-upload/index.css
Global CSS cannot be imported from within node_modules.
Read more: https://err.sh/next.js/css-npm
Location: node_modules/react-images-upload/compiled.js
This error occurred during the build process and can only be dismissed by fixing the error.

any suggestions?

just came across this too. Has anyone been able to fix it?

Me too , I am facing the same issue.


pull request for e2e test at 11/15/2016 12:56:08

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

optest/docs/updated_at.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


support exclude column

Motivation
The data table has 20 fields, but I only want to query 19 of them. Sea-orm does not seem to support field exclusion at present. It is too troublesome to call .column() 19 times
Proposed Solutions
add select api
fn column_exclude<C>(mut self, col: C) -> Self
    where
        C: ColumnTrait,
    {
        // code...
        self
    }

Hey @yuhaya, welcome!! Thanks for the suggestions!  Thanks for the suggestions! I just created a PR to perform similar operation.
https://github.com/SeaQL/sea-orm/blob/1520beaa15b86e7eafb7f0679e2c23d59d34c005/src/query/helper.rs#L115-L131

good!


feat:Addition of block device information in outputs

Is your request related to a new offering from AWS?
Is this functionality available in the AWS provider for Terraform? See CHANGELOG.md, too.

No 🛑

Is your request related to a problem? Please describe.

Ideally the module shout output the block device information that it was able to create.
This is useful specially to retrieve the volume IDs in case we'd like to make use of it (for eg to create Cloudwatch Alarms to monitor the volumes)
Describe the solution you'd like.

The module should be able to output the block device information (most importantly the volume ids since the other attributes are provided in the inputs)
Describe alternatives you've considered.

None
Additional context

@bryantbiggs: hello ! is it possible to reopen this issue that got stale ? I provided a fix also and looking forward for a peer review.
Thanks in advance.
Bests

This issue has been resolved in version 4.4.0 :tada:


Adding ability to modify ELBv2 endpoints.

Coverage decreased (-0.5%) to 67.619% when pulling 3c039e0935c95c09f4f7798e7ca2a8135f0033e3 on kevgliss:602-advanced-elb into 48735e685ccfa996db2849c8d9c785ce7f41f3bf on Netflix:master.


Do you have similar code for javascript?

hello, I am working for web and I need to understand your functionality. Can you provide in Javascript.

@abysshek  I haven't mich experience in Javascript. So, I won't be able to provide the code into Javascript. I will really appreciate if you can work on it and raise pull request of your work so that will useful for other users as well.


KONG featurs

Hi guys!
I want realize sub requests to different microservices in one request to KONG
That i mean

I send into KONG one REST API request
KONG create one sub-request to first service and receive ansver
KONG  take information from first ansver and create second sub-request to second service.
Ansver from second service KONG transmit ME back.

Is it posible?
What this functions name?

Ok thank!
May is it possible in enterprise version or something else?

neither in the enterprise version. A generic solution to this is very hard, hence usually easier to create a custom plugin specific to the flow you need.

Thanks!


Spliting feature after calling exception on hooks AfterScenario

I use specflow and extent reports and i have a method that executes after the scenario to check if there is an error and throw an exception if so, but it is spliting my reports, lets say i have 6 scenarios, and that scenario 3 and 5 fails, the report will be divided in 3, the first one with scenarios 1, 2 and 3(fail), the second with scenarios 4 and 5(fail) and the last one with scenario 6.
I don´t know if it is wrong to do that or if it is something that is expected?
The code is somehing like this:

I use it to run all the steps before stopping the test execution because my application storage what i was doing so i need a clean start before testing, so i have to do all the steps in one test before starting another
In this example 'Test' is a feature file with 2 tests on it, the first test(scenario) fails and the second dont, resulting on this:

I did some workaround before creating the feature and it works fine now, if someone goes thought the same thing here it is what i did, kind of dumb now that i think about it


Is this project still maintained?

Hi, @yaron2
We are very interested in this project. If workflows can work under the stand-alone, It will solves our two problems.

Build the workflow based on Workflow 2 json.
Service aggregation.

Yes the project is maintained. What you described are valid scenarios.

Yes the project is maintained. What you described are valid scenarios.

OK, Thanks for your reply.


Web interface for cache management

List of caches
Create cache
Delete cache
Flush cache
Cache size
Cache configuration

Web interface mockup

Moved to https://github.com/0blivi0n/oblivion-admin/issues/


max_sell_power sensor - enable/disable (goodwe, may be other)

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
Power Limit must be enabled to use the max sell power value. If it is not on, the set value is not worked with. Only when it is turned on, then it follows the set value. This is not taken into account in the graph.
Expected behaviour
If Power limit is on, then the value will be colored, otherwise gray.
Possible Solutions
New sensor e.g. power_limit_switch (or power_limit_mode) wil be created
If the sensor is not defined by the user, then the value of max_sell_power will be colored.
If defined, then:

return value 0 (disable) - max_sell_power will be gray
return value 1 (enable) - max_sell_power will be colored

https://en.goodwe.com/Ftp/EN/Downloads/User Manual/GW_SolarGo_User Manual-EN.pdf
see page 36
Mode
Both
Context / Reason
better information for users

Hi.
The card has support for this. You can use the solar_sell_247 entity  i.e. solar_sell_247: switch.sunsynk_toggle_solar_sell. It will add an icon shown in the screenshot below. I like the idea of colouring the max_sell_power grey when disabled. The icon has a line through when off as well

Hi,
so, that sensor exists. That's nice. Just finish the coloring to gray ;)
Thanks

Added to 4.35.0


Some APIs are unavailable on visionOS

macOS Version(s) Used to Build
macOS 13 Ventura
Xcode Version(s)
Xcode 14
Description
A couple APIs AudioKit uses (only a couple!) seem to be unavailable on visionOS. They will need workarounds or their enclosing functions to be excluded on visionOS.
I propose making a new branch that's visionOS ready by marking those functions as unavailable until those who understand them better can create workarounds.
Crash Logs, Screenshots or Other Attachments (if applicable)
No response

Same here. Am using XCode 15 beta 5.  Error at
guard let track = asset.tracks(withMediaType: .audio).first else {...}
Am working full time on a visual music synth for visionOS. Would rather not fork on my own; would spend a lot of time on an official branch.

@musesum I have a branch you can feel free to use in the meantime.

@warpling  Well I tried in my Package.swift
.package(url: "https://github.com/warpling/AudioKit/tree/visionOS", from: "5.0.0"),
but the most recent tags on your site stop at 3.6 -- I also tried
.package(url: "https://github.com/warpling/AudioKit/tree/visionOS", from: "3.0.0"),
but no luck. Not sure how tags work, I assumed they would carry over.

Hmmm I don't know tags well either but just target the latest from the branch instead. I don't know what the config looks like without using the SPM GUI.

This worked:
.package(url: "https://github.com/warpling/AudioKit.git", branch: "visionOS"),

@warpling
I'm able to get the visionOS simulator to compile (yay!) but, am experiencing a problem with iPadOS 17 beta on device with the following error
'loadTracks(withMediaType:)' is only available in iOS 15.0 or newer
Perhaps changing thie line in the Package.swift might fix?
platforms: [.macOS(.v11), .iOS(.v13), .tvOS(.v13)],


Feat/base64

Implements potential structure of a base64 JSON

We store pre-encoded values in a lookup table
build assembles the encoded values into an array
A client can decode then concatenate the strings to build a metadata standard json to be used across marketplaces

Benefits of this:

Dynamic on-chain metadata as the Realm/Adventurer evolves over time

NOTE- This is branched off the pending combat PR. Ignore those files. Only look at the new Base64 dir

Was thinking - why base64 encode at all? It's JSON, not a binary format, so I think just data:aplication/json, ought to work.

this is a fair point. That makes it cleaner


[Enh]: Allow for kwargs in LazyFrame.collect

We would like to learn about your use case. For example, if this feature is needed  to adopt Narwhals in an open source project, could you please enter the link to it below?
No response
Please describe the purpose of the new feature or describe the problem to solve.
Allow to pass collect arguments to the underlying backend method call. For instance with the current implementation it would not be feasible to run polars with its streaming engine.
Ideally this should be as flexible as possible and not necessarily follow the polars API. Reason for this is that each backend collect-like function allow for different arguments.
Suggest a solution if possible.
I suggest two possible implementations:

sklearn-like: pass arguments with a convention such as polars__streaming, polars__engine, dask__optimize_graph and so on

engine specific dict:
 def compute(
     self,
     *,
     polars_kwargs: dict[str, Any] | None = None,
     dask_kwargs: dict[str, Any] | None = None,
     <engine_kwargs>: dict[str, Any] | None = None,
     ...
     ):

If you have tried alternatives, please describe them below.
No response
Additional information that may help us understand your needs.
No response

yup agree - for duckdb for example there's a variety of formats you may want to collect into

Closing in favor of #1479


minor: add some test case

Pull Request Test Coverage Report for Build 3689
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.3%) to 83.146%

Totals

Change from base Build 3687:
0.3%

Covered Lines:
4282

Relevant Lines:
5150

💛  - Coveralls


not loading all files

What version of Music Assistant has the issue?
2022.6.5
The problem
Previously on 2022.6.3 my full library was loaded (I am using a mounted network drive). Now only part of my library is loaded. I see nothing in the logs that jumps out to me. How can I troubleshoot this? How do I collect debug logs for music assistant?
How to reproduce
not sure - need more troubleshooting logs.
Relevant log output
No response
Additional information
No response
What version of Home Assistant Core are your running
2022.6.0
What type of installation are you running?
Home Assistant OS
On what type of hardware are you running?
Raspberry Pi

Files that are loaded are all shown as Unavailable and do not play

Well, maybe obvious but did you check that the mount was there before MA loaded ?
What happens if you reload the MA integration ?

yes, directory is mounted. reloading results in the same.

weirdly enough it works after a reboot ...

OK this will be more stable as soon as I finish the native smb connection so the mount workarounds are no longer needed.


Office-mix app appears broken

A user emailed phethelp that the office mix app appears to be broken. Amy and I reproduced on our machines (both Mac), but it sounds like @ariel-phet also reproduced on his Windows.
When I try to 'insert' the PhET add-in, I get a brief loading animation, but then nothing happens.

@oliver-phet - I think it should be fixed now.  It looks like the script that automatically updates it has a bug.

Maybe there is a delay for the fix to come through? I just tried again and am getting the same behavior.

Did you try pressing reload?  That fixed it for me.

Yep, I reloaded, removed and re-added the add-in, and restarted PP.

After I click, Reload, I get a brief loading animation, then the screen remains blank.

It may be subject to caching on the Microsoft side.  It is a static file and not cached in varnish, but the test environment is still showing errors too:  https://labsjs.blob.core.windows.net/sdk/LabsJS-1.0.4/labshost.html?lab=https://phet.colorado.edu/office-mix/store.html?PostMessageLabHost
If you add an arbitrary query parameter, it works normally: https://labsjs.blob.core.windows.net/sdk/LabsJS-1.0.4/labshost.html?lab=https://phet.colorado.edu/office-mix/store.html?PostMessageLabHost&1234

@oliver-phet - Did you have a chance to check on the Mac again today?  The app is still working for me as of today in the labsjs links above and in Powerpoint for Windows.

Working again on my Mac. I'll close for now.


screenshot of the current page not embedded  into  log file.

SeleniumLibrary keyword-[Capture Page Screenhot] used in robot script, but the screenshot PNG doesn't show in robot log.html.
In output.xml, the keyword output is like this:
<kw name="Capture Page Screenshot" library="SeleniumLibrary">
<doc>Takes a screenshot of the current page and embeds it into a log file.</doc>
<status status="PASS" starttime="20210111 15:52:35.566" endtime="20210111 15:52:35.871"></status>
</kw>
But in correct casees, it shoud be like this:
<kw name="Capture Page Screenshot" library="SeleniumLibrary">
<doc>Takes a screenshot of the current page and embeds it into a log file.</doc>
<msg timestamp="20210111 16:24:01.458" level="INFO" html="yes">

</msg>
<status status="PASS" starttime="20210111 16:23:59.226" endtime="20210111 16:24:01.458"></status>
</kw>
As you can see, the  is lost.
Do you know the reason of this issue? Robot version is Robot 3.2.2 (Python 3.7.4 on win32)
Thank you.

What log level did you use? Is there any kind of post-processing of results?

What log level did you use? Is there any kind of post-processing of results?

Closing due to lack of information.


Upsert table backfill enhancement: support externally partitioned data

Problem
#6567 allows uploading a batch generated segment to Pinot upsert realtime table. Partitioned data is handled by defining the partition column in segmentPartitionConfig.columnPartitionMap. The addSegment flow uses the config to identify the partition value of the column in metadata.properties of the uplaoded segment and then assign the segment to instance based on the partition id and instance assignment zk metadata.
This puts a restriction to define a partition column that is part of the table column(primary key) and also use only the configured partition function for partitioning data during segment creating in batch job using SegmentIndexCreationDriverImpl
This restriction is not applicable for stream generated segments during realtime ingestion. The partition id is identified using the LLC segment name convention. The stream is partitioned externally and Pinot table does not need to be aware of the partitioned column/function.
Proposal
Proposal to enhance SegmentAssignment.assignSegment() flow to rely on externally provided partition id for an uplaoded segment.

Need to persist the partition id as part of segment zk metadata.
Modify the StrictRealtimeSegmentAssignment.assignSegment to get partition id from zk metadata.
Provide partition id externally:

Option 1: Provide partition id as http headers during segment upload
Option 2: Provide partition id as part of uploaded segment metadata(not as columnPartitionMap) (metadata.properties)

Related: #10896, #11914

For real-time ingested data, the partition must match the upstream partition id to ensure the upsert assumption of all data of the same partition served by the same server, and I don't think we can loose this requirement.
Partition function is required for partition pruning. If partition pruning is not required, then we may allow custom partition id without a partition function.

For real-time ingested data, the partition must match the upstream partition id to ensure the upsert assumption of all data of the same partition served by the same server, and I don't think we can loose this requirement.

Yes, this is not supposed to be changed, but here we are getting the partition id from upstream instead of Pinot applying any partition function on primary key column to find the partition id.
Similarly, we should have capability to provide a partition id for uploaded segment. Since the partitioning of data is being done externally and can provide the partition id for uplaoded segments as well.

Partition function is required for partition pruning. If partition pruning is not required, then we may allow custom partition id without a partition function.

This should be doable with upstream configuration that one should use a partition function from Pinot's list and on a table's column.
Since Pinot has not restricted which partition function to use in the upstream for creating upsert tables, we have use cases that can use custom partition functions, these use-cases also don't need partition pruning.

Provide partition id externally:
Option 1: Provide partition id as http headers during segment upload
Option 2: Provide partition id as part of uploaded segment metadata(not as columnPartitionMap) (metadata.properties)

IMO if we go for option-2, then we should be consistent to add this / update this metadata for all present segments too. Option-1 is better in that aspect as we already pass a lot of info as headers during segment upload and use each header as more of a config.

Another approach I believe can be utlized is defining a naming convention for uploaded segment similar to LLC. The segment name can capture the partition id. We already have a segment type as UPLOADED and SegmentPartitionMetadataManager#getPartitionId can be enhanced to extract partition id from name.
This would not require any changes to existing contracts or zk metadata.


Explore lighting possibilities

Best place to start is probably JavaFX lighting features

It seems there can only be a single lighting source applied as effect per node which heavily constrains high-level lighting options

Moved to https://github.com/AlmasB/FXGL/wiki/Issue-Feature-Question


Provide a basic CORS middleware

Users should be able to quickly setup CORS parameters for any RESTful backend they might be developing.
It should similar in usage as the already available middlewares (like GZip for example).

This should be closed by commit 1cc3619e6e4816145c60b6241539c5c53b999d12. Thanks @kryptt for the middleware. Please reopen if closing this is an error.


[177] enable skylight in qa and disable in prod

To test it's functioning before we ask skylight.io to enable our OSS account.
Context
We're trying to sort out Skylight and would like to ask them to enable our OSS account. However, we'd like to demonstrate that we have it working in qa first.
Changes proposed in this pull request
Enable skylight in qa and disable it in production (since our prod receives too many requests for the current free tier anyway).
Guidance to review
Checklist

[ ] Make sure all information from the Trello card is in here
[ ] Attach to Trello card
[ ] Rebased master
[ ] Cleaned commit history
[ ] Tested by running locally

 Configure Skylight in qa


Consumption of Maven BOMs

Organizations in the Maven world leverage the BOM concept to predefine "blessed" or "known" dependency versions. Enable Gradle to consume BOM natively.
Expected Behavior
Gradle users can define dependencies without a concrete version. The version is resolved from a BOM that's defined for the build. The build fails if the version is not defined for the group and name of the dependency. User do not have to use external plugins anymore.
Current Behavior
Gradle does not support the consumption of BOMs. Users that want to consume BOMs have to consume external plugins e.g. the Pivotal dependency management plugin.
Context
Make it easier for projects that migrate from Maven to Gradle to reuse existing Gradle infrastructure.

As the main developer of Pivotal's dependency management plugin, I'd love to see it become obsolete. If there's anything I can do to help, please do just let me know

@wilkinsona I'd say a good way to start on this would be to 1) start a discussion on the Gradle dev-list and 2) write a spec. Your input would be super valuable given that you have a lot of experience with the support of BOMs in the Gradle. Would you be interested in kicking off a discussion on the dev-list?

Done: https://groups.google.com/d/msg/gradle-dev/UmeM6W-GYVM/s16rNBsOCQAJ

User do not have to use external plugins anymore.

What's the issue here? The fact that a community plugin could add this functionality on top of our APIs tells me that they are sufficient to solve all kinds of interesting use cases. I think we should get away from binding ourselves to Maven instead of adding even more of its concepts into Gradle core.

As the main developer of Pivotal's dependency management plugin, I'd love to see it become obsolete.

Could you elaborate why that is? If the maintenance of that plugin is hard, then we should find out what the problems are and help with those. I'd be very much in favor of keeping this in a community plugin, making that plugin efficient and easy to maintain and then promoting it for anyone who misses BOMs. E.g. gradle init could automatically apply that community plugin when it converts a Maven project that was using a BOM.

Could you elaborate why that is?

It's largely subjective, but it feels to me like the sort of thing that Gradle should support natively. Maven is the de facto standard for dependency metadata on the JVM and boms are becoming increasingly popular (Jackson recently added one, for example). Many users of the plugin have expressed their thanks for the plugin and their surprise that it was needed.

If the maintenance of that plugin is hard, then we should find out what the problems are and help with those

It's certainly caused some problems in the past, but things appear to be better now. The plugin's now 100% Java (it was written in Groovy previously) and doesn't try to support such a broad range of Gradle versions. Both those changes seem to have helped.

Many users of the plugin have expressed their thanks for the plugin and their surprise that it was needed.

I think we want to get away from the sentiment that "using/needing a community plugin" is somehow bad/surprising. The plugin ecosystem is what makes Gradle great. I'd much rather move more stuff out of Gradle's core distribution than pulling things in. Especially if there already is a dedicated and capable maintainer. This will require more work on our side of course, e.g. stabilizing APIs, making core plugins less "special" and promoting community plugins.

This will require more work on our side of course, e.g. stabilizing APIs, making core plugins less "special" and promoting community plugins.

Irrespective of the decision here, this is something that I'd really like to see. I won't retread old ground too much here, but if Gradle's core plugins only used public API then it'd go a long way to levelling the playing field. Perhaps that's part of what you meant by making them less special?

Yes, that's exactly what I mean.

Thanks for opening the discussion on the dev list, @wilkinsona. Looks like it didn't get any traction over there and the discussion is rather happening here.
My 2 cents about this topic: I agree that we need to have a better set of public APIs so that plugin developers don't need to use internal APIs. I also agree with @wilkinsona that Maven BOM support feels very core. Gradle prides itself with being almost 100% compatible with Maven - but then doesn't support an important feature of the Maven spec. We do support other portions of that same spec like consumption of parent POMs, Maven properties etc. That sounds kind of weird and makes it hard for people migrating from Maven to have a smooth transition.
In the long run we could think about Gradle's Maven support as a separate module or plugin for Gradle but we are long ways away from that. Either way I see users run into issues with BOM consumption all the time. It is frustrating and doesn't shine a good light on Gradle. I am thinking of Gradle as an "integrator" of other tools. From that perspective I don't see why we shouldn't support BOM consumption natively. Yes, it will require effort, work and future maintenance on our end but right now we are rather at risk of losing users or at the very least confusing/frustrating them.

The use of BOMs is core to our maven infrastructure. I'm surprised this isn't considered a necessary feature of Gradle resolution since its the Maven idiomatic way to address dependency consistency across multiple projects. Yes, we can accomplish this using nebula-recommender or pivotal plugins but then we have to rely on Nebula/Netflix or Pivotal for their plugin updates and they may not have the Gradle road map or ideology close in mind (slack in updates) nor do they necessarily have the same capacity or priorities.

Maybe this comment may be a little off topic, but kind of within the same topic. I was just thinking why limit to maven BOMs?
In case that one needs to support both maven and gradle, then it will most likely be advantagous from a maintenance perspective to support a single format and that would most likely be BOMs, however in case that one has gone all in with gradle. IMHO then maybe it would be better to use a format that was more gradle like.
So maybe rather than have some logic integrated to the gradle core and get locked into maven BOM. I think it would be more beneficial to have an API for resolving dependencies and get the flexibiltiy to resolve dependencies using maven BOMs or some alternative.

I think it would be more beneficial to have an API for resolving dependencies and get the flexibiltiy to resolve dependencies using maven BOMs or some alternative.

And that's exactly what Gradle's dependency resolution infrastructure already provides. We can certainly make that more powerful, so that BOM support becomes easier to implement, faster etc. But I wouldn't hard-bake BOMs into Gradle's core.

BOM support feels quite core for me too. Most of our JEE projects use a BOM to determine what dependencies play well together.
But the solution of this issue could be something in the middle: continue using a plugin but treat it as "official".
I rather prefer to have this functionality in the core but "official" plugins with gradle support could be an option

For anyone looking for the commit to see the changes c1076008bb70a9bb2dd4ad62c6a6ba4014def375

I'm really pleased to see Gradle getting native support for Maven boms. Thank you for adding it. Looking at the commit that @rwinch referenced above, I didn't notice any support for controlling the value of a property that's used in a bom. For example, Spring Boot's bom uses properties to control the versions of dependencies that it manages directly and boms that it imports. This allows users to easily override a version. Having is missed something in the changes made from Gradle 4.4 or is this something that could be considered as a further enchancement?

@wilkinsona I'd consider that a further enhancement, as it applies to any other Maven dependency too (i.e. we don't support setting properties and we only have very limited support for profiles).

I'd consider that a further enhancement, as it applies to any other Maven dependency too

AFAIK, that's the not case. Maven only supports overriding properties when a (p|b)om is used as the project's parent.

Yes, but since Gradle has no concept of a "parent", we'd need some other channel to convey properties to the Maven resolver. Probably on a project-wide basis, not per dependency. Does that make sense?

It does. As shown in the link I shared above, that's exactly what the Dependency Management Plugin does. Unfortunately, without the ability to override properties, Gradle's bom support will be of limited use to Spring users and we'll continue to recommend the use of the dependency management plugin instead.

I think we'll solve that another way with the upcoming constraints DSL. As far as I can see spring.version only affects dependencies with a particular group. This could be managed using something like:
constraint {
  group  'org.springframework'
  version  '4.0.4.RELEASE'
}

This would upgrade the spring version to 4.0.4 even if the BOM contained something lower.
The major upside of this would be that these constraints would be propagated to downstream projects (both inside a multi-project build and through publishing to a repository). Maven resolver adjustments like setting properties on the other hand would be confined to a single build and thus not very useful when you have downstream consumers.

I think we'll solve that another way with the upcoming constraints DSL

I think it would be better to support a Maven-specific concept in a way that maps directly onto Maven's way of doing things. To do differently would repeat the problems with subtly different handling of Maven exclusions.

As far as I can see spring.version only affects dependencies with a particular group

That's true for spring.version but it's by no means guaranteed to be the case, particularly when the property is controlling the version of a bom that's imported. A concrete example is Spring Boot's bom which imports Jetty's bom. Jetty's bom manages the versions of dependencies in multiple different groups.
With some regret, I have to say that I think this improvement in Gradle is actually going to make things worse overall. In my opinion, for this functionality to be generally useful, it needs to support as much of what Maven can do with a bom as possible, and do so in the same way as Maven. If the functionality is incomplete or works in subtly different ways to Maven's own support for the same concept, users are going to be left wondering how to map something that's easy when using a bom in Maven to Gradle and will sometimes come up blank. They'll then also have to decide between Gradle's own bom support or one of the third-party plugins that's currently filling the gap.

Does Maven even support overriding properties in an imported BOM? Afaik it only supports overriding properties in the parent POM, which is a different use case.

Does Maven even support overriding properties in an imported BOM?

As long as you use the bom that defines the properties as your parent, you can override its properties. That means that you can override the version of a bom that's imported by your parent bom. It's only when you import a bom directly in your own pom that you lose the ability to override its properties.

which is a different use case

Why do you consider that to be a different use case? In terms of dependency management, I think the use case is the same: use a bom to manage the versions of some dependencies.

It's clear that "BOM support" is a pretty large topic, and we were premature in declaring this feature as "delivered". We haven't communicated well enough about the BOM support that we are working on, which is being developed as part of a larger "better dependency management" project.
To clarify, the work we've done is the equivalent of BOM import into a Gradle build. A Gradle build will be able to declare a dependency on a BOM module, which will add version constraints to the build as well as any downstream consumers. This should allow Gradle users to leverage the spring-boot BOM file in the same way Maven users can via import.
(Note that this will be a minor breaking change to dependency resolution, and so will initially be guarded behind a feature flag.)
What we have not done is any work to allow a Gradle build to mimic the use of a BOM as a parent POM with property overrides. I think this is what @oehme was referring to as a "different use case".
What I'd like to do is reopen this issue and convert it into an Epic. This will allow us to add sub-issues for specific elements of BOM support and we can discuss and prioritize them individually.

It’s great to see this available (behind a feature flag) in 4.6 RC1. With things progressing, is there any news on the sub-issues for this now-epic issue? I’m particularly interested in properties support as this is something that’s widely used by Spring Boot’s users and, without it, I remain concerned about the confusion that will be caused as users try to figure out what to use.

It would be cool to have some use cases for that. You've probably seen most of them.
To me at first glance it seems that properties would water down the meaning of a BOM. I.e. a BOM says "these things work well together". If I start changing that with properties, I'm basically voiding that warranty.
Also afaik Maven does not support properties for BOMs. I.e. if you use the import scope, that imported BOM will not have its properties replaced. Afaik property replacement only works with parent poms.

In stable release semantics, a patch release ahead of any of the BOM defined dependencies should be compatible. BOM sometimes requires large horizontal synchronization of release schedule and does not tie everything in an exclusive project lifecycle. Some modules will be updated and available prior to larger BOM release, it happens to us quite often with our Reactor BOM.

So the use case would be "I want to upgrade part of the platform defined by this BOM to a newer version". As a user, why don't I just add a direct dependency to the newer thing I want?

There are a few cases where it's useful to be able to override a version using a bom's property:

A new release of a library is available that the bom has not yet picked up
There's a bug in the version of a library specified in a bom and you want to downgrade
The project providing the bom supports multiple different versions of a library and you want to use one other than the default

We see all three of these regularly being used by Spring Boot's users.

Also afaik Maven does not support properties for BOMs. I.e. if you use the import scope, that imported BOM will not have its properties replaced. Afaik property replacement only works with parent poms.

That's correct, and it's something that Maven users regularly complain about. The dependency management plugin removes this restriction when using a bom in Gradle and it's been warmly welcomed by users. There's been some discussion about improving the situation in Maven but the pace of change on that side of the fence is rather slow.

As a user, why don't I just add a direct dependency to the newer thing I want?

Because that would defect the purpose of using a bom in the first place. If the library contains multiple modules, potentially spanning multiple different group IDs, it's far easier to set a single property to pick  up the new version than it is to add versions to all your relevant dependences or to write a resolution strategy that applies to all the relevant group IDs.

Let me play devil's advocate a little further here: If the thing I want to upgrade itself consists of multiple libraries that need to be aligned together, why does that part not have its own BOM?

It often does. When that’s the case, Spring Boot will import the bom into its own bom, using a property to control its version. Users can then override the property to change the library’s version. This provides a consistent experience for overriding versions, irrespective of whether or not the library has a bom of its own.

To me it looks like there already are solutions: Well-behaved libraries have a BOM, which you can depend on in order to upgrade. Badly-behaved libraries can be fixed with component metadata rules. Or someone else can publish a BOM for that library if the original author can't be convinced.
Is your concern mostly around convenience of using Gradles APIs to fix versioning problems?
Adding support for properties feels like a redundant feature to me. It adds some convenience, but only for a limited use case. Properties are only a thing in Maven. Gradle's metadata format does not have properties.
We also plan to have alignment constraints which will allow you to concisely say "I need 5.0 for everything in the org.foo group". At that point even the convenience difference for badly-behaved libraries goes away.
I understand that properties are the only knob that Maven offers, but Gradle already has a feature set that solves these use cases and we need to be careful not to add more features that do the same thing. We don't plan to mirror Maven features 1:1 but rather adapt it to Gradle's model as best we can.
That's my view at least, I'm sure @jjohannes and @bigdaz also have some ideas around this. And of course I'm curious about your take on the comments above.

Does adding a BOM like below include all the dependencies specified in the pom.xml.
dependencies {
    // import a BOM
    implementation 'org.springframework.boot:spring-boot-dependencies:1.5.8.RELEASE'

    // define dependencies without versions
    implementation 'com.google.code.gson:gson'
    implementation 'dom4j:dom4j'
}

I would expect a clear difference from declaring dependencies when specifying a BOM.
Something like:
dependencyManagement {
    importBom 'org.springframework.boot:spring-boot-dependencies:1.5.8.RELEASE'
}

That also implies some properties from the pom.xml
A very useful way to manage consistent dependencies and properties across multiple projects.

To me it looks like there already are solutions: Well-behaved libraries have a BOM, which you can depend on in order to upgrade. Badly-behaved libraries can be fixed with component metadata rules. Or someone else can publish a BOM for that library if the original author can't be convinced.

Is your concern mostly around convenience of using Gradles APIs to fix versioning problems?

That's certainly part of it.
Another part of it is that publishers of a bom that is regularly used as a parent design that bom expecting it to be possible to override the properties that it uses. That's an entirely reasonable expectation for those publishers to have, as support for properties when used as a parent is an integral part of Maven's bom support.
Whenever Gradle adopts a Maven concept and consumes Maven metadata to support that concept, confusion arises if the default behaviour is different or certain features are not supported. We've seen it in the past with subtly different handling of optional dependencies declared in pom files (the requirement to be declared optional on all edges of the dependency graph vs a single edge). I think ignoring properties for bom imports would be making a similar mistake.
Another problem with not supporting properties is that the bom becomes a leaky abstraction. A consumer of a bom shouldn't have to know how it manages the versions of a particular library's modules when they want to override a version. If a property can be set to override the version, a user gets the same experience irrespective of how many group IDs the library's modules use and irrespective of whether the versions are managed directly in the bom or by a transitive import of a bom.

I understand that properties are the only knob that Maven offers, but Gradle already has a feature set that solves these use cases and we need to be careful not to add more features that do the same thing. We don't plan to mirror Maven features 1:1 but rather adapt it to Gradle's model as best we can.

Maven offers another knob. You can declare dependency management in your own pom and it will override the dependency management in the parent or in an imported bom. This is equivalent to importing a bom in Gradle and then declaring some component rules to override the bom. I haven't seen anyone use this approach in situations where they can use a property instead.

Thanks for the conversation, we really appreciate the effort you take in explaining your use cases and why you think things should work one way or another. You and our users deserve answers and I think we need to give a bit more context to understand our decisions and reflect on whether they are correct or not. First of all, as @oehme explained, our goal is not to map 1:1 to Maven concepts. We will when we think it makes sense, and we will propose different solutions when we think there are better ways to model things.
Our medium term goal is to:

provide first class model for expressing dependency recommendations, dependency constraints (this thing is compatible with this one, those things cannot work together because they both provide an implementation of the same API, ...)
provide ways to fix wrong published metadata, which is very common and the reason why we see so many "excludes" today
provide ways to enrich metadata as the ecosystem moves. Aka, this dependency has a vulnerability, make sure nobody uses it anymore
remove the need for external dependency management plugins like Spring DM or Nebula recommender and dependency rules.
provide a metadata file format that is richer than the Ivy and POM files and provides consistent user experience.

Support for BOMs fall into the "convenience" category: this is a widely used metadata format found in the Maven ecosystem, that we had to support one way or another. This is finally happening in 4.6 and we must rejoice. However, we also have our plans, and they involve understanding what library authors, what platform maintainers and what users all think when they use BOMs.
There are different use cases for BOMs, the main ones being:

as a platform maintainer, I want to make it simpler for users to use features of the platform, by just adding a dependency on a module without a version. Users trust me that I chose the best versions for the platform.
as a library maintainer, I want to make sure that all modules of the library are aligned, and that dependencies of the library are compatible. Said differently: "those things work together and have been tested"
as a user, I don't care what version to use, give me something that works (aka, versions as suggestions)
as a user, share some dependency versions between sub-modules of my Maven build (aka, BOM as a parent)

The reality is that people do not use BOMs for the same purpose everywhere, and reading questions on StackOverflow makes you realize things are far from perfect. Part of the problem with BOMs is that the intent and the implementation do not match (in the Maven world). Since they are not specified, the behavior is determined by the implementation, that you have to retro-engineer. This may be fine, but it's an illustration of something that was built ad-hoc, and that we use "because it kind of works".
For example, the technical definition of what a BOM is is only determined by the kind of dependencies that are found in a POM file. The file format is the same, and it's the presence, or absence, of both dependencyManagement or dependencies block that determine the semantics of the POM file. It may be a good idea to share the same metadata format, but we don't believe that having different semantics based on what you find in a file is a good idea, especially when you don't know if the BOM is going to be used as a "parent POM" or an "imported BOM". This, for us, means that we need to do best effort to support BOMs from the Maven world, but that we also have to give better solutions to our users and move on.
One particular problem with Maven and BOMs is that BOMs are not enforced transitively. If you, as a platform maintainer, write a BOM, it's most likely to express that "those things work together, please make sure the versions you choose are compatible". However, BOMs do not make any guarantee. The dependency management blocks are used:

for direct dependencies
from a parent to child

This means that a library that imports a BOM will potentially build, publish and pass QA, but once it's integrated, the BOM is not enforced. This is terrible behavior, we can surely do better. In short, it matters more to us that users get understandable and predictable results, than mimic’ing the behavior of Maven (you have to be aware that Maven POM files is only one of the metadata options that Gradle supports, but we effectively support more, like Ivy and potential custom models).
This is why 4.6 ships with the concept of "dependency constraints". Unlike BOMs, dependency constraints ARE transitive. If you say something about a dependency, if you say those things work together, they need to be enforced for the full graph (which also means we can potentially fail the build if you have conflicts). This is only a first milestone in the long series of features we're going to ship in 5.0. We want to solve use cases, not "simulate BOM". We cannot live on a weaker publishing model anymore.
So let's illustrate with the properties case. When you say "users can override the property to use a newer version of a library", there are a lot of hidden assumptions in there:

it means that your BOM effectively expresses dependency recommendations. This is not the same as a BOM that was intended to be used as a parent POM. It can be effectively the same, but it already corresponds to 2 different use cases that must be modeled properly.
it means that if a user wants a more recent version of a dependency, they must be allowed to do so. In our model, this corresponds to a "preferred" dependency version. You may have noticed that we also introduced the concept of "strict" dependency versions, which are there to express the fact that a dependency cannot be upgraded whatsoever (within the specification of the "strict" version, if it's a range).
if a user changes a dependency version, then the trust changes from the platform author to the end user ("We as Spring recommend this, but you can choose something else, beware of dragons!"). This is fine, but it also means that you need better ways to model what compatibility is. In particular, it's probably fine to upgrade from 1.0.1 to 1.0.2, but not to 2.0.0. This is the kind of things that we want possible to declare (this library follows semantic versioning).
Gradle and Maven use different models. Maven uses a single parent inheritance model, while Gradle separates how you produce a library from how you consume it. It's a composition model. This means that in Gradle you don't inherit from "parent project properties". You only do if you choose to. Said differently, the way you build your library shouldn't impact the way the consumers use it. Worst case, you BOM could define a property which is also defined in a 3rd party dependency, and they would conflict with each other. This cannot happen with Gradle.
we think "fixing bad metadata" is a use case that needs to be addressed. It's done on the consumer side of things through rules.
we think that "dependency constraints" will better model what a platform is. Being available transitively, and allowing to express richer things like "You cannot change this dependency version, that's the runtime which is effectively provided, so you need to live with this", it's a better user experience as you can clearly explain what was the intent when you declared a dependency.
we will do best effort to publish to _BOM_s, so that users of Maven or Ivy can have some of the semantics, but that's not our goal. We want software to be properly modeled. POM and BOMs cannot express what a real user is faced to, so we need our own metadata format.

So what can we do if we want to upgrade a dependency which is expressed using a property? One option is just to add an explicit dependency:
implementation 'org.springframework.boot:spring-boot-dependencies:1.5.10.RELEASE'

implementation ('com.fasterxml.jackson:jackson-bom:2.9.4') {
    because “we depend on features added in Jackson 2.9” // overrides the version 2.8.10 from the Boot POM
}

And you might say “what if the version is shared by different modules?”. This is a legit case for properties in Maven. However, this is not how we want to solve that. @oehme explained that what we will provide, instead, is a way to express that “those modules are aligned”, be it by group or something else. In other words, we want to model that “those things work together”, rather than relying on a weakly defined property, which may do the work, if there’s no conflict in the graph. By modeling, we will make sure it actually happens, instead of accidently working.
To summarize, this means that we’re committed to supporting the Maven semantics of a published BOM as much as we can,  but we might end up not supporting every feature Maven adds on top exactly the same way. Instead, we will provide alternative solutions to the use cases that fit the Gradle model and we’re focused on making this happen before or for 5.0 (alignment, fixing bad MD, ...). We will update this issue to discuss these solutions further once they are ready. So, it’s not because this issue is closed that it means we’re done with BOMs ;)

Hi Ben, can you please give me feedback if you still work on this issue? We are using spring-dependencies-plugin facing a performance issue and I am at the point to decide to add an issue at springboot-dependencies-plugin or to use the bom feature coming with gradle. So would be nice if you could give me some info on when this feature will be released

@moley This topic is still on our radar although recent releases have not seen a change to what was delivered with Gradle 4.6 behind the feature flag IMPROVED_POM_SUPPORT. That also means there is no target Gradle version thus far, though 5.0 is seriously considered.

ok, thanks for your info, gradle 5.0 will come this year or later?

@wilkinsona We have a really big project with many transitive dependency layers, so it's not that easy. But I am trying at the moment to create one with deps from mavencentral and open an issue.

@moley You can use the Gradle profiler to create flame graphs for @wilkinsona, so he can see the bottlenecks without having your build. E.g. run gradle-profiler --profile jfr --warmups 10 --iterations 40 assemble to measure the performance of a fully up-to-date build

We're always happy to get performance data, please open an issue :)

:-) one in gradle and one in spring-gradle-plugin?

Feature will be part of Gradle 5.0


Resolve compiler warnings

Resolved unused variable (Wunused-variable) warnings
Resolved control flow reaches end of non-void function (Wreturn-type) warnings

It seems that these variables are necessary in case we're linking against single solver :o

The variables are needed because they are used in assertions. :)


Continual spewing of "WebViewLoader: Could not ping localhost:5000" in Android app long after it has loaded and is being used.

@jamalex notes from bug bash:
per logcat — it seems it continues to try to check the server even when not available — and actually, it's not even running on port 5000, it's on 8080 — seems like it's a pew thing
https://www.notion.so/learningequality/BUG-ish-Continual-spewing-of-WebViewLoader-Could-not-ping-localhost-5000-in-Android-app-long-aft-282e4478d4c94f699edb773ea582a29a

👋
I'm pretty sure this is a python-for-android thing, their webview backend by default assumes there's a Flask server running on port 5000 and keeps pinging it until it finds it so it can know when to load the UI, which in this case it never will. Here's where the message is probably coming from:
https://github.com/kivy/python-for-android/blob/a9eee16b32d1991f04d4d6316c6320ad0dde4524/pythonforandroid/bootstraps/webview/build/templates/WebViewLoader.tmpl.java#L35
It does take a port argument, so it may be possible to update pew to pass down a port argument to the p4a command, so that it's checking the port Kolibri is running on. As the Kolibri app does its own checking, this may be redundant, but it is probably a much less painful fix than trying to patch this class template file. Would be happy to accept any PRs to pew proper that lets you specify the server port in project_info.json, or, no promises, but maybe I could look at this myself over the holidays, as this would be nice to have for my own projects as well.

Hi @kollivier - we're planning to write our own custom p4a bootstrap in order to make some further changes to the loading experience, so no need to prioritize this on our account!


Gradebook manual grade entry triggers stacktrace

I left it in jira before thinking: https://jira.sakaiproject.org/browse/SAK-32425

this should be fixed in #3930  - the stacktrace in the above has:
Caused by: java.lang.NumberFormatException: For input string: "6,5"


Don't set multipart/form-data content-type

Fixes: https://github.com/acacode/swagger-typescript-api/issues/172
It's better to let the browser handle setting of this content-type, since it will add the correct boundary.

@all-contributors please add @Styn for code bug


support for disabling plugins

I'd love to see support for disabling Jenkins plugins. The core distribution ships with some plugins that aren't necessarily used in all deployments (i.e. CVS). This can be handled by writing an empty "{plugin-name}.jpi.disabled" file to the plugins directory.

#209 resolves this issue.  It can be closed.

@jhoblitt I'm sitting here researching the plugin behaviors and when i read #209 i got confused because I do not see how that credentials fix resolves this plugins issue? I didnt notice anything in that explaining it.  Could you clarify?

@gregswift My apologies, it was the PR merged after that, #212   That PR was released as part of v1.4.0.  I'm going to close this issue but please feel free to reopen it if there is a bug with this functionality.


Ruby 2 4 upgrade

Update to Ruby 2.4.1. Required upgrading activesupport for compatibility, which also required upgrading mongoid. That in turn highlighted a broken test, which I've fixed.

I've changed the view renderer from erubis to erb, because erubis isn't required any more by other gems, and rather than re-adding it, I decided to just use default erb. This shouldn't change anything in any views, but there's a chance.


feat: HMR for Client Components loaded by Server Components

Description
Resolves #39
After 22 hours of debugging & tackling, I finally made it work, and now client components like ProductDetails have HMR like other components without reloading.
Additional context

Custom HMR event
invalidate some components' caches for refetching
fetch('/react?state=' + encodeURIComponent(key))

Before submitting the PR, please make sure you do the following:

[x] Add your change under the Unreleased heading in the package's CHANGELOG.md

@Aslemammad Hey, thanks a lot for contributing! We are modifying and removing a lot of these files in #317 so we will have many conflicts. Since that PR is going to be merged somewhat soon, can you wait on this until then? We can revisit the HMR issue once we use the official version of RSC 🙃
Aside from that, can you think of a way to force Vite to refresh the import.meta.glob (updating the ?v query) when receiving a hot update? That would be cleaner than using raw dynamic imports with a custom query because the module.id doesn't necessarily need to equal to the absolute path of the file (we might use a hash in the future). Or perhaps we just need to inform Vite's module graph about client components and entry-server 🤔  -- Not sure if this is all possible, though.

@frandiox Thank you all for the support; why not? We can wait for it. It's up to you.
I couldn't find a way of just updating the ?v query, but we can try that later for sure after the await!
And about hashes & ... we can rethink that after merge if it does not happen that soon.

If you need any help on #317, I can help if you want. Thanks.

Closing since we've since moved on to a new implementation of RSC. If you find a solution that works in the new version, feel free to open another PR! ❤


[FLINK-30100][checkpointing] Remove the unused CheckpointFailureReason

What is the purpose of the change
Some CheckpointFailureReasons have not been used for a long time and should be removed. E.g:

TOO_MANY_CONCURRENT_CHECKPOINTS
CHECKPOINT_DECLINED_TASK_NOT_CHECKPOINTING
CHECKPOINT_DECLINED_ALIGNMENT_LIMIT_EXCEEDED
JOB_FAILURE

Brief change log

The first commit: Remove some unused exceptions and refactor some code of CheckpointCoordinatorTest
The second commit: Remove deprecated getCheckpointId of PendingCheckpoint
The third commit: Migrate checkpoint coordinator related tests to junit5
The fourth commit: Remove the unused CheckpointFailureReason

Verifying this change
This change is a trivial rework / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

Hi @pnowojski please help take a look, thanks. It's also a cleanup PR.

@pnowojski Thanks for your review!


[BUG]: compile.sh failing due to morpheus_utils/load

Version
23.01
Which installation method(s) does this occur on?
Source
Describe the bug.
I am trying to build morpheus from 23.01 release source. It seems like it couldn't include the morpheus_utils/load file.
Minimum reproducible example
./scripts/compile.sh

Relevant log output
+ set -e
+ BUILD_DIR=build
+ echo 'Runing CMake configure...'
Runing CMake configure...
+ cmake -B build -GNinja -DCMAKE_MESSAGE_CONTEXT_SHOW=ON -DMORPHEUS_USE_CLANG_TIDY=OFF -DMORPHEUS_PYTHON_INPLACE_BUILD=ON -DMORPHEUS_USE_CCACHE=ON -DMORPHEUS_USE_CONDA=ON '' .
CMake Warning:
  Ignoring empty string ("") provided on the command line.

CMake Error at CMakeLists.txt:75 (include):
  include could not find requested file:

    morpheus_utils/load

CMake Error at CMakeLists.txt:78 (morpheus_utils_initialize_package_manager):
  Unknown CMake command "morpheus_utils_initialize_package_manager".

-- Configuring incomplete, errors occurred!

Full env printout
No response
Other/Misc.
No response
Code of Conduct

[X] I agree to follow Morpheus' Code of Conduct
[X] I have searched the open bugs and have found no duplicates for this bug report

I believe git submodule update --init --recursive in the morpheus root dir will fix this before running the compile script. Please let us know if that is not the case.
@dagardner-nv this was the docs blind spot I mentioned after the utils sub-module was introduced.

It looks like its in the docs for 23.03, but not 23.01
https://github.com/nv-morpheus/Morpheus/blob/branch-23.03/docs/source/developer_guide/contributing.md#clone-the-repository-and-pull-large-file-data-from-git-lfs

thanks @pdmack @dagardner-nv,  the issue has been resolved


fix: Rename built in shadowing variables

Description
Fixes shadowing caused by visualization-interface. Fixed in https://github.com/ansys/ansys-tools-visualization-interface/pull/75
Checklist

[x] I have tested my changes locally.
[x] I have added necessary documentation or updated existing documentation.
[x] I have followed the coding style guidelines of this project.
[x] I have added appropriate unit tests.
[x] I have reviewed my changes before submitting this pull request.
[x] I have linked the issue or issues that are solved to the PR if any.
[x] I have assigned this PR to myself.
[x] I have added the minimum version decorator to any new backend method implemented.
[x] I have made sure that the title of my PR follows Conventional commits style (e.g. feat: extrude circle to cylinder)

Everything seems to be working fine @RobPasMue , feel free to review 🙂


Change "requires" -> "depends" in fabric.mod.json

It was changed in schemaVersion 1 / Loader 0.4.0 (see fabric-example-mod).

My bad didn't see this till now, I've gone ahead and done it already, but thanks


Unable to import renamed GitHub repository

I renamed my repos and want to rebuild the RTD project for it. I renamed the repo on GitHub and deleted the old project from RTD. However, when I go to import the newly-named repo, it does not show up, even after I click "Sync your GitHub projects" (the old repo still shows up, though).
This is the repo in question: https://github.com/marshmallow-code/apispec

I was able to do a "Manual import" of the repo, which works fine.

This sounds related to #1670, which will be resolved by #1695 when that is merged in shortly. Closing this as a duplicate


RFC: python3 support (which would mean dropping atleast 2.5)

Hi, since django 1.5 was just released with preliminary python 3 support, i think it's a good time to discuss what python3 support would mean for this app.
There are pieces of code that simply are impossible to do in a way that is supported from python2.5 up to 3.3 :( e.g. exception handling (http://stackoverflow.com/questions/11285313/try-except-as-error-in-python-2-5-python-3-x)
What are your thoughts about this? Is dropping python < 2.7 support even worth considering?

Fixed by @amadornimbis in #52, merged as aab1cfc508040ea87593e48b4d266800ba568635 and release as 0.21.0.


Full repo build doesn't work on rp2350

The removal of the RTC in Pico2 is causing some demos to fail on these devices
Attempting a full repo build with Ninja cases this error in breakout_encoder_wheel

/home/simon/pimoroni-pico/examples/breakout_encoder_wheel/clock/clock.cpp:6:10: fatal error: hardware/rtc.h: No such file or directory
6 | #include "hardware/rtc.h"
|          ^~~~~~~~~~~~~~~~
compilation terminated.
[778/15238] Building CXX object examples/breakout_encoder_...se_game.dir///__/drivers/ioexpander/ioexpander.cpp.obj
ninja: build stopped: subcommand failed.

There’s a fix for this - and other issues with SDK 2.0.0 - in one of the open PRs here- just requires an include change. I’ve been quite focussed in on the MicroPython stuff so it hasn’t made its way into main yet.
AIUI there’s another SDK revision coming this month… maybe… possibly… so I’m not in a tremendous hurry 😬

OK, the Ninja build broke when I was testing my PR for pico_display_28 + SPI so I just built mine with Make to test and wante to point it out in case it was unreported

Collating those fixes here - https://github.com/pimoroni/pimoroni-pico/pull/1008


Maybe loosen hspec bound.

Currently there is hspec 2.7.10 in Stackage LTS and tests pass fine with that. Maybe you can loosen the bound downward a bit?

(Builderror on nixos builders for context: https://hydra.nixos.org/build/146096657/nixlog/1/tail)

I'm a little confused here. I didn't expect anyone to run cabal test so I just made those dependencies very strict.
I can't tell what cabal command you used from the log, but on a clean environment I can clone the repo, change the bound to something bogus (eg., hspec == 3.8.*), and cabal build has no issues. It's not until I run something like cabal configure --enable-tests that I run into an issue.
Are you running the test suite and do you need to run the test suite?

Hey, sorry for not explaining.
I am a packager for the nixos distribution. We generally try to test all packages because under nixos some assumptions from typical systems are not fulfilled and we wanna make sure we don‘t distribute disfunctional packages. We don‘t have to run the tests. But sometimes we actually find issues that didn‘t happen in upstream tests, so we can even give something back to the ecosystem.
The dependency resolution is also a bit weird on nixos. We don‘t build every package with it’s on cabal generated buildplan but try to create on blessed package set which is based on a stackage snapshot and the latest packages from Hackage. That is the explanation why our build infrastructure tried to test your package with hspec 2.7.10.
If you don‘t want to loosen the bounds we can maintain an override downstream. But we general prefer upstream to loosen bounds to make build plans more flexible for everyone.


- group: 0, editor: log:rendererLog, selection: line: 414-414, col:  1-1

[2022-06-22 20:55:23.476] [renderer3] [trace] [History stack global-default]: notifyNavigation() (editor: log:rendererLog, event: edit)
[2022-06-22 20:55:23.477] [renderer3] [trace] [History stack global-default]: notifyNavigation() not ignoring (editor: log:rendererLog, event: edit)
[2022-06-22 20:55:23.477] [renderer3] [trace] [History stack global-default]: onSelectionAwareEditorNavigation() (editor: log:rendererLog, event: edit)
[2022-06-22 20:55:23.477] [renderer3] [trace] [History stack global-default]: replace() (editor: log:rendererLog, event: <none>)
[2022-06-22 20:55:23.478] [renderer3] [trace] [History stack global-default]: index: 4, navigating: false
- group: 0, editor: walkThrough://vscode_getting_started_page, selection: <none>
- group: 0, editor: log:rendererLog, selection: line: 1-1, col:  1-1
- group: 0, editor: log:rendererLog, selection: line: 12-12, col:  42-42
- group: 0, editor: log:rendererLog, selection: line: 1-473, col:  1-1
- group: 0, editor: log:rendererLog, selection: line: 414-414, col:  1-1

[2022-06-22 20:55:23.479] [renderer3] [trace] [History stack edits-default]: notifyNavigation() (editor: log:rendererLog, event: edit)
[2022-06-22 20:55:23.480] [renderer3] [trace] [History stack edits-default]: notifyNavigation() not ignoring (editor: log:rendererLog, event: edit)
[2022-06-22 20:55:23.480] [renderer3] [trace] [History stack edits-default]: onSelectionAwareEditorNavigation() (editor: log:rendererLog, event: edit)
[2022-06-22 20:55:23.481] [renderer3] [trace] [History stack edits-default]: replace() (editor: log:rendererLog, event: <none>)
[2022-06-22 20:55:23.481] [renderer3] [trace] [History stack edits-default]: index: 3, navigating: false
- group: 0, editor: log:rendererLog, selection: line: 1-1, col:  1-1
- group: 0, editor: log:rendererLog, selection: line: 12-12, col:  42-42
- group: 0, editor: log:rendererLog, selection: line: 1-473, col:  1-1
- group: 0, editor: log:rendererLog, selection: line: 414-414, col:  1-1

thanks for the log. since you cannot reproduce, the log isn't useful to investigate whatever was going on for you. if you can reproduce, pls create an issue with a log when reproducing


Current games issue

const nombre = args.slice([1]).join(' ');
const nombreUrl = nombre.replace(/\s/g, "%20").toLowerCase();
const summoner = await kayn.Summoner.by.name(nombre)
let game = await kayn.CurrentGame.by.summonerID(summoner.id) // awaiting doesn't solve it
console.log(typeof(game));

When trying to see the type of variable game if there is no current games for the Summoner, instead of the 404 object, the console returns an "Unhandled promise rejection" and I can't reassign it nor see it's type. Is this an issue or am I doing it wrong?

You forgot to await
kayn.CurrentGame.by.summonerID(summoner.id)

as well. All of kayn's requests return promises that must be awaited.

Same result.
(node:8832) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'then' of undefined
    at Request.catch.callback [as catch] (C:\Users\viks\Desktop\basil\node_modules\kayn\dist\lib\RequestClient\Request.js:67:49)
    at Object.execute (C:\Users\viks\Desktop\basil\comandos\riotAPI.js:46:71)
    at Client.client.on (C:\Users\viks\Desktop\basil\basil.js:55:11)
    at Client.emit (events.js:203:15)
    at MessageCreateHandler.handle (C:\Users\viks\Desktop\basil\node_modules\discord.js\src\client\websocket\packets\handlers\MessageCreate.js:9:34)
    at WebSocketPacketManager.handle (C:\Users\viks\Desktop\basil\node_modules\discord.js\src\client\websocket\packets\WebSocketPacketManager.js:105:65)
    at WebSocketConnection.onPacket (C:\Users\viks\Desktop\basil\node_modules\discord.js\src\client\websocket\WebSocketConnection.js:333:35)
    at WebSocketConnection.onMessage (C:\Users\viks\Desktop\basil\node_modules\discord.js\src\client\websocket\WebSocketConnection.js:296:17)
    at WebSocket.onMessage (C:\Users\viks\Desktop\basil\node_modules\ws\lib\event-target.js:120:16)
    at WebSocket.emit (events.js:198:13)
    at Receiver.receiverOnMessage (C:\Users\viks\Desktop\basil\node_modules\ws\lib\websocket.js:789:20)
    at Receiver.emit (events.js:198:13)
    at Receiver.dataMessage (C:\Users\viks\Desktop\basil\node_modules\ws\lib\receiver.js:422:14)
    at Receiver.getData (C:\Users\viks\Desktop\basil\node_modules\ws\lib\receiver.js:352:17)
    at Receiver.startLoop (C:\Users\viks\Desktop\basil\node_modules\ws\lib\receiver.js:138:22)
    at Receiver._write (C:\Users\viks\Desktop\basil\node_modules\ws\lib\receiver.js:74:10)
    at doWrite (_stream_writable.js:415:12)
    at writeOrBuffer (_stream_writable.js:399:5)
    at Receiver.Writable.write (_stream_writable.js:299:11)
    at TLSSocket.socketOnData (C:\Users\viks\Desktop\basil\node_modules\ws\lib\websocket.js:864:35)
    at TLSSocket.emit (events.js:198:13)
    at addChunk (_stream_readable.js:288:12)

Hmm, I have a feeling that
const summoner = await kayn.Summoner.by.name(nombre) // this line
let game = await kayn.CurrentGame.by.summonerID(summoner.id)

The commented line may be returning an error.
You can try this:
try {
  const summoner = await kayn.Summoner.by.name(nombre)
  let game = await kayn.CurrentGame.by.summonerID(summoner.id) // awaiting doesn't solve it
console.log(typeof(game));
} catch (error) {
  console.log(error)
}

to see what the error is.

{ statusCode: 404,
  url:
   'https://euw1.api.riotgames.com/lol/spectator/v4/active-games/by-summoner/omitted-the-ID-on-github-comment',
  error:
   { name: 'StatusCodeError',

Alright! This worked just fine. Must I place kayn.CurrentGame inside the Try block, or any call that may return a 404? does it scope it?

If you place it inside the try block, the whole try statement will run from start-to-finish unless an error occurs. So you'll be able to catch 404's, 500's, etc of both Summoner and CurrentGame.
I would put it in there personally, unless you want specific error-handling on a case-by-case basis.

Looks like there's no way to redefine the variable if there is no current game for the summoner, or at least that I'm capable of. Thanks for your help anyway! :)

Ohhh, I haven't been reading carefully. you can try this:
```javascript
const nombre = args.slice([1]).join(' ');
const nombreUrl = nombre.replace(/\s/g, "%20").toLowerCase();
let summoner = null;
try {
  summoner = await kayn.Summoner.by.name(nombre);
} catch (ex) {
  if (ex.statusCode == 404) game = null;
  else throw new Error("completely broken");
}
let game = null;
try {
  game = await kayn.CurrentGame.by.summonerID(summoner.id) // awaiting doesn't solve it
} catch (ex) {
  if (ex.statusCode == 404) game = null;
  else throw new Error("completely broken");
}
console.log(summoner, game)

O M G
So I can actually reasign if the variable is declared outside the  try{} catch {} block in the first place?!
Yes! This returns the current game object if there is one and allows me to reasign game to "No current games" if it's value is null due to ex.statusCode == 404. No bugs here, just an ES6 noob.

it's okay haha, good luck! I didn't read the question properly so my first answer or 2 were not actually answering the question properly