Add overlay manager driver

Because overlay is a builtin driver and global allocation of overlay
resources is probably going to happen in a different node (a single
node) and the actual plumbing of the network is probably going to happen
in all nodes, it makes sense to split the functionality of allocation
into two different packages. The central component(this package) only
implements the NetworkAllocate/Free apis while the distributed
component(the existing overlay driver) implements the rest of the driver
api. This way we can reduce the memory footprint overall.
Signed-off-by: Jana Radhakrishnan<EMAIL_ADDRESS>

Forgot to change NetworkAllocate in drivers/windows/windows.go?

Good point. But without CI catching all of this, it is hard to remember all OSes and ARCHes. Will fix it.

LGTM

Mainly unused code now, needed for future development.
Given comments are addressed, will merge now.


[Feature]  add api docs

What problem does this feature solve?
api docs not available

What does the proposed API look like?

show how to get cursor position when double click
show how to append text at cursor

https://visactor.io/vrender/option/Arc


Edinburgh patch to fix issue #1731 (error handling in core-data POST event/)

Fixes #1731 for Edinburgh release.

This is my first time creating a PR for a patch to a released version, so please let me know if I missed anything.

Will this trigger us to tag 1.0.2 and release?

Codecov Report

Merging #1733 into edinburgh will decrease coverage by 0.02%.
The diff coverage is 0%.

@@              Coverage Diff              @@
##           edinburgh    #1733      +/-   ##
=============================================
- Coverage      17.01%   16.98%   -0.03%
=============================================
  Files             78       78
  Lines           8817     8829      +12
=============================================
  Hits            1500     1500
- Misses          7167     7179      +12
  Partials         150      150

Impacted Files
Coverage Δ

internal/core/data/router.go
4.66% <0%> (-0.07%)
:arrow_down:

Continue to review full report at Codecov.

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

Will this trigger us to tag 1.0.2 and release a new version for Edinburgh?

No, The TSC voted to not do that this morning. We're just getting it ready in case something else comes up.

@tsconn23 if that's the case can we drop the version bump from this PR?

@tsconn23 if that's the case can we drop the version bump from this PR?

If we don't then the merge job will overwrite the previously uploaded 1.0.1 images in Nexus.
https://jenkins.edgexfoundry.org/view/edgex-go/job/edgex-go-edinburgh-merge-go/configure
if we change it now then if we do decide to do a 1.0.2 release, subsequent PRs will be included i that patch release.

hmm okay, I didn't realize that every merge job will overwrite new images in nexus with the same version, that seems fragile, but oh well. I assume jenkins pipelines will solve this issue for good when everything is transitioned to that

😊 No re-writing history. Need to bump up!
From: Trevor Conn<EMAIL_ADDRESS>Reply-To: edgexfoundry/edgex-go<EMAIL_ADDRESS>Date: Wednesday, September 4, 2019 at 8:41 AM
To: edgexfoundry/edgex-go<EMAIL_ADDRESS>Cc: Subscribed<EMAIL_ADDRESS>Subject: Re: [edgexfoundry/edgex-go] Edinburgh patch to fix issue #1731 (error handling in core-data POST event/) (#1733)
@tsconn23https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftsconn23&data=02|01|mbhandaru%40vmware.com|f0e32cbdc9554af4bc3908d7314e5ab2|b39138ca3cee4b4aa4d6cd83d9dd62f0|0|0|637032084906483924&sdata=Hg5bKh%2FuVGaPh43CLhHLaxWDGME0l1cbXKU%2Ftm6%2Fa70%3D&reserved=0 if that's the case can we drop the version bump from this PR?
If we don't then the merge job will overwrite the previously uploaded 1.0.1 images in Nexus.
https://jenkins.edgexfoundry.org/view/edgex-go/job/edgex-go-edinburgh-merge-go/configurehttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjenkins.edgexfoundry.org%2Fview%2Fedgex-go%2Fjob%2Fedgex-go-edinburgh-merge-go%2Fconfigure&data=02|01|mbhandaru%40vmware.com|f0e32cbdc9554af4bc3908d7314e5ab2|b39138ca3cee4b4aa4d6cd83d9dd62f0|0|0|637032084906483924&sdata=ajTFeERpVLcZnymSi6%2FJBj8KOEFvb89Vo%2FlZH3cKbco%3D&reserved=0
if we change it now then if we do decide to do a 1.0.2 release, subsequent PRs will be included i that patch release.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fedgexfoundry%2Fedgex-go%2Fpull%2F1733%3Femail_source%3Dnotifications%26email_token%3DAAUTXVIVW4ZJY7GIFDKEFPTQH7JKRA5CNFSM4ITSNG62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD54AH7A%23issuecomment-527959036&data=02|01|mbhandaru%40vmware.com|f0e32cbdc9554af4bc3908d7314e5ab2|b39138ca3cee4b4aa4d6cd83d9dd62f0|0|0|637032084906493921&sdata=yvxbf3lVt3VfgMJrd68Fi5d%2BsMo4YqIcn%2BFUFqJzYLg%3D&reserved=0, or mute the threadhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAUTXVP7JJSU2EUKWI5AUO3QH7JKRANCNFSM4ITSNG6Q&data=02|01|mbhandaru%40vmware.com|f0e32cbdc9554af4bc3908d7314e5ab2|b39138ca3cee4b4aa4d6cd83d9dd62f0|0|0|637032084906493921&sdata=UD2UDPyJye8kIBGebYGkx4IQH%2FIZbFWLsVKCB3r1LXQ%3D&reserved=0.


Getting started is horribly, horribly out of date

Hello!
I've attempted to use diesel because I really like the interface, however I've been in getting started hell for a while now.
I ran into several issues around the diesel_codegen version, which I've fixed with a lot of time spent in this repository's issues section. Now I'm attempting to get diesel to compile for stable and am running into all sorts of version mismatches with syntex and am starting to wondering if this project actually works for anyone.
build.rs:13   diesel_codegen_syntex::register(&mut registry);
                                              ^~~~~~~~~~~~~
build.rs:13:35: 13:48 help: run `rustc --explain E0308` to see a detailed explanation
build.rs:13:35: 13:48 note: expected type `&mut syntex::Registry`
build.rs:13:35: 13:48 note:    found type `&mut syntex::Registry`
build.rs:13:35: 13:48 note: Perhaps two different versions of crate `syntex` are being used?
build.rs:13   diesel_codegen_syntex::register(&mut registry);
                                              ^~~~~~~~~~~~~
build.rs:14:28: 14:41 error: mismatched types [E0308]
build.rs:14   dotenv_codegen::register(&mut registry);
                                       ^~~~~~~~~~~~~
build.rs:14:28: 14:41 help: run `rustc --explain E0308` to see a detailed explanation
build.rs:14:28: 14:41 note: expected type `&mut syntex::Registry`
build.rs:14:28: 14:41 note:    found type `&mut syntex::Registry`
build.rs:14:28: 14:41 note: Perhaps two different versions of crate `syntex` are being used?
build.rs:14   dotenv_codegen::register(&mut registry);
                                       ^~~~~~~~~~~~~
error: aborting due to 2 previous errors

This is after having moved my extern definitions outside of the main body, after trying the syntex version specified in getting_started 0.31, as well as internet-suggested versions like 0.38, and 0.42. I'm running out of things the internet says to try.
The barrier of entry to using this is real, the main issue here is that the getting_started isn't up to date. I would totally put a pull request up against it if only I could get it to work.
Thanks for all the hard work you've put into this, it was fun trying to use it!

Hi, thanks for reaching out and writing an issue instead of just giving up and moving on! (Something I'm sure guilty of…)
So, with 0.7, the codegen story change a bit, which is why the getting started guide is probably out of date. This is being worked on! In PR #404 you can see we are about to add the example code from that guide to this repository.
As the changelog entry for 0.7 (here) mentions, "diesel_codegen has been split into two crates." @sgrif wrote a bit in this commit message on how to migrate.
Your error—thanks for adding this—already mentions what the problem is: There are two different versions of syntex in use. I admit, that's a bit hard to read 😄 I was actually looking at the Travis logs for #404 when I noticed that.
You are using diesel_codegen_syntax in version 0.7.2, right? That version has an upper bound on syntex version 0.43 (you mentioned 0.42 above). Can you check in your Cargo.lock what syntex you are using? If there are multiple versions, try to make sure to reduce it to one.
I hope that helps—this is just me guessing, actually…

Sorry, I've been short on time. I will make sure the guides are up to date this weekend.

That did it @killercup, thank you! This is my first rust project, so I'm still learning many of the debugging skills. Now I know version management is an active process with cargo.
@sgrif Thank you!

I'm just getting started and have been having a bad time. I've been following the current guide http://diesel.rs/guides/getting-started/ using the specific rust nightly. This issue is specifically labeled as "out of date", but I was under the impression that given rust's semantic versioning, old rust examples should just work.
But it won't even start compiling.
$ cargo build
    Updating registry `https://github.com/rust-lang/crates.io-index`
error: Package `diesel_codegen v0.7.0` does not have these features: `nightly`

Removing the nightly feature from the toml gets a bit further, but quickly runs into compile errors:
/Users/dsmith/.cargo/registry/src/github.com-1ecc6299db9ec823/dotenv_codegen-0.8.1/src/dotenv_macro.rs:13:66: 13:80 error: type name `ast::TokenTree` is undefined or not in scope [E0412]
/Users/dsmith/.cargo/registry/src/github.com-1ecc6299db9ec823/dotenv_codegen-0.8.1/src/dotenv_macro.rs:13 pub fn expand_dotenv<'cx>(cx: &'cx mut ExtCtxt, sp: Span, tts: &[ast::TokenTree])
                                                                                ^~~~~~~~~~~~~~
/Users/dsmith/.cargo/registry/src/github.com-1ecc6299db9ec823/dotenv_codegen-0.8.1/src/dotenv_macro.rs:13:66: 13:80 help: run `rustc --explain E0412` to see a detailed explanation
/Users/dsmith/.cargo/registry/src/github.com-1ecc6299db9ec823/dotenv_codegen-0.8.1/src/dotenv_macro.rs:13:66: 13:80 help: you can import it into scope: `use syntax::tokenstream::TokenTree;`.
/Users/dsmith/.cargo/registry/src/github.com-1ecc6299db9ec823/dotenv_codegen-0.8.1/src/dotenv_macro.rs:25:50: 25:64 error: type name `ast::TokenTree` is undefined or not in scope [E0412]
/Users/dsmith/.cargo/registry/src/github.com-1ecc6299db9ec823/dotenv_codegen-0.8.1/src/dotenv_macro.rs:25 fn expand_env(cx: &mut ExtCtxt, sp: Span, tts: &[ast::TokenTree])
                                                                                ^~~~~~~~~~~~~~
/Users/dsmith/.cargo/registry/src/github.com-1ecc6299db9ec823/dotenv_codegen-0.8.1/src/dotenv_macro.rs:25:50: 25:64 help: run `rustc --explain E0412` to see a detailed explanation
/Users/dsmith/.cargo/registry/src/github.com-1ecc6299db9ec823/dotenv_codegen-0.8.1/src/dotenv_macro.rs:25:50: 25:64 help: you can import it into scope: `use syntax::tokenstream::TokenTree;`.
error: aborting due to 2 previous errors

I'm new to rust, so I'm not sure where to turn to next. I'm not sure where the issue lies. Is this an issues with diesel? Is this an issue with a dependency? Is the guide in error? Did somebody break the semantic versioning rules such that the example no longer works now? If so, can the example be updated with very specific versions to get things running? Am I using the wrong nightly?
When a large public project such as diesel doesn't compile, especially given a "getting started" guide, it reflects poorly on rust IMO. Hoping this can be resolved quickly!

@devinrsmith
A breaking change to ast caused this (see slapresta/rust-dotenv#44).
However, another error pops up after that will in some time hopefully be fixed with #426, but meanwhile to use all of this replace your dependencies section with
[dependencies]
diesel = { git = "https://github.com/SergioBenitez/diesel" }
diesel_codegen = { git = "https://github.com/SergioBenitez/diesel", default-features = false, features = ["postgres"] }
dotenv = {git = "https://github.com/slapresta/rust-dotenv" }
dotenv_macros = {git = "https://github.com/slapresta/rust-dotenv" }

This solution is not pretty, but it works. These problems come from that diesel only "supports" new nightly releases with steps of 6 weeks.
I've also just started using diesel, and this was a huge :-1: for me. But the problem is really on our part, nightly is not stable after all.

@Emilgardis I know you disagree with our nightly support policy but please don't start commenting on every issue complaining about it.

This is my first comment on diesel (?). And I can understand the decision you've made, it makes sense.

My bad I thought you were someone who had opened another issue. :+1:


[path_provider] documents folder

Is there an existing issue for this?

[X] I have searched the existing issues
[X] I have read the guide to filing a bug

Use case
When we want our project to be able to find documents inside the user's computer, I believe that a good practice would be to find the Documents folder inside the user folder in all OSs. Sibling to the Download folder in all Desktop environments I believe.
Proposal
Create a getDocumentssDirectory method on path_provider. I believe this one should aim to simply have the functionality on all Desktop environments, not on Android or iOS.

Thanks for proposing this.
Can you help with more information on how this would differ from getApplicationDocumentsDirectory()?

I do not have a Mac, but I will try and test this on a virtual machine with Linux if needed. The issue was raised by me mostly because this one is not solved, maybe you can help me clarify that.
The first comment there, after the description, shows the following path: /Users/bbkane/Library/Containers/com.bbkane.readingWritingFiles/Data/Documents. From what I could tell, this is running on a Mac the getApplicationDocumentsDirectory function.
I still have a question:

Why is it that on Windows I get redirected to the Documents folder under my user's folder whereas on Mac (assuming my previous paragraph is right), Android and other systems give me a folder specific to my own app?

This question is asked because I can see a difference between the user Documents folder and a folder for documents my own app will store. Would then the second one be getApplicationSupportDirectory?

Thanks for your detailed response.
I think I understand that the Documents  folder you are referring to here is that of the device and not one specifically in the application.
Your proposal will be synonymous with getExternalStorageDirectory which is available only on Android.
If this is the case, kindly check out https://github.com/flutter/flutter/issues/127101, to confirm it's similar/related to the use case you are describing?

Yes, it is. Should this issue be closed then? Since that issue is more broad than this one?

Following the suggested issue and related ones, I found #77628 which is exactly what I was trying to say. I'm closing this in favour of that one (this comment explains my thoughts as well)


clipboard permission?

Why does this extension have permission to access a users clipboard?

Well there is an option to copy snippets directly to clipboard, so without it it wouldn't work. Also the extension is fully offline, you can see it here in the codebase. No data leaves your computer :D


ARC-1483 - UI cleanup

What's in this PR?

This PR addresses the UI nitpicks

Why

To improve UX

Are all the nitpicks accounted for? Would be great to see that reflected in the doc (update status from TODO to DONE)


Move create/patch device functions to fleet class, and export types

refactor it by moving certain functions to the Fleet class and making them static. Additionally, we can introduce new functions that allow querying device metadata without the need to create instances of the Device class. This modification is beneficial in scenarios where only device metadata is required, as the Device class might contain unnecessary functionality, and lack some data.


Do you have example using C# ASP.Net?

@damiangreen     @vhert09  did you find a asample ?
i have this problem http://stackoverflow.com/questions/32579274/instasharp-oauthresponse-not-work


add support for android support library 23.2.0

After update to support library 23.2.0,  a error occurs when aapt
Error:(3, 5) No resource found that matches the given name (at 'android:actionModeCloseDrawable' with value '@drawable/abc_ic_ab_back_mtrl_am_alpha').

on file:
\path\to\my\project\app\build\intermediates\exploded-aar\com.github.afollestad.material-dialogs\core\<IP_ADDRESS>\res\values-v11\values-v11.xml

There may be some other resources which are removed from support 23.2.0.
Please update and be compatible with this new released support library.
Thanks.
By the way, this release also add the ``Theme.AppCompat.DayNight```. This allows apps to easily support both a Light and Dark theme. I hope you can add support it in later release, too.

Duplicate of two issues opened within the past two hours.

https://github.com/afollestad/material-dialogs/releases/tag/<IP_ADDRESS>

The above won't work until JitPack installs version 23.2.0 of the Google libs repo.


'gcloud preview' command no longer supported.

141.0.0 (2017-01-25) (Google Cloud SDK) The deprecated gcloud preview app and gcloud preview datastore have been removed. Commands are available under the GA release track.

See: https://cloud.google.com/sdk/docs/release-notes

I cancelled the builds since this is an RST change.


Job name not visible when there are a lot of "culprits"

It is no longer possible to see the job name when there are lot of culprits. As a result, it is not clear which job is broken. You will have to click on it and go to the job to see which job it is. This is not a good situation for a big monitor view.

Hey @antonyj75 and thanks for your feedback. This request seems similar to what @patrickdepinguin asked for in #70. I'll be looking into addressing the way this information is displayed soon.
In the meantime though, I see that the top four builds from your screenshot haven't run in 10 days. Would it possible for them to be executed more often, therefore limiting the amount of change per build?
Best,
Jan

@jan-molak have you noticed that there is a pull request #116 pending that implements this feature?

Yes, I have, thanks for that PR, Patrick! I'm not yet sure though if hiding the culprits alltogether is the best solution to this problem... Let me elaborate a bit more.
It seems to me that the underlying problem here is that the builds are not executed often enough; too many changes git picked up by Jenkins and the list of possible culprits gets long.
From what I have observed this is a common scenario if the team runs nightly (or weekly) builds rather than executing a build per commit (or polling the VCS for changes every couple of minutes).
This practice usually results in a difficult troubleshooting process, as it's hard to tell what broke the build if you have to review (and potentially fix) code changes that came in from 30 people in order to make the build pass again...
Having said that, I agree that the visualisation should be improved and loosing the name of the build job from the view is definitely not good enough :-)
Instead of hiding the list of culprits though I'm thinking of displaying this information in a "facebook like button" style, so maybe:
Possible culprits: Adam Ipsum and 27 others

What do you think?

@jan-molak I don't think that the build-monitor plugin should try and dictate such policies onto its users. There may be very good reasons why a team can only run their tests once a day and thus have a long culprit lists. One such reason could be the limited availability of resources, or the long duration of an individual test run in very complex systems.
For this reason, I believe the plugin should be flexible and allow for some configuration.
Besides this, you should be aware of cultural issues. In some cultures (ethnical cultures or company cultures) it is considered inappropriate to blame people publicly on a wall display. Hiding the culprit list would work perfectly in such cases.
Having a 'Adam Ipsum and 27 others' text could even be worse, as now Adam seems to be blamed prominently while he could be totally innocent.

@jan-molak Our team runs builds with every code push. This includes jobs for both building our projects as well as running automated functional testing. Even though we run the jobs multiple times per day, we have so much activity in our mercurial repo for automated tests that we still have the problem that the screen is just filled up with the blame list when a job fails.
Having a condensed culprit would be helpful in allowing us to still see the job name, though being able to hide it all together would be preferable.

@jan-molak https://github.com/jan-molak  and others:
Thank you for your email.
Is it possible to provide an option to enable/disable the display of culprits?
We have several jobs that run at code commit.
There are also some performance jobs that we run daily, weekly, and monthly.
We do not want to see the culprit list in these jobs, because as you can see, the list could be large.
Therefore, it would be great if we are able to enable/disable the display of culprits.
For example:
Show culprits

When checked, the culprit list is shown.
Thank you. Have a nice day!
With kind regards,
Antony
Mass production of food is evil.
Foodstuff is best when produced by local farmers.
Want to know why? Watch  http://documentarylovers.com/film/food-inc/ Food Inc.
From: David<EMAIL_ADDRESS>Sent: 30 March 2015 20:44
To: jan-molak/jenkins-build-monitor-plugin
Cc: Antony
Subject: Re: [jenkins-build-monitor-plugin] Job name not visible when there are a lot of "culprits" (#138)
@jan-molak https://github.com/jan-molak  Our team runs builds with every code push. This includes jobs for both building our projects as well as running automated functional testing. Even though we run the jobs multiple times per day, we have so much activity in our mercurial repo for automated tests that we still have the problem that the screen is just filled up with the blame list when a job fails.
Having a condensed culprit would be helpful in allowing us to still see the job name, though being able to hide it all together would be preferable.
—
Reply to this email directly or view it on GitHub https://github.com/jan-molak/jenkins-build-monitor-plugin/issues/138#issuecomment-87718263 .Image removed by sender.

Good points, guys. I really appreciate your comments.
While I completely agree that the issue with job names getting out of view needs to be fixed, I'm wondering if the Claim plugin could help in scenarios you've described above?
Let me think out loud for a moment.
Claiming a broken build does several things:

hides the list of culprits
clearly indicates who's working on fixing the build so others can help him
helps to prioritise work

It seems that we talked about four scenarios so far:
1. Long-running builds
Builds can take a long time time to run because of bad reasons, i.e. using web browser-based tests to exercise the whole application stack where unit tests would suffice, or because of perfectly good reasons, like running system soak tests or performance tests for example.
In either case, I'd prefer to see at a glance how badly a build is broken, if it's broken.

If it contains 120 changes from 27 authors and nobody is working on it yet (it's not been claimed) it's probably not going to be trivial to fix. You might need the entire team to drop the tools and fix the problem.
If it contains a couple of changes from one to maybe a handful of authors someone can easily pick this up. The situation is not good, but we're not doomed yet :-)
If it's already been claimed I can easily tell who's on the case and offer them help if they need it.

2. Limited resources
Limited resources might lead to running builds less often. I'd argue that the situation here is same as above. If it's broken - you can claim it.
3. Higly active projects with a lot of change
It doesn't seem like the volume of change should justify leaving the build red?
I usually work on projects with hundreds of developers and a lot of change, but even on those project if the build is broken you shouldn't be pushing new changes unless they're to fix the failure. Should you?
And if you're the one fixing the build - again, you can claim it.
4. Lack of transparency
Now, here's a tricky one... The main purpose of Build Monitor is to help enable transparency. How to deal with a situation where transparency is not desired?
Even in such a situation I'd still like to know how badly a build is broken, and if someone is on it.
Claiming should again do the trick, but what if the build has not been claimed (yet)?
Maybe displaying something along the lines of the following could help to determine the scale of the damage?
           < job name >
Contains 120 changes by 27 authors

Actually, this information could also be displayed if a build is claimed...
Looking forward to hearing your thoughts!

Hi Jan,
Good morning.Thank you for your quick response.
Beyond the four scenarios, the source control and claim plugins have their limitations as well.
Some examples are:

I've seen that the list of culprits is not always correct. This is because, the list of contributors keep changing with multiple runs of the failed job. If you want to see the actual potential culprits, then you need to see the first time failure of the job. Subsequent failed builds of the job only show the contributors to those respective builds.
We have a gerrit automatic review system that also does commits to git. In this case, the possible culprit is shown as "gerrit". This gives no idea who the real culprit is.
You could only claim a failed build. We have several jobs that could be "unstable" when the coverage or coverity or test failures are within a threshold. The claim plugin does not provide a way to claim unstable builds. Therefore we are in the same situation where the job name is not visible. This does not provide a good experience when we have the monitor on the wall.

Your idea of displaying something like
< job name >
Contains 120 changes by 27 authors
sounds good to me.
So I request to either provide this functionality or give an option to hide/display the list of culprits in the configure screen.
In view of your desire to keep the plugin as simple as possible, I believe doing this will help keeping the display of data simple. :-)
Thank you!
With kind regards,Antony
 On Monday, March 30, 2015 6:35 PM, Jan Molak<EMAIL_ADDRESS>wrote:

Good points, guys. I really appreciate your comments.While I completely agree that the issue with job names getting out of view needs to be fixed, I'm wondering if the Claim plugin could help in scenarios you've described above?Let me think out loud for a moment.Claiming a broken build does several things:

hides the list of culprits
clearly indicates who's working on fixing the build so others can help him
helps to prioritise work
It seems that we talked about four scenarios so far:

Long-running builds
Builds can take a long time time to run because of bad reasons, i.e. using web browser-based tests to exercise the whole application stack where unit tests would suffice, or because of perfectly good reasons, like running system soak tests or performance tests for example.In either case, I'd prefer to see at a glance how badly a build is broken, if it's broken.

If it contains 120 changes from 27 authors and nobody is working on it yet (it's not been claimed) it's probably not going to be trivial to fix. You might need the entire team to drop the tools and fix the problem.
If it contains a couple of changes from one to maybe a handful of authors someone can easily pick this up. The situation is not good, but we're not doomed yet :-)
If it's already been claimed I can easily tell who's on the case and offer them help if they need it.

Limited resources
Limited resources might lead to running builds less often. I'd argue that the situation here is same as above. If it's broken - you can claim it.

Higly active projects with a lot of change
It doesn't seem like the volume of change should justify leaving the build red?
I usually work on projects with hundreds of developers and a lot of change, but even on those project if the build is broken you shouldn't be pushing new changes unless they're to fix the failure. Should you?And if you're the one fixing the build - again, you can claim it.

Lack of transparency
Now, here's a tricky one... The main purpose of Build Monitor is to help enable transparency. How to deal with a situation where transparency is not desired?Even in such a situation I'd still like to know how badly a build is broken, and if someone is on it.Claiming should again do the trick, but what if the build has not been claimed (yet)?Maybe displaying something along the lines of the following could help to determine the scale of the damage?           < job name >
Contains 120 changes by 27 authors
Actually, this information could also be displayed if a build is claimed...Looking forward to hearing your thoughts!—
Reply to this email directly or view it on GitHub.

Hi Antony and thanks for pointing those out.

I've seen that the list of culprits is not always correct. This is because, the list of contributors keep changing with multiple runs of the failed job. If you want to see the actual potential culprits, then you need to see the first time failure of the job. Subsequent failed builds of the job only show the contributors to those respective builds.

That's an intentional behaviour; The idea here is to avoid people committing code on a broken build.

We have a gerrit automatic review system that also does commits to git. In this case, the possible culprit is shown as "gerrit". This gives no idea who the real culprit is.

I see, I thought that this could be configured?

You could only claim a failed build. We have several jobs that could be "unstable" when the coverage or coverity or test failures are within a threshold. The claim plugin does not provide a way to claim unstable builds. Therefore we are in the same situation where the job name is not visible. This does not provide a good experience when we have the monitor on the wall.

I usually avoid using the concept of unstable builds because of the reasons I talk more about in my article "The bad case of rotting builds".
Nevertheless, I believe that the issue you've observed with the Claim plugin has been fixed in 2.5 (JENKINS-23513) so you might want to give that version a try?
Having said all the above, I really appreciate your feedback guys and agree that it should be up to the team to decide whether showing the list of possible culprits helps them or not.
I'll get get #116 merged soon, so stay tuned! :-)
Thanks for sharing your thoughts!
Best,
Jan

Thank you Jan for your detailed response, and sharing insights about gerrit configuration and claim plugin.
I will talk to the responsibles in our team to see if this could be done better.
A big thanks for merging #116 as well. J
Have a nice day!
With kind regards,
Antony
Mass production of food is evil.
Foodstuff is best when produced by local farmers.
Want to know why? Watch  http://documentarylovers.com/film/food-inc/ Food Inc.
From: Jan Molak<EMAIL_ADDRESS>Sent: 02 April 2015 16:11
To: jan-molak/jenkins-build-monitor-plugin
Cc: Antony
Subject: Re: [jenkins-build-monitor-plugin] Job name not visible when there are a lot of "culprits" (#138)
Hi Antony and thanks for pointing those out.
I've seen that the list of culprits is not always correct. This is because, the list of contributors keep changing with multiple runs of the failed job. If you want to see the actual potential culprits, then you need to see the first time failure of the job. Subsequent failed builds of the job only show the contributors to those respective builds.
That's an intentional behaviour; The idea here is to avoid people committing code on a broken build.
We have a gerrit automatic review system that also does commits to git. In this case, the possible culprit is shown as "gerrit". This gives no idea who the real culprit is.
I see, I thought that this could be configured http://wiki.qt.io/Setting-up-Gerrit ?
You could only claim a failed build. We have several jobs that could be "unstable" when the coverage or coverity or test failures are within a threshold. The claim plugin does not provide a way to claim unstable builds. Therefore we are in the same situation where the job name is not visible. This does not provide a good experience when we have the monitor on the wall.
I usually avoid using the concept of unstable builds because of the reasons I talk more about in my article  http://smartcodeltd.co.uk/blog/2014/10/16/communicating-build-status-better-with-jenkins-and-the-build-monitor-plugin/ "The bad case of rotting builds".
Nevertheless, I believe that the issue you've observed with the Claim plugin has been fixed in 2.5 (JENKINS-23513 https://issues.jenkins-ci.org/browse/JENKINS-23513 ) so you might want to give that version a try?
Having said all the above, I really appreciate your feedback guys and agree that it should be up to the team to decide whether showing the list of possible culprits helps them or not.
I'll get get #116 https://github.com/jan-molak/jenkins-build-monitor-plugin/pull/116  merged soon, so stay tuned! :-)
Thanks for sharing your thoughts!
Best,
Jan
—
Reply to this email directly or view it on GitHub https://github.com/jan-molak/jenkins-build-monitor-plugin/issues/138#issuecomment-88863198 .Image removed by sender.

Hi Jan,
We updated the plugin and used the "Show possible culprits?" option.Simply put: works like a charm.
Thanks a lot for getting this done so quickly.
With kind regards,Antony
 On Thursday, April 2, 2015 12:41 PM, Jan Molak<EMAIL_ADDRESS>wrote:

Hi Antony and thanks for pointing those out.
I've seen that the list of culprits is not always correct. This is because, the list of contributors keep changing with multiple runs of the failed job. If you want to see the actual potential culprits, then you need to see the first time failure of the job. Subsequent failed builds of the job only show the contributors to those respective builds.
That's an intentional behaviour; The idea here is to avoid people committing code on a broken build.
We have a gerrit automatic review system that also does commits to git. In this case, the possible culprit is shown as "gerrit". This gives no idea who the real culprit is.
I see, I thought that this could be configured?
You could only claim a failed build. We have several jobs that could be "unstable" when the coverage or coverity or test failures are within a threshold. The claim plugin does not provide a way to claim unstable builds. Therefore we are in the same situation where the job name is not visible. This does not provide a good experience when we have the monitor on the wall.
I usually avoid using the concept of unstable builds because of the reasons I talk more about in my article "The bad case of rotting builds".
Nevertheless, I believe that the issue you've observed with the Claim plugin has been fixed in 2.5 (JENKINS-23513) so you might want to give that version a try?Having said all the above, I really appreciate your feedback guys and agree that it should be up to the team to decide whether showing the list of possible culprits helps them or not.
I'll get get #116 merged soon, so stay tuned! :-)Thanks for sharing your thoughts!Best,
Jan—
Reply to this email directly or view it on GitHub.

Thank you, it is working fine! J
With kind regards,
Antony
Mass production of food is evil.
Foodstuff is best when produced by local farmers.
Want to know why? Watch  http://documentarylovers.com/film/food-inc/ Food Inc.
From: Jan Molak<EMAIL_ADDRESS>Sent: Sunday, November 22, 2015 1:59 AM
To: jan-molak/jenkins-build-monitor-plugin
Cc: Antony
Subject: Re: [jenkins-build-monitor-plugin] Job name not visible when there are a lot of "culprits" (#138)
Closed #138 https://github.com/jan-molak/jenkins-build-monitor-plugin/issues/138  via  https://github.com/jan-molak/jenkins-build-monitor-plugin/commit/ddd190b7dfebd95a2cec6882478e6773a0d5ec3c ddd190b.
—
Reply to this email directly or view it on GitHub https://github.com/jan-molak/jenkins-build-monitor-plugin/issues/138#event-471292261 .Image removed by sender.

Great, I'm glad to hear that you like this solution :smile:
I'll release the latest version of Build Monitor to Jenkins Update Centre next week, but if you'd like to take it for a spin before that you can always download it here.


[Event request] table 36 "Sales Header" - OnBeforeValidateSellToEmail

Hi there,
Please add this IsHandled Event to the "Sales Header" table.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


adding Documentation for the Repositories and Services classes #36 (#40)

Description
Added Javadoc comments to the Repositories and Services folders to improve code documentation and provide better context for each method and class. This enhances code readability and helps with future maintenance by offering clear explanations for the controller logic. No related issue was referenced for this change.
Type of Change

[ ] Bug fix
[ ] New/Update feature
[x] New/Update Documentation

Additional Information

Please do not close the issue as more Java Documentation needs to be added.

Approved, once again looks good


fix: Correct colab link in regression notebook.

The colab link in the regression notebook doesn't work. This PR fixes it.

Hello Kaleab,
Thank you for your fix. At the moment we don't have a process in place for accepting changes automatically. It is OK if I just merge this internally?
Thanks!

Done!


Catch missing imports of internal functions.

As title, gives feedback to user about missing import.
Closes #4195

Looks like this is ready to merge now.


Installation

Currently the documented pip install and install_all.py break for me.
Core installs ok, then when moving on to features:
pip3 install git+https://github.com/sentinel-hub/eo-learn#subdirectory=coregistration
Collecting git+https://github.com/sentinel-hub/eo-learn#subdirectory=coregistration
Cloning https://github.com/sentinel-hub/eo-learn to /tmp/pip-8bt4doir-build
Collecting eo-learn-core (from eo-learn-coregistration==0.1.0)
Could not find a version that satisfies the requirement eo-learn-core (from eo-learn-coregistration==0.1.0) (from versions: )
No matching distribution found for eo-learn-core (from eo-learn-coregistration==0.1.0)
I got it working by cloning the repo and did the typical:
python3 setup.py build
python3 setup.py build install
on each module and it seems to work OK.
Ubuntu 18.04.1 fresh install with updates.

Hi Ben,
thanks for reporting the problem. At the moment we are working on preparing the first stable version of eo-learn. It should be done until some time next week. Then we plan to upload the package and each of the subpackages to PyPI. That will simplify the installation process.

Since the release of eo-learn version 0.3.0 last week it is possible to install the package with pip (instructions). Therefore I am closing this issue.


applicant refactoring

Description :sparkles:
Issues :bug:
Testing :alembic:
Screenshots :camera_flash:
Additional notes :spiral_notepad:

Codecov Report

Merging #140 (ded26a3) into develop (0fa4fd9) will decrease coverage by 58.54%.
The diff coverage is 30.00%.

@@             Coverage Diff              @@
##           develop     #140       +/-   ##
============================================
- Coverage    72.20%   13.66%   -58.55%
============================================
  Files          255       50      -205
  Lines         5217      622     -4595
  Branches       347      114      -233
============================================
- Hits          3767       85     -3682
+ Misses        1386      501      -885
+ Partials        64       36       -28

Impacted Files
Coverage Δ

...ontend/shared/src/components/forms/fields/types.ts
0.00% <0.00%> (ø)

frontend/shared/src/utils/string.utils.ts
0.00% <0.00%> (ø)

frontend/shared/src/components/header/Header.tsx
16.66% <50.00%> (ø)

frontend/shared/src/components/header/useHeader.ts
12.00% <100.00%> (ø)

...tend/kesaseteli/employer/src/hooks/useUserQuery.ts

backend/shared/shared/oidc/views/eauth_views.py

...benefit/applicant/src/hooks/useApplicationQuery.ts

...r/browser-tests/index-page/userActions.testcafe.ts

...teli/employer/src/components/form/SubmitButton.tsx

.../kesaseteli/employer/src/hocs/withAuthRedirect.tsx

... and 176 more

Continue to review full report at Codecov.

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


Regression test for #4208.

Adds a regression test and closes #4208. Somewhere along the way, some other change must have fixed the bug (possibly #4889, #4733, or #4846).

:+1:


Header request insert from context

Component(s)
router
Is your feature request related to a problem? Please describe.
Currently its not possible to insert headers from context in the router, like we see on Apollo. It requires a custom module, but would be great to have this feature in the pure config file.
Describe the solution you'd like
Etc reading user_id from context in config.yaml
version: '1'
headers:
  all: # Rules for all origin requests
    request:
      - insert:
          name: "User-ID"
          from_context: "user_id"

Describe alternatives you've considered
Create a custom plugin/module that supports to read from context and insert the header.
Additional context
No response

Hi @rasmusviben, thanks for opening an issue. Could you elaborate a bit more on your needs? Do you only want to forward UserID? Thanks.

No, its just an example. I have a bunch of headers - 6-7 values that I would like to read from the context and forward as header, like for apollo: https://www.apollographql.com/docs/graphos/routing/header-propagation - see section "Insert header from context".
Currently I can't see thats possible to do with the cosmo-router without writing a custom module?


sorting by stars

Is your feature request related to a problem? Please describe.
No.
Describe the solution you'd like
I'd like a "sort by stars" option, it'd help a lot.
Describe alternatives you've considered
no one.
Additional context
My most starred repo is on the last position:

Thanks for the issue, I will implement this in 4.0.0 version

It came to realize even a little earlier than planned :)


Feature Request: Integrated Terminal

Hi @onivim team.
Thank you for amazing app, i am licensed user :)
Do you plan adding feature "Integrated terminal" like VSCode? I just use this feature very frequently so if this will be implemented would be nice

Yes, it is, but looks like a buggy and not smooth and stable like VSCode, i'd like to see it to be fixed


Refactor: split continuation symbol out of ValDef.

We modify the code generation so that the declaration of the variable $continuation and its initialisation, which uses a match, all happen in a single statement.
We also change the type assigned to the $continuation variable, to be an instance of the inner class, so we can save a lot of the asInstanceOf statements.

we do have the tests but they can't catch everything for now, does it work in runtime for the continuationPluginExample project especially the Main one which has a lot of cases?

we do have the tests but they can't catch everything for now, does it work in runtime for the continuationPluginExample project especially the Main one which has a lot of cases?

I have not tested all cases, but a couple of those seem to be working fine.

okay yes if it works for a couple it should be okay


refactor: put table styling on context

since font sizes and famalies will be needed for doing a proper "hug" calculation, we need to put the styling on the context

@a-m-dev going to skip putting styling on the theme. If anything I think we should put the background stuff on styling instead, since theme is straight from nebula, and we are adding stuff to that. I think I could be good to have a look at together with a more structured context like bengtsson suggested


Getty detangle

closes #16

So for thumbnails, I'm thinking about adding a method to the Translator interface like
def get_media_locations(raw_metadata, local_metadata_filepath=None):

that will return a dict like:
{"thumbnail": {
    "local": "file:///path/to/thumbnail/file.jpg",
    "remote": "http://foo.getty.com/image/13421.jpg"
    }
}

If you give it a local file path, the translator can return the location it expects to find the thumbnail, otherwise it'll try to pull the remote location from the json in raw_metadata.
Then it's up to the writer to read the file, upload to the store, etc.  If the --download_thumbnails flag is set, the writer can try to request the file over http.

Hmm yeah I see the problem. I'm not sure the translator should care about the local thumbnail, though.

Yeah, I'm not too keen on it either.   The other thought I had was that we could define a separate interface for walking through a local dataset, and it could return the path to the raw metadata files and media files.  So you'd have one of those for getty dumps and it would know where to find the local thumbs.

How about mapping remote urls to local paths at download time (after translation)? It's a bit annoying because we don't preserve the directory structure of the remote, but it could work.
Either way, translator shouldn't know about the local file, we swap it in in the stateful writer.

The tricky bit is when we've already got the image from a previous bulk download (as in the getty dumps we've been using).  In the old ingest code I'm just rewriting the local file path from e.g. getty/json/images/A/B/C/D/ABCDEFG.json to getty/downloads/thumb/A/B/C/D/ABCDEFG.jpg  since that's how they're laid out in the dump directory structure.
But that's not really a property of the getty dataset per-se, just our dump creation code, and it doesn't really belong in the translator.  But we need to put that filename rewrite function somewhere, and since it's specific to getty dumps it doesn't really belong in the writer either....
Probably instead of a "directory walker" interface, we should have a "dataset iterator" interface, one instance of which could walk a getty dump (and return local thumbnail paths if present).  Then we could eventually implement iterators that hit a remote API, etc.  That's pretty similar to the split we have in the l-space translator design as well.

Right, so I was thinking that maybe we can adopt a standard pattern for this, but that's probably not something we should fix.
I'm also wondering about the case where we may have multiple images for a particular work (like different views of a statue) or other more complex cases, going up to the IIIF arbitrary canvas case. Hmm.

Yeah, the dataset iterator interface in mc_datasets uses the group_num key to identify images belonging to the same semantic group. Still a rough preliminary interface.

I need to look through mc_datasets some more... maybe we can unify the dataset iterator between the two projects.   For now I've got an iterator interface which yields translated metadata and the locations of local and remote media.  Then the writer will load the media files (or download, if the flag is set), put to the datastore, and stash the refs into the meta.data dict in the Artefact before sending to the transactor.
There's also a process_media step that for now just assumes that media items named thumbnail are images and tries to resize them to 150x150 px.
I tried to make it fairly generic as to what kind of media you might be storing, and how the data is loaded, but like @parkan said we should probably think more deeply about how we want to link to and represent associated media for our records.  But for now, this gets us back where we were before the refactor, with a thumbnail link in meta.data.
  But I'm thinking we'll want to dispatch on the translator id + the args to the ingest command to find the right iterator.   So e.g. you could provide an api key instead of a dump dir to use a different iterator.
The other piece that's still missing in this branch is artist deduplication, but I haven't decided yet how I want to handle that with this design...

I think maybe this is the way to think about this:

The output from translator is a map<k,v> where v can be a simple value, a mediachain object or an asset/external object
Simple values are treated literally
Mediachain objects are idempontently inserted/upserted => yields mediachain/IPLD address
Assets are resolved and processed => yields HTTP/IPFS address
Arbitrary fields can be objects or assets so they shouldn't be referenced by specially named fields, I'm thinking either two dictionaries of field name -> thing form or maybe special values in the graph?
Translator makes no assumptions about order of inserts (other than "dependencies" being inserted first) so writer can spool and reorder all entities first, if desired
Not sure how to specify case-by-case treatment for assets (thumbnail resize)

so maybe something like:
translator_output = {
  "canonical":  {
    "__mediachain_object__": true,
    "type": "artefact",
    "meta": {
      "data": {
        "thumbnail": {
          "__mediachain_asset__": true,
          "uri": "http://foo.bar/thumb.jpg"
      }
    },
  },
  "chain": [
    {
      "__mediachain_object__": true,
      "type": "artefactCreatedBy",
      "meta": {},
      "entity": {
        "__mediachain_object__": true,
        "type": "entity",
        "meta": { "data": { "name": "Mr. Snrub" } }
   }
  ]
}

and the writer will basically do a depth-first traversal of each mediachain object and send anything with __mediachain_object__ to the transactor, and __mediachain_asset__ to the datastore, replacing the inline dicts with multihash refs...
It would have to insert the main canonical first, then it could process each cell in the chain sequentially, setting its ref to the ref of the main canonical.

lgtm 👍

@yusefnapora let's rebase this on master

good call

Added parallel ingestion script


Tooltip count and nodes on screen don't match

Browser: Chrome
WC: f326ded1
Orchestrator: AWS ECS

Filter by Services.
Select 'Show Unmanaged'
Mouse over the tooltip: you'll notice that it says 9 nodes 18 connections (sometimes but of these increment by one).
But the display only shows 8 nodes (and I didn't count the connections).

View the tooltip from this recording:
http://recordit.co/KEJK0cEHtd

sometimes but of these increment by one

What do you mean?

But the display only shows 8 nodes

Uhm, I think we may not be showing unconnected nodes, although this doesn't make sense for services.

I wasn't quite clear on what the tooltip was indicating.  I just noticed that the node count in the tooltip doesn't match the number of nodes on the screen.  I'll check Kubernetes to see if it shows the same discrepancy.

It just seems to be the case for ECS and Services (it is filtered on 'Show Unmanaged'). Is it counting an additional node that is not displayed in Scope in this view?

sometimes these increment by one

I am not seeing this behaviour.  When I first saw this, the number in the tooltip would increment and decrement occassionally (maybe parts of the cluster was still spinning up?)


Can't copy the values of debugging elements such as exception messages

From @CarlosTorrecillas on August 5, 2016 8:24
Environment data
dotnet --info output:
.NET Command Line Tools (1.0.0-preview2-003121)
Product Information:
Version:            1.0.0-preview2-003121
Commit SHA-1 hash:  1e9d529bc5
Runtime Environment:
OS Name:     Mac OS X
OS Version:  10.11
OS Platform: Darwin
RID:         osx.10.11-x64
VS Code version: 1.3.1
C# Extension version: 1.3
Steps to reproduce

Create a .NET Console app
Add the code to throw an exception
On the debugging section try copy the value of either the message or the stacktrace

Expected  behavior

I would expect the value to be copied in the clipboard

Actual behavior

I get the message "error CS1012: Too many characters in character literal"

Copied from original issue: OmniSharp/omnisharp-vscode#639

Ive been told to raise the issue in the two repos so I don't know where it belongs to

Sounds like a problem of the C# debug extension because it generates the "error CS1012:..."

@chuckries saw your comment on https://github.com/OmniSharp/omnisharp-vscode/issues/639. So what exactly is the problem with VS Code that results in the CS1012 error on your side?

VSCode will try to evaluate the variable before it copies it's value to the clipboard here
This was originally done because the node debugger cuts off long string value unless they are evaluated.
So the bottom line issue here is that the debug adapter can not evalute the long string that is trying to be copied over.
Not sure what we can do on the vscode side here.
@chuckries @weinand suggestions welcome

I'll take a look at this from the debugger side. I didn't realize an evaluation was performed on copy.

I think we need some way to opt out doing an evaluation on 'Copy Value' and just hand back the value sitting in the UI. As it stands, for copying Message out of $exception in the following screenshot:

We are asked to evaluate the expression $exception [Exception]['Message [string]'], which is completely meaningless to us. The error being seen when pasting is coming from the compiler failing to evaluate. We have the ability to evaluate ($exception).Message, but I'm not sure how we could manipulate the evaluation string into that. As it stands we can't even copy an int value out of the locals window because the evaluation string we are given includes the type annotation: i [int]
@gregg-miskelly @caslan @wesrupert for visibility. Wes did the type annotating work on our side. I'm not sure if this is something we need to scrape back out or if VS Code can give us the identifier without providing the type annotation.

Another option would to pass a token to the variable that needs to be re-evaluated rather than sending a raw string. My understanding is that this token approach is used other places in the debugger UI.

If VS Code wants to perform this evaluation, the best method I see for giving us the context would be to give us the same data as we get for the setVariable command, i.e. a context (stackframe or variablesReference) and the name, and we can handle it from there.

Seeing as the underlying behavior is from a desire to get a "better" string out of the value, it would also be nice to have a separate context for this evaluate command, e.g. "context": "copy". Looks like it currently doesn't send a context at all, as trying to copy the args local in a sample app gives the following command: evaluate: {"expression":"args [string[]]","frameId":1000}.

Passing a "context":"copy" in this case makes sense to me.
@weinand opinion?

Personally I don't think 'context' is enough -- VS Code shouldn't attempt to concatenate children together to build the name of an expression as this isn't language-agnostic. As Wes suggested, I think the clean way to handle this problem is to add a new request (GetFullValue?) which works the same as setVariable. For debugAdapters that don't support GetFullValue, VS Code should default to copying the original value.

Assigning first to @weinand to investigate how to solve this on the debug protocl level, and once we come to a conclusion I can implement it on the vscode side.

In the October release we've introduced a new attribute evaluateName on the Variable type (see https://github.com/Microsoft/vscode-debugadapter-node/issues/73).
This can be used in an evaluateRequest to copy the value of debugging elements to the clipboard.
@isidorn please use this new (optional) attribute when copying values to the clipboard.

Currently if the evaluateName is passed we will respect it on the vscode. If it is not passed we will still use our ugly heuristic for figuring out the evaluateName here
I propose that in October we support both but in the november release we drop the support for not specifiying the evaluateName. In that case if the evaluateName is not passed we will simply use the name of the variable. No critical feature is dependent on this and I would like to get rid of that ugly code thus I am all in for droping this in november.

@weinand is it fine if I drop our ugly heuristic for figuring out the evalute name of a variable this milestone. This will break the following scenarios for adapters that do not support evaluateName:

adding a child element to a watch expression via context menu
copying a value of a child element via context menu

I am +1 for dropping it since this is not a major breakage imho and each adapter can start supporting evaluateName to prevent this.

Since we did not even mention evaluateName in the October release notes, we cannot drop the fallback strategy in November. Neither node-debug nor node-debug2 have adopted this and their adoption is not yet on the November plan.

@weinand makes perfect sense. In the future let me know when node-debug or node-debug2 implement this so we can drop the hack.

I've created this issue for the adoption work.


Exit with 111 if Marathon could not bind to address.

Summary:
This should ease debugging issues such as COPS-4623.

ping @alenkacz and @meichstedt

Ok, I guess we should drop it then unless @timcharper has some ideas about the dependency injection there.

I've found a way to get the exception from the service.
While investigating, I've also found that Jetty by default has the flag "reuseAddress" to true, which means I could start two marathons on the same port without failure. Or a simple python http webserver (python -m SimpleHTTPServer 8080), and then a marathon.
We might want to set that flag to false, to ensure marathon isn't binding to any already used port. I assume DC/OS usually takes care of that, but still... Looks a bit weird
https://stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and-so-reuseport-how-do-they-differ-do-they-mean-t


Chunking Ignores Images

Description:
The current chunking strategies in the Unstructured library do not handle images properly. When encountering an image element, the chunker simply discards it, resulting in the loss of image data. This is a significant limitation for documents that contain important images.
Steps to Reproduce:
Partition a document that contains images.
Apply a chunking strategy (e.g., "basic" or "by_title") to the partitioned elements.
Observe that the images are missing from the resulting chunks.
Expected Behavior:
Chunking strategies should preserve images and incorporate them into chunks in a meaningful way. This could involve:
Chunking based on image size.
Grouping images with related text elements.
Creating special chunk types for images.
Providing configuration options for users to specify how they want images to be handled.
Workarounds:
Currently, the following workarounds can be used:
Pre-process documents to extract images before chunking.
Post-process chunks to re-insert images based on metadata.
(see below)
However, these workarounds are not ideal and require additional effort.
Request:
Implement a solution to preserve images during chunking.

It's also possible to make this optional with a new parameter in all chunking methods.
Additional Information:
Here is my current workaround which can also be used to create a test for this:
def workaround_chunk(
    elements,
    max_characters=4000,
    multipage_sections=True,
    new_after_n_chars=None,
    combine_text_under_n_chars=3000,
    overlap=0,
    overlap_all=False,
    isolate_chunk_types=["Image", "Table"],
    base_method="chunk_by_title"):

    chunks = []
    elements_for_chunking = []
    for i in range(0, len(elements)):
        element_dict = elements[i].to_dict()
        if element_dict["type"] in isolate_chunk_types or i == len(elements) - 1:
            if base_method == "basic":
                new_chunks = chunk_elements(
                    elements= elements_for_chunking,
                    max_characters=max_characters,
                    combine_text_under_n_chars=combine_text_under_n_chars,
                    overlap=0,
                    overlap_all=overlap_all,
                    new_after_n_chars=new_after_n_chars)
            elif base_method == "chunk_by_title":
                new_chunks = chunk_by_title(
                    elements= elements_for_chunking,
                    max_characters=max_characters,
                    combine_text_under_n_chars=combine_text_under_n_chars,
                    overlap=0,
                    overlap_all=overlap_all,
                    new_after_n_chars=new_after_n_chars,
                    multipage_sections=multipage_sections
                )
            # append to chunks the items in new chunks, the result should be a flat list of elements
            chunks = chunks + new_chunks
            elements_for_chunking = []
            chunks.append(elements[i])

        else:
            elements_for_chunking.append(elements[i])

    return chunks

A possible solution I think is to create a new ImagePreChunk and ImageChunk classes similair to PreChunkTable and TableChunk. Implementing it this way will also cover the rare cases of images with long texts within them.

@asakinory recently the .metadata.orig_elements field was added to metadata for chunks. This allows perhaps more convenient post-processing of chunks to So you can post-process chunks to process them in whatever way makes sense for your use-case.
For example, you can retrieve whatever Image elements were incorporated into a chunk with the expression:
chunk_images = [e for e in chunk.orig_elements if type(e).__name__ == "Image"]

Any text extracted from the image using OCR will appear in the chunk.text in element-stream order (document order generally speaking).
Let us know how you go with that and we can consider further steps if necessary :)


Re-think interactivity of list widgets

Right now list widgets are not interactive. The design team proposed that clicking on a list item should pan the map to the feature that was clicked. I think it makes sense to have a list of categories (with no aggregation/progress bar, etc.) that you can use to show/hide features on the map (for example: a list of states).
cc/ @saleiva

Thinking on it.

Any thoughts on this @saleiva?

Yep, give me a few days
On Nov 2, 2015 10:58 AM, "Pablo Alonso"<EMAIL_ADDRESS>wrote:

Any thoughts on this @saleiva https://github.com/saleiva?
—
Reply to this email directly or view it on GitHub
https://github.com/CartoDB/cartodb.js/issues/745#issuecomment-152974782.

@alonsogarciapablo @xavijam let me know if you need the sketch file

Hey! Not sure what's the status of this. @saleiva did you decide how this is going to work?

:)


It seems there are two docs in parallel?

If we go to https://wilix-team.github.io/iohook/usage.html we will see targets:
"targets": [
    "node-59",
    "electron-57"
  ],

But in https://github.com/wilix-team/iohook/blob/master/docs/usage.md we can see:
"targets": [
    "node-72",
    "electron-85"
  ],

Seems first link leads to outdated docs, while there is an actual version.

Yes. It was fixed a few days ago. Closing it now


Transfer workflows from workflows repo

Transferred the doc-related GitHub actions from the workflows repo. Part of issue #448 in stock synthesis repo.

@e-gugliotti-NOAA we should probably redo this one with git-filter-repo as well


Think about making multimodal as first class citizen in the protobuf

Context
We want docarray to fully support multi modal features. ATM we have the dataclass feature that allow to do this easily. Nevertheless this multiodal feature is not first class citizen. Our protobuf still does not offer the same flexibility as our dataclass. There are two layers, protobuf with chunk and content and dataclass that map the multi modal feature to the protobuf definition.
We should remove the extra layer, make multi modal first class citizen in the protobuf.
This will make the goal of docarray for multi modal clearer  + it will be easier for anybody to ship an interface for docarray in other programming language.

Please make sure to involve @girishc13 and @dongxiang123 to make sure docarray can support every pattern for vector/traditional search and ranking.

the refactoring has been kickoff https://github.com/docarray/docarray/tree/feat-rewrite-v2


scss/double-slash-comment-whitespace-inside

Whether this rule can be automatically fixed？

This should be reported in the https://github.com/stylelint-scss/stylelint-scss repo instead.


Ability to open .py files directly in the Notebook Editor

Feature: Notebook Editor

Description
Allow opening a .py file, optionally with percent annotations, directly in the notebook editor. This allows a notebook like experience for percent files, instead of the only option available currently which is running the cells in the interactive window. This is also preferable to converting the the file .ipynb before hand.
Naturally, cell outputs would be either discarded or exported to an .ipynb explicitly.
This would mimic the behavior of the Jupyter Notebook web interface when opening .py files.
Microsoft Data Science for VS Code Engineering Team: @rchiodo, @IanMatthewHuff, @DavidKutu, @DonJayamanne, @greazer, @joyceerhl

Thanks for the feedback! However, we don't have plans on adding this functionality at this time.


Make heatmap colors configurable

This allows all heatmap colors to be configured (even custom themes).

I was going to allow users to use rgb as well, but that would mean hex-codes would need the # prefix, which makes it a comment in INI format. 🙁
It could still be done, but it would increase complexity a little.

@jolheiser hex colorbcode is fine as long as it is written somehow in the docs

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@f05cd3e). Click here to learn what that means.
The diff coverage is 66.66%.

@@            Coverage Diff            @@
##             master    #8857   +/-   ##
=========================================
  Coverage          ?   41.26%
=========================================
  Files             ?      544
  Lines             ?    69873
  Branches          ?        0
=========================================
  Hits              ?    28833
  Misses            ?    37352
  Partials          ?     3688

Impacted Files
Coverage Δ

modules/templates/helper.go
48.56% <66.66%> (ø)

Continue to review full report at Codecov.

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

Cant test itvat the moment boot it looks good!

Please also remove the colors in the css and update the docs, to make it clear where to change these.

The colors are still needed in CSS, as those would be the fallback.
And I did update the customization docs, was there another place to change it?

The colors are still needed in CSS, as those would be the fallback.

I would prefer having that only as default option in the config

I didn't add anything to the sample ini since these are all optional and the keys change (somewhat) dynamically based on the theme names.

But wouldn't it make sense to have defaults for the light and dark theme?

If the colors are completely converted to config values, we lose some of the niceties less provides in favor of completely hard-coded default values.
My intention was to let admins override if they want, but still have default values provided through less/CSS.
If default values are hard-coded, users who copy the sample ini wholesale will need to modify it if colors change.
I'm not against hard-coding it, but this implementation allows overriding if wanted, and otherwise doesn't modify any existing styles.

Imho this is not needed, this could be overrrided with custom css file, no need to add additional settings

Imho this is not needed, this could be overrrided with custom css file, no need to add additional settings

That's a good point (admittedly I never thought of that)
I suppose then the only advantage is not messing with a custom/header.

It could be nice if there was an option to automatically load css/js files that are in a certain folder(s) rather than needing to modifying a template to include them, as you then loose out on any automatic update of that template in the future.

custom/header is actually blank by default, I believe its intended purpose is things like this.
I completely forgot it existed, though.

ah right I was confusing base/header|footer and also forgot those.

custom/header is actually blank by default, I believe its intended purpose is things like this.
I completely forgot it existed, though.

but it would make sence to add a description to https://docs.gitea.io/en-us/customizing-gitea/
how to ONLY set/update heatmap (with a smal example)


RangeError: Maximum call stack size exceeded

 daGrev.is git:(master) ✗ hux -r

firefox opening.

At index.hux
Begin record
Type q to quit, l for taking a screenshot and marking a live playback point til next screenshot, and anything else to take a normal screenshot.
>
1 screenshot recorded.
> q

Don't move! Simulating the recording now...

firefox opening.

At index.hux
  Taking screenshot firefox-1.png

RangeError: Maximum call stack size exceeded

It happens to me too, @chenglou


spec file: Add "Conflicts:" to sailfishos-chum-gui

… in order to prevent any of the three packages {sailfishos-chum|sailfishos-chum-testing|sailfishos-chum-gui} to be installed concurrently.
After SailfishOS:Chum GUI application commit 1cce90a all three RPMs also Provides: sailfishos-chum-repository, so this can be used to check if any SailfishOS:Chum repository (either the regular or the testing one) is configured on a device.

Linked to https://github.com/sailfishos-chum/sailfishos-chum-gui/pull/115


Issues running the kernel

After installing on my Mac, I cant get the hass-pyscript-jupyter to work
Running 'jupyter kernelspec list':
[ListKernelSpecs] WARNING | Native kernel (python3) is not available
[ListKernelSpecs] WARNING | Native kernel (python3) is not available
Available kernels:
  pyscript    /usr/local/share/jupyter/kernels/pyscript

Running 'jupyter pyscript info':
hass_pyscript_kernel version 1.0.0 installed
Kernel pyscript installed in /usr/local/share/jupyter/kernels/pyscript
Config settings from /usr/local/share/jupyter/kernels/pyscript/pyscript.conf:
    hass_host = <IP_ADDRESS>
    hass_url = http://<IP_ADDRESS>:8123
    hass_token = 6MTYxNzE5MDI1OSwiZXhwIjoxOTMyNTUwyoPnHd8vvF0upJAKRCzsek
    hass_proxy = None

If I run 'juptyer notebook', all seems ok:
[I 2021-03-31 13:42:38.768 LabApp] JupyterLab extension loaded from /usr/local/Cellar/jupyterlab/3.0.12/libexec/lib/python3.9/site-packages/jupyterlab
[I 2021-03-31 13:42:38.769 LabApp] JupyterLab application directory is /usr/local/Cellar/jupyterlab/3.0.12/libexec/share/jupyter/lab
[I 13:42:38.776 NotebookApp] Serving notebooks from local directory: /Users/denver
[I 13:42:38.777 NotebookApp] Jupyter Notebook 6.2.0 is running at:
[I 13:42:38.777 NotebookApp] http://localhost:8888/?token=8c639d693d8f0
[I 13:42:38.777 NotebookApp]  or http://<IP_ADDRESS>:8888/?token=8c639d693d8f0
[I 13:42:38.777 NotebookApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation).
[C 13:42:38.781 NotebookApp]

    To access the notebook, open this file in a browser:
        file:///Users/denver/Library/Jupyter/runtime/nbserver-4284-open.html
    Or copy and paste one of these URLs:
        http://localhost:8888/?token=8c639d693d8f0
     or http://<IP_ADDRESS>:8888/?token=8c639d693d8f0

If I then select 'hass pyscript' in Jupyter notebooks 'New' menu I get:
[I 18:46:35.274 NotebookApp] Creating new notebook in
[I 18:46:36.394 NotebookApp] Kernel started: 5f607b3a-3390-4b7c-bc5b-939c3f47782d, name: pyscript
[W 18:46:36.442 NotebookApp] 404 GET /nbextensions/widgets/notebook/js/extension.js?v=20210331184622 (::1) 28.070000ms referer=http://localhost:8888/notebooks/Untitled4.ipynb?kernel_name=pyscript
/usr/local/Cellar/jupyterlab/3.0.12/libexec/bin/python3.9: No module named hass_pyscript_kernel
[I 18:46:39.380 NotebookApp] KernelRestarter: restarting kernel (1/5), new random ports
/usr/local/Cellar/jupyterlab/3.0.12/libexec/bin/python3.9: No module named hass_pyscript_kernel
[I 18:46:42.389 NotebookApp] KernelRestarter: restarting kernel (2/5), new random ports
/usr/local/Cellar/jupyterlab/3.0.12/libexec/bin/python3.9: No module named hass_pyscript_kernel
[I 18:46:45.400 NotebookApp] KernelRestarter: restarting kernel (3/5), new random ports
/usr/local/Cellar/jupyterlab/3.0.12/libexec/bin/python3.9: No module named hass_pyscript_kernel
[I 18:46:48.413 NotebookApp] KernelRestarter: restarting kernel (4/5), new random ports
/usr/local/Cellar/jupyterlab/3.0.12/libexec/bin/python3.9: No module named hass_pyscript_kernel
[W 18:46:51.422 NotebookApp] KernelRestarter: restart failed
[W 18:46:51.423 NotebookApp] Kernel 5f607b3a-3390-4b7c-bc5b-939c3f47782d died, removing from map.
[W 18:47:36.469 NotebookApp] Timeout waiting for kernel_info reply from 5f607b3a-3390-4b7c-bc5b-939c3f47782d
[E 18:47:36.472 NotebookApp] Error opening stream: HTTP 404: Not Found (Kernel does not exist: 5f607b3a-3390-4b7c-bc5b-939c3f47782d)

Any ideas where to go from here or what to try please.

Came across the same problem. The kernelspec refers to python as the python binary to use, but it's not using the one which the shell points to when in a virtualenv. Not sure if this is a problem with jupyter or with this tool.
This can be 'fixed' by setting the binary to the one which has access to the hass_pyscript_kernel module.

Run jupyter kernelspec list
Open the file kernel.json in the folder which is listed next to pyscript in the previous command's output
Change python in argv to whatever comes out of which python when running that in your virtualenv

On to the next problem, connection refused... 😞

Any update on this? I also have this problem. HTTP 400, 401 and 403s


Improve rule coding, including for \sqrt.

Rule widths (overline, underline, fraction, sqrt) actually scale
with the current font size in AMS-TeX. Implement that. (Sqrt is
a special case: the rule width depends on the font size of the
surd.)
Change the CSS coding for rules. The old, complex coding prevented
variable-width lines and may have contributed to issues like #696.
Its purpose, according to 0a3a2271f4b207feb14fe366cb4e72e48d79dd93,
was IE8 support; but KaTeX no longer supports IE8.

Example difference, using \frac towers (an example from @ronkok). Before:

After:

Note that the rules are less unruly.

@kohler I'll review this evening.  The screenshots look good.

I'll review this evening

I was overly optimistic.  I'll try to get to it this weekend.

The \sqrt rule looks a lot better.  I've found the smaller font sizes to be more troublesome.  Here are some renderings using 12px sized font.
Safari

Safari @ 400%

Chrome

Chrome @ 400%

I tried out some other font sizes.  18px was the worst.
Safari @ 400%

Chrome @ 400%

My guess is that the \sqrt rule is a bit to high on Chrome for 18px and is getting clipped.  This also happens at 11px and might happen for other font sizes.  I zoomed to 100% just in case the zoom was causing an issue and the rule was still missing.  This should be fixed before merging.

Hi @kevinbarabash, I rebased on top of the current master & pushed. I cannot replicate a missing \sqrt rule on Chrome, with either 11px or 18px, at any mag. Here's the diff I made to main.css. Version 59.0.3071.115 (Official Build) (64-bit) on Mac. Can you help me replicate? There's no clipping in the CSS coding, so your proposed explanation doesn't make sense to me.
--- a/static/main.css
+++ b/static/main.css
@@ -1,7 +1,7 @@
 body {
     margin: 0px;
     padding: 0px;
-    font-size: 72px;
+    font-size: 11px;
 }

 #input {

I'm running a dev version of Chrome.  It said it was ready to upgrade so I upgraded and the problem went away.

When a nucleus has both sub & sub, the defaultRuleThickness is part of the calculation involved in separating the subscript from the superscript. The screenshotter subscript positions changed in scriptscript mode because now defaultRuleThickness is relatively larger for script and scriptscript fonts—e.g., the script defaultRuleThickness is 0.049em, not 0.04em.
The previous KaTeX implementation differed. It used 0.04em as the thickness for purposes of separating sup+sub, but it should have used 0.04em base-size units for consistency with the TeXbook (since previously all rules were 0.04em base-size units thick). Instead it used 0.04em script-size units (in scriptscript mode).

@kohler thanks for the PR.  The updated horizontal rules look great.


[SPARK-50176][CONNECT][3.5] Disallow reattaching after the session is closed

What changes were proposed in this pull request?

Disallow cursors from reattaching corresponding ExecuteHolders after the session is closed.
In order to prevent a session with a long-running query from being closed, the session is always accessed when reattaching.
https://github.com/apache/spark/pull/44670 resolves this issue in Spark 4.0.0.
Why are the changes needed?

SPARK-50176. Sessions with long running queries are susceptible to cache eviction, causing trouble when the client tries to reattach to the execution.
Does this PR introduce any user-facing change?

No.
How was this patch tested?

org.apache.spark.sql.connect.execution.ReattachableExecuteSuite
Was this patch authored or co-authored using generative AI tooling?

No.

Hi @dongjoon-hyun , thank you for looking into the PR.
In Spark 4.0.0, https://github.com/apache/spark/pull/44670 resolved a similar issue a while ago, but the author did not back-port the change. Unfortunately, the change is substantially different from mine, because the change relies on new features in Spark 4.0.0 such as the session tombstone container, thus a clean cherry-pick wouldn't be possible.
Therefore, I'll just mention https://github.com/apache/spark/pull/44670 in the PR message.

Merged to branch-3.5.

@HyukjinKwon @dongjoon-hyun It seems that the necessary testing pipeline was not triggered when this pr was merged:

https://github.com/apache/spark/actions/runs/11623531226/job/32370719419

It seems that this pull request caused the failure of the daily test:

https://github.com/apache/spark/actions/runs/11628383197
https://github.com/apache/spark/actions/runs/11642182106
https://github.com/apache/spark/actions/runs/11650793794

This issue can also be reproduced in local testing:
git reset --hard 4205b795f893ef51441250cd48c094655ec42193 // before this one: [SPARK-50155][3.5] Move scala and java files to their default folders
build/sbt clean "connect/testOnly org.apache.spark.sql.connect.execution.ReattachableExecuteSuite"

[info] ReattachableExecuteSuite:
[info] - reattach after initial RPC ends (2 seconds, 209 milliseconds)
[info] - raw interrupted RPC results in INVALID_CURSOR.DISCONNECTED error (301 milliseconds)
[info] - raw new RPC interrupts previous RPC with INVALID_CURSOR.DISCONNECTED error (40 milliseconds)
[info] - client INVALID_CURSOR.DISCONNECTED error is retried when rpc sender gets interrupted (283 milliseconds)
[info] - client INVALID_CURSOR.DISCONNECTED error is retried when other RPC preempts this one (435 milliseconds)
[info] - abandoned query gets INVALID_HANDLE.OPERATION_ABANDONED error (37 milliseconds)
[info] - client releases responses directly after consuming them (289 milliseconds)
[info] - server releases responses automatically when client moves ahead (398 milliseconds)
[info] - big query (1 second, 17 milliseconds)
[info] - big query and slow client (7 seconds, 232 milliseconds)
[info] - big query with frequent reattach (966 milliseconds)
[info] - big query with frequent reattach and slow client (7 seconds, 703 milliseconds)
[info] - long sleeping query (10 seconds, 145 milliseconds)
[info] - Async cleanup callback gets called after the execution is closed (47 milliseconds)
[info] Run completed in 34 seconds, 114 milliseconds.
[info] Total number of tests run: 14
[info] Suites: completed 1, aborted 0
[info] Tests: succeeded 14, failed 0, canceled 0, ignored 0, pending 0
[info] All tests passed.

git reset --hard 0229c0ea451c953e78cd273d9de2bc05962470a5 // this one: [SPARK-50176][CONNECT][3.5] Disallow reattaching after the session is closed
build/sbt clean "connect/testOnly org.apache.spark.sql.connect.execution.ReattachableExecuteSuite"

[info] - long sleeping query *** FAILED *** (67 milliseconds)
[info]   org.apache.spark.sql.AnalysisException: [UNRESOLVED_ROUTINE] Cannot resolve function `sleep` on search path [`system`.`builtin`, `system`.`session`, `spark_catalog`.`default`].; line 1 pos 7
[info]   at org.apache.spark.sql.connect.client.GrpcExceptionConverter$.$anonfun$errorFactory$2(GrpcExceptionConverter.scala:79)
[info]   at org.apache.spark.sql.connect.client.GrpcExceptionConverter$.$anonfun$errorInfoToThrowable$2(GrpcExceptionConverter.scala:106)
[info]   at scala.Option.map(Option.scala:230)
[info]   at org.apache.spark.sql.connect.client.GrpcExceptionConverter$.errorInfoToThrowable(GrpcExceptionConverter.scala:104)
[info]   at org.apache.spark.sql.connect.client.GrpcExceptionConverter$.toThrowable(GrpcExceptionConverter.scala:122)
[info]   at org.apache.spark.sql.connect.client.GrpcExceptionConverter$.convert(GrpcExceptionConverter.scala:41)
[info]   at org.apache.spark.sql.connect.client.GrpcExceptionConverter$$anon$1.hasNext(GrpcExceptionConverter.scala:52)
[info]   at org.apache.spark.sql.connect.SparkConnectServerTest.$anonfun$runQuery$2(SparkConnectServerTest.scala:235)
[info]   at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
[info]   at org.scalatest.enablers.Timed$$anon$1.timeoutAfter(Timed.scala:127)
[info]   at org.scalatest.concurrent.TimeLimits$.failAfterImpl(TimeLimits.scala:282)
[info]   at org.scalatest.concurrent.TimeLimits.failAfter(TimeLimits.scala:231)
[info]   at org.scalatest.concurrent.TimeLimits.failAfter$(TimeLimits.scala:230)
[info]   at org.scalatest.concurrent.TimeLimits$.failAfter(TimeLimits.scala:274)
[info]   at org.apache.spark.sql.connect.SparkConnectServerTest.$anonfun$runQuery$1(SparkConnectServerTest.scala:230)
[info]   at org.apache.spark.sql.connect.SparkConnectServerTest.$anonfun$runQuery$1$adapted(SparkConnectServerTest.scala:229)
[info]   at org.apache.spark.sql.connect.SparkConnectServerTest.withClient(SparkConnectServerTest.scala:199)
[info]   at org.apache.spark.sql.connect.SparkConnectServerTest.withClient$(SparkConnectServerTest.scala:191)
[info]   at org.apache.spark.sql.connect.execution.ReattachableExecuteSuite.withClient(ReattachableExecuteSuite.scala:30)
[info]   at org.apache.spark.sql.connect.SparkConnectServerTest.runQuery(SparkConnectServerTest.scala:229)
[info]   at org.apache.spark.sql.connect.SparkConnectServerTest.runQuery$(SparkConnectServerTest.scala:228)
[info]   at org.apache.spark.sql.connect.execution.ReattachableExecuteSuite.runQuery(ReattachableExecuteSuite.scala:30)
[info]   at org.apache.spark.sql.connect.SparkConnectServerTest.runQuery(SparkConnectServerTest.scala:259)
[info]   at org.apache.spark.sql.connect.SparkConnectServerTest.runQuery$(SparkConnectServerTest.scala:257)
[info]   at org.apache.spark.sql.connect.execution.ReattachableExecuteSuite.runQuery(ReattachableExecuteSuite.scala:30)
[info]   at org.apache.spark.sql.connect.execution.ReattachableExecuteSuite.$anonfun$new$44(ReattachableExecuteSuite.scala:373)
[info]   at org.apache.spark.SparkFunSuite.withSparkEnvConfs(SparkFunSuite.scala:320)
[info]   at org.apache.spark.sql.connect.execution.ReattachableExecuteSuite.$anonfun$new$43(ReattachableExecuteSuite.scala:372)
[info]   at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
[info]   at org.scalatest.enablers.Timed$$anon$1.timeoutAfter(Timed.scala:127)
[info]   at org.scalatest.concurrent.TimeLimits$.failAfterImpl(TimeLimits.scala:282)
[info]   at org.scalatest.concurrent.TimeLimits.failAfter(TimeLimits.scala:231)
[info]   at org.scalatest.concurrent.TimeLimits.failAfter$(TimeLimits.scala:230)
[info]   at org.apache.spark.SparkFunSuite.failAfter(SparkFunSuite.scala:69)
[info]   at org.apache.spark.SparkFunSuite.$anonfun$test$2(SparkFunSuite.scala:155)
[info]   at org.scalatest.OutcomeOf.outcomeOf(OutcomeOf.scala:85)
[info]   at org.scalatest.OutcomeOf.outcomeOf$(OutcomeOf.scala:83)
[info]   at org.scalatest.OutcomeOf$.outcomeOf(OutcomeOf.scala:104)
[info]   at org.scalatest.Transformer.apply(Transformer.scala:22)
[info]   at org.scalatest.Transformer.apply(Transformer.scala:20)
[info]   at org.scalatest.funsuite.AnyFunSuiteLike$$anon$1.apply(AnyFunSuiteLike.scala:226)
[info]   at org.apache.spark.SparkFunSuite.withFixture(SparkFunSuite.scala:227)
[info]   at org.scalatest.funsuite.AnyFunSuiteLike.invokeWithFixture$1(AnyFunSuiteLike.scala:224)
[info]   at org.scalatest.funsuite.AnyFunSuiteLike.$anonfun$runTest$1(AnyFunSuiteLike.scala:236)
[info]   at org.scalatest.SuperEngine.runTestImpl(Engine.scala:306)
[info]   at org.scalatest.funsuite.AnyFunSuiteLike.runTest(AnyFunSuiteLike.scala:236)
[info]   at org.scalatest.funsuite.AnyFunSuiteLike.runTest$(AnyFunSuiteLike.scala:218)
[info]   at org.apache.spark.SparkFunSuite.org$scalatest$BeforeAndAfterEach$$super$runTest(SparkFunSuite.scala:69)
[info]   at org.scalatest.BeforeAndAfterEach.runTest(BeforeAndAfterEach.scala:234)
[info]   at org.scalatest.BeforeAndAfterEach.runTest$(BeforeAndAfterEach.scala:227)
[info]   at org.apache.spark.SparkFunSuite.runTest(SparkFunSuite.scala:69)
[info]   at org.scalatest.funsuite.AnyFunSuiteLike.$anonfun$runTests$1(AnyFunSuiteLike.scala:269)
[info]   at org.scalatest.SuperEngine.$anonfun$runTestsInBranch$1(Engine.scala:413)
[info]   at scala.collection.immutable.List.foreach(List.scala:431)
[info]   at org.scalatest.SuperEngine.traverseSubNodes$1(Engine.scala:401)
[info]   at org.scalatest.SuperEngine.runTestsInBranch(Engine.scala:396)
[info]   at org.scalatest.SuperEngine.runTestsImpl(Engine.scala:475)
[info]   at org.scalatest.funsuite.AnyFunSuiteLike.runTests(AnyFunSuiteLike.scala:269)
[info]   at org.scalatest.funsuite.AnyFunSuiteLike.runTests$(AnyFunSuiteLike.scala:268)
[info]   at org.scalatest.funsuite.AnyFunSuite.runTests(AnyFunSuite.scala:1564)
[info]   at org.scalatest.Suite.run(Suite.scala:1114)
[info]   at org.scalatest.Suite.run$(Suite.scala:1096)
[info]   at org.scalatest.funsuite.AnyFunSuite.org$scalatest$funsuite$AnyFunSuiteLike$$super$run(AnyFunSuite.scala:1564)
[info]   at org.scalatest.funsuite.AnyFunSuiteLike.$anonfun$run$1(AnyFunSuiteLike.scala:273)
[info]   at org.scalatest.SuperEngine.runImpl(Engine.scala:535)
[info]   at org.scalatest.funsuite.AnyFunSuiteLike.run(AnyFunSuiteLike.scala:273)
[info]   at org.scalatest.funsuite.AnyFunSuiteLike.run$(AnyFunSuiteLike.scala:272)
[info]   at org.apache.spark.SparkFunSuite.org$scalatest$BeforeAndAfterAll$$super$run(SparkFunSuite.scala:69)
[info]   at org.scalatest.BeforeAndAfterAll.liftedTree1$1(BeforeAndAfterAll.scala:213)
[info]   at org.scalatest.BeforeAndAfterAll.run(BeforeAndAfterAll.scala:210)
[info]   at org.scalatest.BeforeAndAfterAll.run$(BeforeAndAfterAll.scala:208)
[info]   at org.apache.spark.SparkFunSuite.run(SparkFunSuite.scala:69)
[info]   at org.scalatest.tools.Framework.org$scalatest$tools$Framework$$runSuite(Framework.scala:321)
[info]   at org.scalatest.tools.Framework$ScalaTestTask.execute(Framework.scala:517)
[info]   at sbt.ForkMain$Run.lambda$runTest$1(ForkMain.java:414)
[info]   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[info]   at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[info]   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[info]   at java.lang.Thread.run(Thread.java:750)
[info] - Async cleanup callback gets called after the execution is closed (44 milliseconds)
[info] Run completed in 25 seconds, 431 milliseconds.
[info] Total number of tests run: 15
[info] Suites: completed 1, aborted 0
[info] Tests: succeeded 14, failed 1, canceled 0, ignored 0, pending 0
[info] *** 1 TEST FAILED ***
[error] Failed tests:
[error] 	org.apache.spark.sql.connect.execution.ReattachableExecuteSuite

Can you fix this issue? @changgyoopark-db

https://github.com/apache/spark/pull/48745 -> this should fix the issue - TEST ONLY.


refresh graphs every minute

Wrap graphing logic in a function that's called recursively every minute. The recursive call could be problematic. Maybe have some way to clear the setTimeout after some time?

What do you think of doing something like  setTimeout( function() { location.reload(); }, 60 * 1000 ); instead of the recursive call?

That's a much simpler solution. Even if the refresh interval is every 30s, I don't see a drawback in reloading the entire page.

It would be interesting to have the refresh interval be configurable, but I don't have any strong feelings about either a 30s or 60s refresh period.

Looks great, thanks for this!


Not working with IP address hosts

This is working from the command line:
echo -e '{"version": "1.1","host":"example.org","short_message":"WOOORRRKIIING","full_message":"Backtrace here\n\nmore stuff","level":1,"_user_id":9001,"_some_info":"foo","_some_env_var":"bar"}\0' | nc -w 1 -u <IP_ADDRESS> 12201

However, when I try the examples given in graypy documentation, it is not working. No errors, but I cannot see the logs on Graylog.
import logging
logger = logging.getLogger('projectname')
logger.debug('Please, work! :) ')

This is my setup:
'gelf': {
    'class': 'graypy.GELFHandler',
    'host': '<IP_ADDRESS>',
    'port': 12201,
}

and
'projectname': {
     'handlers': ['gelf'],
     'level': 'DEBUG',
 }

Please, note that when I do 'host': 'localhost' it is working on the local Graylog server. That's why I think that the problem may be in 'host': '<IP_ADDRESS>'. Is DNS name required? or am I doing something wrong?
Thank you!

Sorry, nevermind! This is my bad

@rahmonov Hey!
Please, explain me what have you done here to solve the issue. My problem is that when messages are sent from local machine (via 'host': 'localhost') they are delivered successfully, but with 'host': '<public_ip_of_my_graylog_server>' the logs are not delivered.
12201 UDP port is opened for external access in my VPC security group as well as in iptables.

@Tayum unfortunately I don't remember. I wish I explained how I fixed it. Was too young I guess :) But I looked at my configuration and saw that I changed the IP to a DNS name. Maybe this is what helped. Apologize again.

@rahmonov Thank you anyways for taking the time to reply :)


Fix backup of /etc cmd when PTP is configured

When PTP is configured, the chronyd service unit is disabled, which makes the below command to fail with the below error

ostree admin config-diff | awk '{print "/etc/" $2}' | xargs tar czf /var/tmp/backup/etc.tgz --selinux

time="2023-10-17 15:32:23" level=debug msg="Running command: nsenter --target 1 --cgroup --mount --ipc --pid -- ostree admin config-diff | awk '{print "/etc/" $2}' | xargs tar czf /var/tmp/backup/etc.tgz --selinux"
tar: Removing leading /' from member names tar: Removing leading /' from hard link targets
tar: /etc/systemd/system/multi-user.target.wants/chronyd.service: Cannot stat: No such file or directory
tar: Exiting with failure status due to previous errors
time="2023-10-17 15:32:24" level=error msg="An error occurred: exit status 123"

/cc @alosadagrande

Fixed by c76f4a2.


2010 Interface Style Issue

Describe the bug
When using the 2010 interface style tool, the inventory icon has moved to be underneath the prayer icon - making the stone that's supposed to house the backpack icon, blank.
Screenshots

Environment (please complete the following information):
Latest release: 1.4.14

Duplicate of #5105


Odd white bars in the terminal.integrated.commandsToSkipShell setting

Issue Type: Bug
Repro

Open settings
View terminal.integrated.commandsToSkipShell

Bug
The setting description has a pair of white bars:

These are markdown horizontal rules but look out of place. I think they are the only place I've seen them used in the settings UI
VS Code version: Code - Insiders 1.48.0-insider (731f9c25632dbbf01ee3a7892ad9d2791fe0260c, 2020-07-24T05:51:27.957Z)
OS version: Darwin x64 19.6.0

System Info

Item
Value

CPUs
Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz (16 x 2400)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onoop_rasterization: enabledopengl: enabled_onprotected_video_decode: unavailable_offrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
2, 2, 2

Memory (System)
32.00GB (0.02GB free)

Process Argv
--crash-reporter-id cc7f0c9b-aa2b-4a45-8baa-81ffda32679e

Screen Reader
no

VM
17%

I added these as part of my PR #100445. IMO this setting is unusual in its complexity, and the lines are intended to help the user parse the large quantity of information being presented.

I think they look alright personally, maybe a little heavy if anything?

This is the only setting I see that uses them so I feel they look out of place. A normal paragraph break the sections would probably work
If we keep the horizontal rules, my recommendations would be:

Add top and bottom padding to them
Adjust the color to be less bright
Potentially adjust the width to only span part of the text width

@misolori may be able to provide better suggestions

I agree with @mjbvz's suggestions

Using Developer Tools I added the following to the first  element created by the markdown:
 */
    margin-top: 10px;
    margin-bottom: 10px;
    margin-left: 20px;
    margin-right: 20px;
    opacity: 0.4;

Result is:

Then I added border-bottom-width: 0px; and applied the styling to both lines to get this:

And with the default light theme:

Is that more acceptable?

What does it look like with a normal paragraph break?

Or removing the italics and splitting that into its own para:

The paragraphs are just as impactful as the rules imo.

@gjsjohnmurray The second example with the newlines look good to me. Thanks for taking a look!
We may also want to check in the css to make the horizontal rules look better since settings from extension could use them


Revise and consolidate the tensor encoding checks

New checks for CSR/CSC were added in PR#110. Unfortunately, those checks were incorrect (see discussion #165).
This PR fixes the CSR/CSC checks and consolidates them with the existing checks. The general approach was to use the framework of the existing checks (return optional, message if error, None if success). But instead of passing an index to indicate the operand number (or return value if negative), that piece is left to the caller to make the check less magical and to give greater flexibility to the caller.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
5 unchanged lines in 2 files lost coverage.
Overall coverage remained the same at 82.7%

Files with Coverage Reduction
New Missed Lines
%

mlir_graphblas/engine.py
1
75.1%

mlir_graphblas/tests/test_profile.py
4
51.95%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
2548

Relevant Lines:
3081

💛  - Coveralls


Too Many Transactions

Identified an issue with one of my wallets I use for mining. When i use the webapp in production I get the loading screen for a moment and then nothing. The screen shows as if it has reloaded but doesn't show a link for report download.
Upon inspection in Chrome dev tools, it looks like the error is in the following API call
Request URL:
https://api.kaspa.org/transactions/search
Request Method:
POST
That API call receives a response of "{"detail":"Too many transaction ids"}"
Can anything be done to paginate this API call when wallets show transaction counts above the threshold for that api endpoint?

Thanks for reporting @awood0540. Looking at the rest api, there is indeed a limit for the number transaction IDs that can be passed at a time (1000): https://github.com/lAmeR1/kaspa-rest-server/blob/40fdccd3d00bfef043b987a1098f201b7669577c/endpoints/get_transactions.py#L176
So I'll request over these transaction Ids in groups of 1000 or less.

Thanks so much @coderofstuff !! I really appreciate all of your effort, time, and contributions to the kaspa community!

Thanks for reporting @awood0540. Looking at the rest api, there is indeed a limit for the number transaction IDs that can be passed at a time (1000): https://github.com/lAmeR1/kaspa-rest-server/blob/40fdccd3d00bfef043b987a1098f201b7669577c/endpoints/get_transactions.py#L176
So I'll request over these transaction Ids in groups of 1000 or less.

Hi, have you implemented this fix? I am still getting the too many transactions error

Should be fixed in 818de3a5172a6113abc5172f4910191b8adf7b87
Try it @awood0540 @tchey290