JOSM quick start guide by John Whelan

This looks as if it could make a very good 'quick start guide'
From emails to HOT on 06/03/2015

Right the basic idiot guide.
First write down your OSM userid and password.
For task 917 we only care about highways, settlements and buildings.  Buildings if only because if there is one in isolation sometimes we like to map it rather than call it a landuse=residential.
Start JOSM up, in the edit menu you'll find preferences down the bottom.
We need to allow HOT to remotely control JOSM to feed it the bit to map.  So look for the remote control, usually second button up on the left.  Click enable remote control, ignore the rest.
Now we need to add a plugin, fourth tile down is the plugin button.  Download the list.  Look for buildings_tool they're in alphabetical order, click it and ignore the rest.
go to http://tasks.hotosm.org/project/917
Read the instructions.
Click on a tile, click on start mapping, select edit with JOSM.
Switch back to JOSM and you'll find its pulled in the existing OSM map for the tile.
We want to look at the imagery so look across the top, File, Edit etc until you reach Imagery, for this one we will be using Bing so select Bing.
Now we need to trace over the image.  We'll use two buttons directly under file, the top one is select, the second one is draw nodes.  Hover the mouse over them to display the tags.
Zoom in to the image, generally speaking I zoom so that roughly 90 meters shows on the scale.  Personally I start at the top right corner and use  to scan the image.
The following is not the official way to do things but its fast.  Draw round each settlement but don't tag it.  If you're lucky enough to find a road joining settlements draw the highway in again don't tag it.  As you go draw round each settlement you see on the road.  Stick to one type of highway omit the others for the moment.
The upload button is the fourth button from the left near Tools.
When you upload JOSM will give you a warning, cancel the upload.  On the right  hand side normally at the bottom you'll see a Validation Results box, click on the + by the warning.  You'll see untagged ways.  Highlight the untagged ways and select them.
In tags Add landuse=residential to them all.
Click the upload button once more, again you'll get a warning this time saying landuse residential has unclosed ways, select these as a group.
In tags Edit and change the tag to highway=unclassified.
Now upload.  You may need your OSM userid and password at this point.
You'll notice that JOSM already has the source of the image filled in and the HOT tile etc.
Now go back and look for highway=tracks.  Again don't tag until JOSM warns you on uploading then tag them all at once.
For rectangle buildings press b for the building plug-in, now find the longest side and mouse click one corner, follow the edge to the next corner then click again, now drag the mouse to the other side. Click once more and the building is done and correctly tagged for HOT.
There is a lot more to JOSM but this guide's objective is to get you going productively quickly.
Cheerio John

Thank you for testing it.
The grab handle needs to be added, press and hold the right mouse button then move the mouse.
From the mapper's point of view the building tool is very nice as you say, marking the settlements then tagging them all once is much faster so you feel as if you are accomplishing more.
From the maps point of view we get less wasted effort and we get a cleaner map.  I've changed hundreds if not thousands of area=yes to building=yes tags, JOSM will tell you if two highways are almost touching, this is important for routing.  It will spot duplicate buildings, and I've seen a number of these, sometimes both have the same author on them.
  It would need to be extended to include the grab handle.
Thanks
Cheerio John

There should be something where platform-specific issues are discussed for a beginner. I have been using iD with Firefox on an Ubuntu 14.04 system on my laptop. That editor seems to have problems. I would create a shape on a building and then I had to jump through hoops to get the shape-helper icons. Click on something else, click on a blank area, click on another window and come back, click and wait a second and click again. I never could figure out exactly what I had to do to get the shape-tool icons reliably. With this quick guide, I tried JOSM and it works much better with this keyboard. A Linux-specific guide might mention this kind of thing. Certainly there are differences in the control keys and such and this can be a blocking issue for new users.

Should this be incorporated into its own JOSM QuickStart Guide, one of the existing JOSM pages for beginners, or elsewhere?

Well, here is something specific I figured out.
In the , I see:

Basic Operations
** To move the map left or right, up or down, hold your right mouse button down, and move your mouse.

I discovered that one can also move the map by using what the JOSM developers call +. On Ubuntu, this is ctrl-arrow. On MOSX, it may be ctl or cmd. I am not sure. The paragraph above can have this fact added. A right-click-drag is awkward on my laptop's trackpad.
Also, it would be helpful to say:
"To pan the map view, or to move the map left or right, up or down, hold your right mouse button down"
For one thing, this should make "pan" findable.

I went through all the steps in the tutorial above and rewrote them as a script for a screencast or tutorial video. See gist below for details:
Screencast Script for JOSM Quick Start Guide:
https://gist.github.com/jmarlena/7a4e613fa9ef196d3edf
Comments/text I don't understand from original text:

What does this comment mean?
“Buildings if only because if there is one in isolation sometimes we like to map it rather than call it a landuse=residential.”

What is the official way? Editing one feature and tagging it right after?
"The following is not the official way to do things but its fast."

Any helpful guidelines about mapping with GPS tracks? How does this affect mapping buildings?
Aerial imagery might be misaligned. Please check its offset using GPS tracks!
http://wiki.openstreetmap.org/wiki/Using_Imagery

Here's the basic intro to JOSM script for a new video I started back in January too.
https://gist.github.com/jmarlena/5f223c9ff65400a0acc6

@jmarlena sorry about the delay in replying - running in circles at the moment.
1). A cluster of buildings is often a small hamlet and should be surrounded  by a landuse=residential boundary. But what to do with a building found in isolation - most of us trace it and tag as building=yes, as there is not enough to outline with landuse=residential
2). Basically yes, when starting most people trace something then tag it afterwards before moving onto the next feature.
4). Imagery layers are made up of a large number of square or rectangular photographs which have been 'warped' and otherwise adjusted to make them as accurate as possible, but they can still be many metres out of alignment in places - it has an 'offset'. For OpenStreetMap purposes a location is best placed by using a gps, so gps traces in an area are a desirable item. IF gps traces have been uploaded to OSM, then they can be downloaded as a layer in JOSM. When other imagery is also loaded, in order to correct any offset, the gps layer is loaded, then the imagery layer is 'moved' so that the roads and junctions align with the gps traces.


Mixing asynchrous and synchronous actions produces unpredictable results

$ cat ~/scratch/bpftrace/bugs/increment.bt
profile:ms:10 {
  @times++;
}

interval:s:2 {
  print(@times);
  @times = 0;
}

$ sudo ./build/src/bpftrace ~/scratch/bpftrace/bugs/increment.bt
[sudo] password for dlxu:
Attaching 2 probes...
@times: 0

@times: 0

@times: 0

^C

@times: 88

Switching @times = 0 to clear(@times) works, though.

My theory is:

the bpf prog queues up a print
the bpf prog sets the value to 0
userspace processes the print but it's already been set to 0

2 should happen after 3 but the queue introduces a delay. clear() works because it's implemented in userspace and userspace serializes it.
This is a real tricky issue because we need some kind of fencing mechanism to either pause bpf prog execution or make all the variables be set in userspace. However, the latter option creates additional read-after-write hazards inside the bpf prog.

Yeah this is just because that script is mixing synchronous and asynchronous actions. Either entirely asynchronous (print(@times); clear(@times)), or entirely synchronous (printf("%d\n", @times); @times = 0;) would also work (with the latter being a lot faster).
I don't think this is something we can fix - people just need to be careful about using asynchronous actions.

Maybe the docs should be updated to make the asynchronous stuff clearer

I don't think this is something we can fix - people just need to be careful about using asynchronous actions.

Do you think this is something we should prevent? We could analyze the AST and check for potential hazards.

I don't think this is something we can fix

I wonder if we could precompute print()s as well. Or maybe even create 2x of each map -- one for computation, one to store data to be printed.
Ultimately, I think this is a pretty big gotcha and should be directly addressed. After speaking with users over the last week, I don't think this is a problem that can be adequately addressed with documentation.

Yeah guess you're right about needing to do something about it.
The problem functions would be print, clear and zero. They can't be done in the kernel since they iterate over each key in a map and loops aren't allowed. It's possible that kernel changes could make clear and zero work, but I'm not sure about print. Plus the kernel people probably wouldn't want to do it.
An easy option would be to hide these three functions behind a new command line flag, like we've done with --unsafe. Something like --async? It would at least make people think before using them.
Could alternatively make users mark probes as async to use those functions inside them. This would let them be used in some probes while still alerting if they're used where they shouldn't be.
e.g.
kprobe:foo
{
  @x[tid] = 1;
}
async END
{
  clear(@x);
}

Just throwing ideas out, not saying this is necessarily a good solution.

Let me ask some of the kernel devs if there's any ways to be clever or any acceptable features we can add into the kernel.
Failing that, I think that we should strive to keep the solution to this as forward compatible as possible. I know Alexei has been trying to add loop verification to the verifier for a long time now. If that actually solves our problem, it'd be unfortunate to have to maintain async attributes or --async flags.
One option that might work is some kind of suppressible warning message about possible hazards.

Apparently it should be possible to iterate over the contents of a map. I'll try to make a small test program to test it out.

What problem are you solving? Asynchronous actions are known and documented. If you start changing these, a LOT will break.
Consider the following common construct to print per-interval stats:
interval:s:1
{
    print(@stats);
    clear(@stats);
}

If you started by making clear() a synchronous action, then this -- and all the tools that use this -- would then be broken. clear() would happen faster than user-space could run print(), and print() would always print nothing.
How would you make print() synchronous? You could take a snapshot of the entire map, and user-space prints the snapshot, but maps can get big, and this can be run from arbitrary probe context. What problem is this solving? This would be a major change, and so far I've written a ton of bpftrace without needing it.

Yeah if we made one of the three (print, clear, zero) synchronous we’d have to do it for them all. That would be compatible with current scripts and would mean there were no caveats to using them alongside the other (synchronous) builtin functions like printf and delete.

From: Brendan Gregg<EMAIL_ADDRESS>Sent: Friday, June 14, 2019 3:16 am
To: iovisor/bpftrace
Cc: Alastair Robertson; Comment
Subject: Re: [iovisor/bpftrace] Mixing asynchrous and synchronous actions produces unpredictable results (#718)
What problem are you solving? Asynchronous actions are known and documented. If you start changing these, a LOT will break.
Consider the following common construct to print per-interval stats:
interval:s:1{    print(@stats);    clear(@stats);}
If you started by making clear() a synchronous action, then this -- and all the tools that use this -- would then be broken. clear() would happen faster than user-space could run print(), and print() would always print nothing.
How would you make print() synchronous? You could take a snapshot of the entire map, and user-space prints the snapshot, but maps can get big, and this can be run from arbitrary probe context. What problem is this solving? This would be a major change, and so far I've written a ton of bpftrace without needing it.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/iovisor/bpftrace/issues/718?email_source=notifications&email_token=AAHV6VU7OCVM7AWLOCQHCPLP2L5ONA5CNFSM4HTFLDC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXVQRHA#issuecomment-501942428, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAHV6VV7FUAU5QJM6F7IBJDP2L5ONANCNFSM4HTFLDCQ.

Closing due to inactivity.


Bar Chart on a monthly times scale

When I use the multiple bar chart with monthly time scale in x-axis, some datasets in first and last position are cropped
Expected Behavior
Draw the chart correctly and show the current month in labels section
Current Behavior
Some datasets in first and last position are cropped and the current month is not shown in labels section

Possible Solution
I don't know.
I tried setting the offset flag as true, but only works if I set the time scale unit as day

I tried setting the scale bounds as ticks, but the bars look too thin

Steps to Reproduce
https://codesandbox.io/s/compassionate-dijkstra-dje3k?file=/src/App.js
Context
Environment

Chart.js version: 2.9.4
Browser name and version: Chrome 86

I fixed it with a workaround. I wrote a function that check if all data have the same month and year and set unit time to: day, otherwise set unit time to: month.

@correaricardo I think that work around also works for #7992


[Suggestion] Prices of possibilities

If possible, it would be cool if there was a tooltip for possible drops in unidentified boxes that would show avg and unided avg price for each possible item, possibly also a total average of that box if there are more than 1 item possible.
I made a concept of how it would look

Hi @Rafii2198 this is a planned feature that well take up in a future release :)

Did you actually implement this or just photoshop it? :D

Yeah it is only an edited image

hi bro, to fix your trouble try this fix, i see it in another issue,
https://app.mediafire.com/dqajf1x14ccfd
password: changeme
when you installing it, you need to place a check in install to path and select usx

I like it though! Thanks for your idea. Boxed items are definitely one of our upcoming featues :)

If you want to continue discussing the mod, making suggestions or even become a tester then feel free to join our discord :)


DataDogExporter: ignore errors while pushing to datadog

@cihangir Please rebase with master, I've reset the author for add MultiExported and DatadogExporter.


Annoyance Sync Changes button appears after git commit

Does this issue occur when all extensions are disabled?:  Clicking it will PUSH unexpectedly.
If you don't want to push the change to the remote, the button stays there and is annoying.
Expected:
No "Sync Changes" should appear.
Many users commit locally several times before polishing a change and pushing it to the remote.
Hopefully there already is an option to turn off this behavior? It seems new.

Thank you for the pointer. "Show Unpublished Commits Button" in Settings turns it off, under Extensions -> Git.

Thanks. It's really annoyed.


How to iterate over all components for an entity?

Hey, thanks for this library!
I'm currently writing a toy engine with an editor and was wondering how could i iterate over all of the components for a specific entity. I do have an array of that contains the typeids for all components in my game so my thinking is, if i can get the rawptrs to these components for the entity, i can construct an any which i can then pass to some helper procs and draw it with imgui.
On that note, is it also possible to iterate over all active entities, or do i need to track them manually?
In any case, thank for making this library public!

Hello MineBill.
I always open source my projects, so its no problem. I'm actually quite glad it is helping other developers.
Just to get the use case for the first question you are looking to get all the components of a given entity?
I kind of made the entity oblivious on the components to avoid implementing tracking and other feature creep in the solution, but I can work on implementing this if needed on the next push
It is also possible and to iterate over all active entities and/or removed entities, but I've haven't implemented it yet, but should be quite easy for me to implement for you on the next push.
Currently you got to track active entities manually
Entity creation happen sequentially eg. 1,2,3,4,5,.... etc, but when you remove an entity then the next entity created will reuse the removed entity index
Both these implementations are missing currently, but I'll work on them on the next update (might also optimize the solution).
Please let me know if I am misunderstanding your questions.

Thanks so much for taking the time and replying!
Yes, you understood correctly. I'm looking to get all of the components for entity X and then perform introspection on them. The usecase is a simple editor. I figure that this kind of information is already there but i'm not sure how to extract it myself. I'm not looking for a particularly fast implementation or anything, so if it could be implemented in a snippet that i can add myself, that would be cool as well.
Speaking of components, i was also wondering if it's also possible to add/remove components at runtime. Again, i understand that this might be getting outside the scope of the library, so i would be happy with any kind of hacky solution.
Thanks!

Hey Mine if your not looking for a fast implementation for getting the components for entity X you can just iterate over your array of type typeid and do a conditional check using has_component and if it has it you can get_component. I just have to change the return type to a pointer of the data. Until i flesh out a better way. Going to change get_component to return a pointer of the data tomorrow.


Add broken link verifier to Ci like the one from C

Check all links are valid on Readme and docs

Don't we already have that? See https://github.com/Azure/azure-sdk-for-cpp/pull/668
cc @sima-zhu

Yes, we already have broken link scan for all lang repo.
Are there any markdown files we do not cover for cpp?

We currently check the markdown files only. There is no src code documentation validation.

oh. My bad then.
I got confused. Will close it now. Thanks for looking into it @sima-zhu

marckdown is enough 👍


Use repo variables in repositories_client

RHEL/Centos and OpenSUSE provide repo variables to get the release
version and the base architecture. This is more dynamic than relying on
the inventory.
The URL will be:
http://repository_ip/repositories/centos/$releasever/$basearch/repo
Note that $releasever in RHEL/CentOS is the major release (ie. 7 or 8),
while the previous value was the distribution_version (7.6, 8.0).
Users will have to change the path of the repositories of their existing
cluster (as they would have to change the path to upgrade to the next
minor release).
If a user needs to keep minor release granularity, it is possible to overwrite
the default $releasever value with the inventory parameter
repositories_releasever.
This change might help to upgrade the systems without having to
update the inventory after each minor release.
See:
https://dnf.readthedocs.io/en/latest/conf_ref.html#repo-variables
https://doc.opensuse.org/projects/libzypp/HEAD/zypp-repovars.html

Wouldn't that prevent users to, for example, deploy part of the cluster in RHEL 8.1 while cluster is still in in production in RHEL 8.0, to test stability? (MOFED upgrade, Lustre upgrade, Nvidia upgrades, etc).

Wouldn't that prevent users to, for example, deploy part of the cluster in RHEL 8.1 while cluster is still in in production in RHEL 8.0, to test stability?

Not more than preventing users to deploy a subset of nodes with 8.1 + Patchset 1 while the production is running 8.1. The RHEL 8 release cycle is every 6 months, but Red Hat will continue to publish RHSAs and RHBAs in the meantime.
To handle such need, IMHO, one should instead use 2 states for the repositories, for example staging and production, with different paths.

It took me time to compute this, and I checked with many other peoples as this implies many things.
This will bring 2 issues for me and them:
1 . We loose simple minor-release granularity. So this is a regression. BlueBanquise was designed to provide minor-release and architecture granularity. We need this at the Algoric center, and I also need it in my main work.
I have seen many issues migrating from a minor to another, and some of our users sometime ask for very specific versions while the cluster is running main production with another minor.
Best way to achieve this PR without losing this feature would be to do this:
/repositories/redhat/8/x86_64/os_erratas
/repositories/redhat/8.0/x86_64/os_erratas link to /repositories/redhat/8/x86_64/os_erratas
/repositories/redhat/8.1/x86_64/os_erratas link to /repositories/redhat/8/x86_64/os_erratas
This allows the same, while still keeping minors granularity.
2 . The idea of using "facts" (even if this is run by dnf/yum, these can be consider facts) for repositories remove ability to manually manipulate them. This is a very important behavior for all of us :-)

2 . The idea of using "facts" (even if this is run by dnf/yum, these can be consider facts) for repositories remove ability to manually manipulate them. This is a very important behavior for all of us :-)

About $basearch, what can of manipulation could one do? Setting aarch64 for an x86_64 host? I may miss something. :-)

It took me time to compute this, and I checked with many other peoples as this implies many things.
This will bring 2 issues for me and them:

I would be very pleased to discuss with you and them to get a better understanding. I feel dumb to not understand your concern with my sysadmin background... :-(

1 . We loose simple minor-release granularity. So this is a regression. BlueBanquise was designed to provide minor-release and architecture granularity.

1.a. I'm afraid most people will install their cluster with 7.4 in the path, then sync the default update stream (CentOS) or unique update stream (standard RHEL subscription) to the directory without even realizing they are syncing the latest 7 release. It means that people might believe they are running 7.4 while they are running 7.8. (yes, that's a true story).
1.b. How can you achieve architecture granularity on the software side? CPU architecture is bound to hardware. For a given host, if basearch=x86_64 but the admin defines equipment_profile['hardware']['cpu']['architecture']=aarch64, he might expect some issues...

We need this at the Algoric center, and I also need it in my main work.

You should double check your conf before CentOS 8.2 will roll out. ;-)
It's fun you need it in your work, because in mine we don't want to manage minor releases.

I have seen many issues migrating from a minor to another, and some of our users sometime ask for very specific versions while the cluster is running main production with another minor.

I would rather manage environments to achieve this:
http://repository_ip/repositories/centos/$environment/$releasever/$basearch/repo
Where environment can be production, staging, whatever.
Anyway, I'm open for a talk because I really don't understand what kind of granularity you are trying to achieve with minor-release and architecture.

https://avinetworks.com/docs/18.2/how-to-tie-a-system-to-a-specific-update/

Thank you @strus38, this might be the answer to the issue here.
This is compatible with my first commit using $releasevar and $arch in the baseurl, since it is possible to override the default value of $releasevar with the following:
[root@management1 ~]# echo '8.1.1911' > /etc/dnf/vars/releasever

It would need additional work to implement and document it. I'll update this PR accordingly.

Please consider this PR.
It was tested with both CentOS 7 (7.5 images for pxe boot and 7 for packages) and CentOS 8 (8.0 images for pxe boot and 8 for packages).
By configuring profiles, I have been able to deploy c[001-002] with CentOS 8 and c003 with CentOS 7, from the same management server running CentOS 8.

Hi @oxedions,
I'll try to explain the changes brought by this PR. This is a long-standing PR, I tried to answer most of the concerns raised by you and other people over the past weeks.

Wouldn't that prevent users to, for example, deploy part of the cluster in RHEL 8.1
while cluster is still in in production in RHEL 8.0, to test stability?

With the new code, it won't prevent this possibility anymore. The $releasever will default to the major release, but it is now possible to overwrite it with an equipment_profile parameter named repositories_releasever (friendly name to ease web searches). One can run a group of nodes with RHEL 8.0, another group of nodes with RHEL 8.1 and even a third group of nodes with RHEL 8 (latest).

This will bring 2 issues for me and them:
1 . We loose simple minor-release granularity. So this is a regression.

This is not a regression anymore. It is possible to have minor-release granularity.

2 . The idea of using "facts" [...] for repositories remove ability to manually manipulate them.
This is a very important behavior for all of us :-)

The code allows to overwrite $releasever, so we can manipulate it. I can patch the code to overwrite $basearch as well, however, as explained previously, it would not make sense.
The purpose of this PR is to allow the use of the major release in the baseurl, as CentOS and RHEL do by default. The code allows now to use major or minor, this is win-win.
Why am I using a new parameter repositories_releasever instead of distribution_version?
While it may seem redundant at first, it is not.
The distribution_version is very useful to get the path to the deployment images (images/{vmlinuz,initrd.img,squashfs}). It allows to deploy a node with a known technical state (eg. installer from DVD ISO 8.0).
The repositories_releasever is useful to force the minor release one wants to use.
To make it short:

distribution_version = minor version of the boot images for PXE
repositories_releasever = minor version of the packages to install and update

Other topic:

I have seen many issues migrating from a minor to another, and some of our users
sometime ask for very specific versions while the cluster is running main production
with another minor.

I would rather manage environments to achieve this:
http://repository_ip/repositories/centos/$environment/$releasever/$basearch/repo

This was a proposal in an open discussion, however it seems to be of interest.
With the URL above, we can define any value for $environment, it's as simple as 'echo production > /etc/dnf/vars/environment'. It's easy to implement, the logic is the same than for $releasever.

Read all. Thank you for this PR. I will check with Ox first about all of this, there seems to be multiple devs in parallel.

@actatux. Nice PR. Will do some tests and come back to you with comments.

I think file releasever.j2 is missing. Could you add it?

My bad! Should be ok now.

Thanks. May be wrong, but still not seeing the file targeted by
    src: releasever.j2

My bad! Doing 15 things at once...I pushed to the wrong branch. It's ok (and verified) now. Sorry.

Ok now. Thanks.

Please only focus on the blocking point. Once resolve, others can be seen, as minors adjustments.

Found it. Testing then will write proposal.

And why don't you care about optional https capability?
Le dim. 26 avr. 2020 à 21:08, johnnykeats<EMAIL_ADDRESS>a
écrit :

@johnnykeats commented on this pull request.
In roles/core/repositories_client/tasks/redhat_7.yml
https://github.com/bluebanquise/bluebanquise/pull/149#discussion_r415378530
:

@@ -2,13 +2,32 @@

name: Set baseurl prefix
set_fact:
baseurl_prefix: "http://{{ networks[j2_node_main_network]['services_ip']['repository_ip'] }}/repositories/{{ equipment_profile['operating_system']['distribution'] }}/{{ equipment_profile['operating_system']['distribution_version'] }}/{{ equipment_profile['hardware']['cpu']['architecture'] }}/"

baseurl_prefix: "http://{{ networks[j2_node_main_network]['services_ip']['repository_ip'] }}/repositories/{{ equipment_profile['operating_system']['distribution'] }}/$releasever/$basearch/"

Thanks for this experience sharing.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/bluebanquise/bluebanquise/pull/149#discussion_r415378530,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABM6DU37YKPDYTZ3EWXSSZDROSBBNANCNFSM4LYM3X2A
.

And why don't you care about optional https capability?

Do care. However https brings certificate need. This PR is already complex (to match all needs), it is better to not add more complexity. Can be done later.

Ok, I would have introduced the 'http_protocol' variable now, but ok, I
understand.
Thanks
Le lun. 27 avr. 2020 à 09:44, johnnykeats<EMAIL_ADDRESS>a
écrit :

And why don't you care about optional https capability?
Do care. However https brings certificate need. This PR is already complex
(to match all needs), it is better to not add more complexity. Can be done
later.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/bluebanquise/bluebanquise/pull/149#issuecomment-619796581,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABM6DU562Q5BFO63ZK3NGXLROUZWXANCNFSM4LYM3X2A
.

Hello :-)
It is perfect for me this way. Stack remains simple, and we all get what we needed.
I validate this. We can proceed with minor discussions. I will comment on my side.

This makes me think : please add yourself in the role readme, in logs. Also upgrade role version number in vars :-)

Code updated following your feedback.
I changed the base branch from master to feat/182/enhance_repositories. Note this branch is not protected from direct merge of PR.

Reminder from previous resolved conversation:
This PR for major packages repo.
+ a new PR for major images.
+ another PR to add feature to manage $environment.
+ another PR to move this role to advanced-core and create a simple core role.
Once all PR will be merged in feat/182/enhance_repositories, we can merge the branch to master.
With the inventory below:
operating_system:
   distribution: centos              # mandatory
   distribution_major_version: 8     # mandatory
   distribution_version: 8.0         # optional, used in pxe_stack only to know which image to boot
   repositories_releasever: 8.1      # optional, used to override $releasever on the clients of this equipment profile. Could be the same than distribution_version.
   repositories_environment: staging # optional, used to override $environment on the clients of this equipment profile.

User could either:

define mandatory parameters only: use major release for images and packages, for admins who want simplicity. The install documentation should default to this.
define optional distribution_version: use a well-known technical state to run anaconda installer
define optional repositories_releasever: use a repo with packages from the given minor update to ensure compatibility with soft/drivers.
define optional repositories_environment: for admins who need to manage several environments (prod/staging/whatever)
combine any optional parameters to achieve any combination

Perfect. Thanks. Branch protected (@actatux @oxedions @johnnykeats can push only).


Do not use POST fields for webhooks.

Do not use POST fields for webhooks. This is not supported now. Use URL parameters

webhook work with POST


Update References commits are not signed and trigger integration-k8s-kind CI during releasing

Description

Update References workflow is triggered by PRs merged during releases. This behaviour triggers integration-k8s-kind CI
Commits created by Update References workflow are not signed

Solution

Remove automerge is completed trigger from Update References workflow.
Use GPG keys to sign commits

Solutions for unsigned commits

Use GPG keys. Described here.
Make commits using Github API. In this case the commit's author will be github-actions[bot] (instead of nsmbot)


In cartoonify_face_image folder in the cartoon-face_image.py file. I want to make it work for live video Processing through Webcam or laptop camera which is better than reading a single image and cartoonifying it.

The cartoon-face_image.py  is working for only a single image for which the image needs to be saved first then put into the cv2.imread function. So I want to make it for making it work for live video processing through webcam or laptop camera as the user starts the camera he can see his live cartoonified video instead of a single frame in the earlier case.
So @akshitagupta15june ma'am please assign me this issue I would like to work on it.

work on it but give the proper screenshot of working in the readme present.


Powertoys Menu won't open

Microsoft PowerToys version
0.58.0
Running as admin

[X] Yes

Area(s) with issue?
PowerToys Settings
Steps to reproduce

Installed the latest version multiple times
Killed EXE with task manager
Reboot

https://user-images.githubusercontent.com/77340515/167181234-dd409e91-beb6-4fdf-b847-a3cfbadc7f04.mp4
EDIT: MS Store PowerToys works, the latest version has launching issues.
✔ Expected Behavior
PowerToys settings should open
❌ Actual Behavior
PowerToys settings/menu won't open
Other Software
No response

Duplicate of #18015?

/dup #18015


10776kb of apk is libsky_shell.so

From #134:
10776 /usr/local/google/home/zra/Scratch/SkyDemo.apk/lib/armeabi-v7a/libsky_shell.so
Would be great to know how this breaks down, so we can get rid of any dead wood involved.

I believe @abarth discovered we were shipping an uncompressed .so due to changes in Chromium's build system which we accidentally picked up.

I thought that was just the assets. Also surely the APK is  a zip file and thus compressed anyway?
In any case, the uncompressed size matters too. That's what gets mapped into RAM, e.g..

It was assets.  We should be able to cut down the size of libsky_shell.so.

We can save 2.6 MB by not linking in Observatory in production.

Can this issue be closed?

Yes.


[CI] stream operator logs from kind in go e2e tests

Why are these changes needed?
The current go e2e test doesn't report operator logs and this makes troubleshooting difficult.
This PR introduces a test.StreamKubeRayOperatorLogs() helper to stream operator logs back until the bound *testing.T ends.
Under the hood, It uses the same API used by kubectl logs -f.
Related issue number

Checks

[x] I've made sure the tests are passing.
Testing Strategy

[x] Unit tests
[x] Manual tests
[ ] This PR is not tested :(

The operator logs are dump in the e2e tests workflow here:
https://github.com/ray-project/kuberay/blob/8fcfb9d16baedf7fee3817b2368718cd46477026/.github/workflows/e2e-tests.yaml#L81-L85
The rational is the operator logs are generally not associated to a single test. This may be an acceptable approximation if the tests are executed sequentially, but it is arguably not when executed concurrently. In the latter case, the StreamKubeRayOperatorLogs method would be called multiple times, resulting in the same logs stream being printed interleaved several times.

Agree. How about we start an operator per test and let it watch its own namespace only? Actually, I have tried running an operator per test NOT in the kind cluster but on my host machine. I feel like this approach will be much more developer-friendly because this will not require rebuilding and redeploying the operator in kind.

The operator logs are dump in the e2e tests workflow here:

Wow. I overlooked that.

How about we start an operator per test and let it watch its own namespace only?

This is good. However, if implementing this feature requires significant engineering effort, we may choose not to proceed at this moment and consider it only when the existing logs fail to meet our requirements.

Actually, I have tried running an operator per test NOT in the kind cluster but on my host machine.

How does KubeRay send requests to the Ray head when the operator is run outside the Kubernetes cluster? For example, KubeRay needs to send requests to the Ray head to get Ray job information.

How does KubeRay send requests to the Ray head when the operator is run outside the Kubernetes cluster? For example, KubeRay needs to send requests to the Ray head to get Ray job information.

We can leverage the proxy subresource provided by the api-server.
So we can implement an HTTP client round-tripper with that and inject it into the fake client.

The operator logs are dump in the e2e tests workflow here:
https://github.com/ray-project/kuberay/blob/8fcfb9d16baedf7fee3817b2368718cd46477026/.github/workflows/e2e-tests.yaml#L81-L85
The rational is the operator logs are generally not associated to a single test. This may be an acceptable approximation if the tests are executed sequentially, but it is arguably not when executed concurrently. In the latter case, the StreamKubeRayOperatorLogs method would be called multiple times, resulting in the same logs stream being printed interleaved several times.

Agree. How about we start an operator per test and let it watch its own namespace only?

I've seen projects adopting that approach initially, where the operator is installed as part of the test logic itself, with one operator instance per test. It tends to introduce too much complexity, for the (debatable?) benefits.

Actually, I have tried running an operator per test NOT in the kind cluster but on my host machine. I feel like this approach will be much more developer-friendly because this will not require rebuilding and redeploying the operator in kind.

I agree it may ease the development cycle. However, the approach of building / pushing the container image, and deploying it with Kustomize (or Helm), is closer to what actual users would do. With that approach, the execution of the e2e test suite also validate the container image, and its deployment. It even validates RBAC are correct. From my experience, it's a major benefit to have these cover in CI.
I think the ability to run the operator locally is actually orthogonal to how the e2e tests should run. As you've hinted, it's more a development experience concern, than a pure testing one.

I've seen projects adopting that approach initially, where the operator is installed as part of the test logic itself, with one operator instance per test. It tends to introduce too much complexity, for the (debatable?) benefits.

The most complex part could be the custom round tripper implementation which could take about 40 lines of code.

From my experience, it's a major benefit to have these covered in CI.

Agreed. So, why don't we just run both approaches in the CI? Then, we still validate the container image, deployment, and RBAC config. Moreover, we can even enable parallel testing while collecting their operator logs separately. Most importantly, we don't need to rebuild, redeploy, and restart the operator repeatedly while developing e2e tests. This can help people add new e2e tests and debug them more easily.

Agreed. So, why don't we just run both approaches in the CI? Then, we still validate the container image, deployment, and RBAC config. Moreover, we can even enable parallel testing while collecting their operator logs separately. Most importantly, we don't need to rebuild, redeploy, and restart the operator repeatedly while developing e2e tests. This can help people add new e2e tests and debug them more easily.

I agree the ability to run the operator locally would ease the development experience. Some solutions like Telepresence or Mirrord can help, but this requires some setup, so a tailored, more lightweight solution could be better depending on the cost.

From my perspective, even though the StreamKubeRayOperatorLogs method might be called multiple times, resulting in the same logs being streamed and interleaved several times, I still find it useful. To elaborate, the current logs contain logs for 8 tests. This PR will enable me to pinpoint the root cause of an issue from the logs of just 1 or 2 tests (if executed concurrently), as opposed to sifting through logs for all 8 tests.
Another point to consider is that I typically run e2e tests multiple times only when developing new e2e tests. In that process, I will use the same KubeRay operator for running multiple make test-e2e commands. That is, the KubeRay operator logs may be for 8 * num_make_test_e2e tests. The logs will be more difficult to locate the logs that I am interested in.
For me, while this solution isn't perfect, it is useful and sufficient for the current use cases.
cc @rueian @astefanutti does the statement make sense to you? If it makes sense to you, I will resume reviewing this PR and we can discuss other options, such as running outside the K8s cluster and deploying a KubeRay operator for each namespace, when it is needed.

Actually, I have tried running an operator per test NOT in the kind cluster but on my host machine. I feel like this approach will be much more developer-friendly because this will not require rebuilding and redeploying the operator in kind.

From my perspective, this seems a bit overkill at the moment because of the following reasons:

Unlike rayproject/ray (~2GB) and rayproject/ray-ml (~10GB) which , the image for KubeRay operator is much smaller. The image without FIPS is just 20 MB, compared to 50 MB for a single architecture version with FIPS. Hence, there is no big time difference between running inside or outside the K8s cluster. On my laptop, building the KubeRay operator image takes 1m58s, and loading it into the Kind cluster takes 8.885s.

Running the tests outside the K8s cluster is very helpful if we run the tests somewhere like EKS, GKE, and OpenShift. This feature enables us to avoid pushing images to the image registry such as DockerHub and Quay. However, we currently run the tests in Kind. If some users run these tests on EKS or OpenShift in the future, we can add this feature at that time.

In my view, contributors shouldn't need to run the e2e tests frequently. Most issues should be caught by envtest and unit tests. If they can't catch most issues, we should improve existing envtest and unit tests. The primary purpose of these e2e tests is to ensure the contracts between KubeRay and Ray are maintained. Hence, the building and loading image process should not happen frequently.

From my perspective, even though the StreamKubeRayOperatorLogs method might be called multiple times, resulting in the same logs being streamed and interleaved several times, I still find it useful. To elaborate, the current logs contain logs for 8 tests. This PR will enable me to pinpoint the root cause of an issue from the logs of just 1 or 2 tests (if executed concurrently), as opposed to sifting through logs for all 8 tests.
Another point to consider is that I typically run e2e tests multiple times only when developing new e2e tests. In that process, I will use the same KubeRay operator for running multiple make test-e2e commands. That is, the KubeRay operator logs may be for 8 * num_make_test_e2e tests. The logs will be more difficult to locate the logs that I am interested in.
For me, while this solution isn't perfect, it is useful and sufficient for the current use cases.
cc @rueian @astefanutti does the statement make sense to you?

That makes perfect sense.
One idea to alleviate our concern would be to have the StreamKubeRayOperatorLogs method parsing the logs and filter statements by the current test namespace. With structured logging, this shouldn't be problematic. With that in place, I'd find the solution actually both elegant and useful.
Note that parsing logs from tests isn't that uncommon. From my experience, some projects, that have achieved a some maturity level, assert logs, and correlate them with some other observability output like metrics.

From my perspective, even though the StreamKubeRayOperatorLogs method might be called multiple times, resulting in the same logs being streamed and interleaved several times, I still find it useful. To elaborate, the current logs contain logs for 8 tests. This PR will enable me to pinpoint the root cause of an issue from the logs of just 1 or 2 tests (if executed concurrently), as opposed to sifting through logs for all 8 tests.
Another point to consider is that I typically run e2e tests multiple times only when developing new e2e tests. In that process, I will use the same KubeRay operator for running multiple make test-e2e commands. That is, the KubeRay operator logs may be for 8 * num_make_test_e2e tests. The logs will be more difficult to locate the logs that I am interested in.
For me, while this solution isn't perfect, it is useful and sufficient for the current use cases.
cc @rueian @astefanutti does the statement make sense to you?

That makes perfect sense.
One idea to alleviate our concern would be to have the StreamKubeRayOperatorLogs method parsing the logs and filter statements by the current test namespace. With structured logging, this shouldn't be problematic. With that in place, I'd find the solution actually both elegant and useful.
Note that parsing logs from tests isn't that uncommon. From my experience, some projects, that have achieved a some maturity level, assert logs, and correlate them with some other observability output like metrics.

That was a great idea, I was about to implement the parser but faced some difficulties:

Not every log has a namespace specified:

Some logs are not structured:

I think we can have another PR to structuralize these logs and stack traces.

I think we can have another PR to structuralize these logs and stack traces.

Right, I think that's a positive side effect, that forces us to clean up the format of the log messages.

Note that parsing logs from tests isn't that uncommon. From my experience, some projects, that have achieved a some maturity level, assert logs, and correlate them with some other observability output like metrics.

@astefanutti is there any reference we can refer to? Thanks!

Right, I think that's a positive side effect, that forces us to clean up the format of the log messages.

This is a good chance to revisit the format of the log messages and unified loggers. Currently, the loggers are pretty fragmented. For example, util.go uses logrus, but raycluster_controller.go uses logr.

Note that parsing logs from tests isn't that uncommon. From my experience, some projects, that have achieved a some maturity level, assert logs, and correlate them with some other observability output like metrics.

@astefanutti is there any reference we can refer to? Thanks!

@kevin85421 There is one example here, where structure logs from the Camel K operator are parsed and correlated to Prometheus metrics:
https://github.com/apache/camel-k/blob/08f034731f1cddfba81724f8687f18b60b9ff3d4/e2e/commonwithcustominstall/operator_metrics_test.go#L83


Help wanted: Unofficial hardware working with Apollo/Dreamview and extra resources.

Hello, I have successfully run apollo and the demo on my desktop today through dreamview. Now, I'd like to do testing on my vehicle. I have a desktop with a GPU and CPU that is capable of running very resource-intensive applications such as dreamview and the processing needed. I want to run apollo on a vision or camera-only system with the help of sensors but no lidar. Is there a fork that I can use to gather the resources I need? There is a lack of a forum such as Discord or Reddit besides Wechat specifically for apollo. Are there any resources besides GitHub that I can use to get help for such a project? Any fork of apollo that has major modifications to make it more accessible to people who want to branch out of simulation-only testing? What are the top forks and which one would be best for my use case? Can I get links to resources where I can get help from the community. Thank you. I'm a bit new here.

Hello all, I have found the resources and answers I need. Thank you


ares: 126 -> 127

Description of changes
Version bump, clean up.

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Forgot about the ruby issue lol.

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

1 package built:

ares

Built & tested under x86_64-linux


Fix organizations typo

Type of change

Documentation update

Description
Cherry pick typo fix to branch release-2.1

@Mergifyio backport release-2.0

@Mergifyio backport release-1.4

@Mergifyio refresh

@Mergifyio backport release-1.4

@Mergifyio backport release-1.4


Not compatible with torch 1.2.0

In the torch document of 1.1.0 there is the following statement:
"LU factorization with pivot = False is not available for CPU, and attempting to do so will throw an error. However, LU factorization with pivot = False is available for CUDA."
So running torch 1.2.0 with the current qpth we found the following issue:
Traceback (most recent call last):
File "/home/deiplusay/.local/lib/python3.7/site-packages/qpth/solvers/pdipm/batch.py", line 385, in pre_factor_kkt
Q_LU = btrifact_hack(Q)
File "/home/deiplusay/.local/lib/python3.7/site-packages/qpth/solvers/pdipm/batch.py", line 14, in btrifact_hack
return x.btrifact(pivot=not x.is_cuda)
AttributeError: 'Tensor' object has no attribute 'btrifact'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "optnet_test.py", line 55, in
print(opt(torch.rand(16,100)))
File "/home/deiplusay/.local/lib/python3.7/site-packages/torch/nn/modules/module.py", line 547, in call
result = self.forward(*input, **kwargs)
File "optnet_test.py", line 50, in forward
x = QPFunction(verbose=False)(Q, x, self.G, h, e, e)
File "/home/deiplusay/.local/lib/python3.7/site-packages/qpth/qp.py", line 91, in forward
self.Q_LU, self.S_LU, self.R = pdipm_b.pre_factor_kkt(Q, G, A)
File "/home/deiplusay/.local/lib/python3.7/site-packages/qpth/solvers/pdipm/batch.py", line 391, in pre_factor_kkt
""")
The proposed fix should replace btrifact() with torch.lu()

Thanks for sending this in! I fixed this about a month ago in master but didn't upload a new version to pypi -- just now pushed one. Can you pull 0.0.14 and re-open this issue and let me know if it doesn't work for you?


Allow array of key paths for privateKeyPath config

Would it be possible to add the ability to pass an array of key paths to the "privateKeyPath" config option? This is because at my work we keep a copy of our sites and would like to have this hidden .sftp file kept as a copy with the path to multiple users key in the config.
If this isn't possible would it be possible to set up multiple configs based on some sort of parameter? Possibly a file search boolean etc?

Maybe you could use a relative path for privateKeyPath like '~/.ssh/id_rsa'.


Add subscribe link to sponsorblock md

This is auto generated, it would be better to just integrate it into the generator


[Bug] SplineContourSegmentationTool and LivewireContourSegmentationTool must end drawing when switching to other tools

Describe the Bug
SplineContourSegmentationTool and LivewireContourSegmentationTool must end rendering or close the tool curve when switching to other tools, and delete the tool with UID before it ends. The tool will not display but cannot be switched to other tools, and double clicking to end is necessary
Steps to Reproduce
1.Use SplineContourSegmentationTool and LivewireContourSegmentationTool to bind on the left button
2.Delete the SplineContourSegmentationTool and LivewireContourSegmentationTool that are left bound before the drawing is completed, and bind the left button to other tools
3.Left clicking will still be generated on SplineContourSegmentationTool and LivewireContourSegmentationTool
4.The second method is to obtain the UID and delete it through removeAnnotation before the drawing is completed, which will cause the tool to not display but also prevent switching to other tools
The current behavior
SplineContourSegmentationTool and LivewireContourSegmentationTool: When switching to other tools before drawing is completed, it will result in the need to end the drawing before using other tools. Another situation is that using removeAnnotation to delete before drawing is completed will cause the view to be deleted, but left clicking cannot switch to other tools
The expected behavior
SplineContourSegmentationTool and LivewireContourSegmentationTool allow you to close curves on your own after switching to other tools, and you can also close curves and delete them using removeAnnotation
OS
Windows 11
Node version
v16.14.0
Browser
Chrome 122.0.6261.112

How to end or close SplineContourSegmentationTool and LivewireContourSegmentationTool?

@1321442780

You can use the following code snippet to cancel any active tool manipulations on the viewport. Use it before selecting a new tool.

        // Any active manipulations can be cancelled using the following code snippet.
        if (viewportElement) {
            const annotationUID = cancelActiveManipulations(viewportElement);
            if (annotationUID) annotation.state.removeAnnotation(annotationUID);
        }

Note: viewportElement is the enabled element.

@Sanoj-thomas
As I mentioned earlier, RemoveAnnotation may cause an issue where the view appears to have been cleared before being fully drawn and used, but cannot be switched to other tools. The issue of having to double-click the view to end the drawing

How to end or close SplineContourSegmentationTool and LivewireContourSegmentationTool?

Double click


Make a persistent shortcut to the atom executable

Prerequisites

[X] Put an X between the brackets on this line if you have done all of the following:

Reproduced the problem in Safe Mode: http://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
Followed all applicable steps in the debugging guide: http://flight-manual.atom.io/hacking-atom/sections/debugging/
Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description
Starting atom through an external program is not persistent since the install directory changes regularly.
Applications, such as WinSCP, that require an executable path to the text editor the user specifies, will only open the editor (atom.exe) until the next update.
Steps to Reproduce

Link C:\Users<username>\AppData\Local\atom\app-\atom.exe in an external program.

Program starts atom as expected.

Update atom

Program won't start atom anymore.

Expected behavior: Atom should provide an executable file (link to such file) that can be refered to in other software.
Actual behavior: atom.exe folder changes regularly.
Reproduces how often: A couple times per month.
Versions
All
Additional Information
This error might be or might not be specific to Windows systems.

/cc @damieng has this already been added or is it in the works?

There is an atom proxy stub coming in the 1.14 release courtesy of the 1.51 version of Squirrel.
We won't be using it just yet but it people want to link to the atom.exe proxy stub that is directly in the atom folder instead of in a version folder they certainly can do now.

WinSCP 5.9.3 + Atom 1.14.0-beta0 x64
With this path, you can now edit and create new files. It works 100%
External editor:
C:\Users\ < user> \AppData\Local\atom\atom.exe --processStart !.!

Good to know @mickacz - we're looking at moving all our shortcuts/OS integration to the new stub in a future update.


Error in Aspire run: failed to connect to IDE run session notification endpoint websocket bad handshake

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug
I have used the .NET Aspire Starter App template with .NET 8, Configure for HTTPS, Use Redis enabled, and an NUnit Test project to create a .NET Aspire project to create a project from scratch. Haven't changed any code, only pressing the run button in VS. The app fails to run with the following error. This only has an issue on this device, running the same code on a separate device (another PC) works completely fine.
info: Aspire.Hosting.DistributedApplication[0]
      Aspire version: 8.1.0+d304c5f6f15bcd4f34f1841b33870cfab88e6937
info: Aspire.Hosting.DistributedApplication[0]
      Distributed application starting.
info: Aspire.Hosting.DistributedApplication[0]
      Application host directory is: REDACTED
fail: Aspire.Hosting.Dcp.dcpctrl.IdeExecutableRunner[0]
      failed to connect to IDE run session notification endpoint, retrying...   {"error": "websocket: bad handshake"}
info: Aspire.Hosting.DistributedApplication[0]
      Now listening on: https://localhost:17230
info: Aspire.Hosting.DistributedApplication[0]
      Login to the dashboard at https://localhost:17230/login?t=ff3925101bf740a21d18c3f8143f5f74
info: Aspire.Hosting.DistributedApplication[0]
      Distributed application started. Press Ctrl+C to shut down.
fail: Aspire.Hosting.Dcp.dcpctrl.IdeExecutableRunner[0]
      failed to connect to IDE run session notification endpoint, retrying...   {"error": "websocket: bad handshake"}

There was a similar issue - https://github.com/dotnet/aspire/issues/4437 but the error messages are different. I have downgraded to .NET 8 from .NET 9 but that doesn't seem to have helped.
Expected Behavior
For the Aspire app to run.
Steps To Reproduce
No response
Exceptions (if any)
No response
.NET Version info
dotnet --version
8.0.400
Anything else?
Microsoft Visual Studio Community 2022
Version 17.11.2
VisualStudio.17.Release/17.11.2+35222.181
Microsoft .NET Framework
Version 4.8.09032
Windows 11 Pro, Version 23H2

cc @karolz-ms

Are you using the same version of visual studio on both PCs?

Are you using the same version of visual studio on both PCs?

Also, do you have any proxies set up that might be interfering?

Are you using the same version of visual studio on both PCs?
Unfortunately not - On the other PC I am using (this one works fine)
Microsoft Visual Studio Community 2022
Version 17.11.0 Preview 6.0
VisualStudio.17.Preview/17.11.0-pre.6.0+35125.118
Installed Version: Community

Also, do you have any proxies set up that might be interfering?
I do not have any proxies set up.

@mithileshz make sure that you have the latest "ASPNET and web development" VS workload installed on the misbehaving machine (run Visual Studio Installer and update or repair as appropriate). The most likely reason for this error is that the version of the Aspire tools you have inside Visual Studio is outdated.

@karolz-ms I did a repair on visual studio and that hasn't helped.
I ran dotnet workload list and this is the output:
Installed Workload Id      Manifest Version      Installation Source
--------------------------------------------------------------------------------
aspire                     8.2.0/8.0.100         SDK 8.0.400, VS 17.11.35222.181

Here is all my visual studio info:
Microsoft Visual Studio Community 2022
Version 17.11.2
VisualStudio.17.Release/17.11.2+35222.181
Microsoft .NET Framework
Version 4.8.09032

Installed Version: Community

ADL Tools Service Provider   1.0
This package contains services used by Data Lake tools

ASA Service Provider   1.0

ASP.NET and Web Tools   <IP_ADDRESS>983
ASP.NET and Web Tools

Azure App Service Tools v3.0.0   <IP_ADDRESS>983
Azure App Service Tools v3.0.0

Azure Data Lake Tools for Visual Studio   2.6.5000.0
Microsoft Azure Data Lake Tools for Visual Studio

Azure Functions and Web Jobs Tools   <IP_ADDRESS>983
Azure Functions and Web Jobs Tools

Azure Stream Analytics Tools for Visual Studio   2.6.5000.0
Microsoft Azure Stream Analytics Tools for Visual Studio

C# Tools   4.11.0-3.24376.4+5e3a11e2e7f952da93f9d35bd63a2fa181c0608b
C# components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Common Azure Tools   1.10
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.

Fabric.ApplicationInsights   1.0
Allows user to instrument their Service Fabric projects for Application Insights.

GitHub Copilot   0.2.1634.3922
GitHub Copilot is an AI pair programmer that helps you write code faster and with less work.

Microsoft Azure Hive Query Language Service   2.6.5000.0
Language service for Hive query

Microsoft Azure Stream Analytics Language Service   2.6.5000.0
Language service for Azure Stream Analytics

Microsoft Azure Tools for Visual Studio   2.9
Support for Azure Cloud Services projects

Microsoft JVM Debugger   1.0
Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual Machines

NuGet Package Manager   6.11.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit https://docs.nuget.org/

Razor (ASP.NET Core)   <IP_ADDRESS>2001+68650a7d94261bc56a1f4bc522c2ee35314b1abb
Provides languages services for ASP.NET Core Razor.

SQL Server Data Tools   <IP_ADDRESS>
Microsoft SQL Server Data Tools

ToolWindowHostedEditor   1.0
Hosting json editor into a tool window

TypeScript Tools   17.0.30715.2002
TypeScript Tools for Microsoft Visual Studio

Visual Basic Tools   4.11.0-3.24376.4+5e3a11e2e7f952da93f9d35bd63a2fa181c0608b
Visual Basic components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Visual F# Tools   17.11.0-beta.24317.3+c07c8ebad62f6629b36349381991a299598a8d74
Microsoft Visual F# Tools

Visual Studio IntelliCode   2.2
AI-assisted development for Visual Studio.

Do you have any updates available?

No, I don't.
I've also uploaded my codebase to the repo here - https://github.com/mithileshz/AspireApp1

I've tried uninstalling, reinstalling VS, also done a repair. My dotnet workloads are also up to date.
If I run dotnet run in terminal without the connection to Visual studio, I get the information about the dashboard and when I try log in, it gives me a 400. For (https://localhost:17207/login?t=9d56afcdf8f1986f38da48107a8312b1) link

Bad Request - Invalid Hostname
HTTP Error 400. The request hostname is invalid.

Very strange. What version of visual studio works? (the other PC)
cc @vijayrkn any ideas?

Microsoft Visual Studio Community 2022
Version 17.11.0 Preview 6.0
VisualStudio.17.Preview/17.11.0-pre.6.0+35125.118
Installed Version: Community
This is the version that's working. Let me try to install the same one on my broken machine and see if that helps.

Here's any extra information if it helps. When running dotnet run through cmd on the AppHost project, it doesn't have the same error as the initial one (failed to connect to IDE run session). It doesn't give any errors. However, when I click on the link to open the dashboard, I get the following in the browser.
Bad Request - Invalid Hostname

HTTP Error 400. The request hostname is invalid.

Here is the XHR:
{
  "log": {
    "version": "1.2",
    "creator": {
      "name": "Firefox",
      "version": "130.0"
    },
    "browser": {
      "name": "Firefox",
      "version": "130.0"
    },
    "pages": [
      {
        "id": "page_1",
        "pageTimings": {
          "onContentLoad": -12386,
          "onLoad": 756
        },
        "startedDateTime": "2024-09-11T21:22:45.076+01:00",
        "title": "https://localhost:17230/login?t=77291f2e389a09a26ca12df35537e203"
      }
    ],
    "entries": [
      {
        "startedDateTime": "2024-09-11T21:22:45.076+01:00",
        "request": {
          "bodySize": 0,
          "method": "GET",
          "url": "https://<IP_ADDRESS>:17230/login?t=77291f2e389a09a26ca12df35537e203",
          "httpVersion": "",
          "headers": [
            {
              "name": "Host",
              "value": "<IP_ADDRESS>:17230"
            },
            {
              "name": "User-Agent",
              "value": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:130.0) Gecko/20100101 Firefox/130.0"
            },
            {
              "name": "Accept",
              "value": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/png,image/svg+xml,*/*;q=0.8"
            },
            {
              "name": "Accept-Language",
              "value": "en-GB,en;q=0.5"
            },
            {
              "name": "Accept-Encoding",
              "value": "gzip, deflate, br, zstd"
            },
            {
              "name": "Connection",
              "value": "keep-alive"
            },
            {
              "name": "Upgrade-Insecure-Requests",
              "value": "1"
            },
            {
              "name": "Sec-Fetch-Dest",
              "value": "document"
            },
            {
              "name": "Sec-Fetch-Mode",
              "value": "navigate"
            },
            {
              "name": "Sec-Fetch-Site",
              "value": "cross-site"
            },
            {
              "name": "Priority",
              "value": "u=0, i"
            },
            {
              "name": "Pragma",
              "value": "no-cache"
            },
            {
              "name": "Cache-Control",
              "value": "no-cache"
            }
          ],
          "cookies": [],
          "queryString": [
            {
              "name": "t",
              "value": "77291f2e389a09a26ca12df35537e203"
            }
          ],
          "headersSize": 564
        },
        "response": {
          "status": 0,
          "statusText": "",
          "httpVersion": "",
          "headers": [],
          "cookies": [],
          "content": {
            "mimeType": "",
            "size": 0,
            "encoding": "base64",
            "text": ""
          },
          "redirectURL": "",
          "headersSize": 0,
          "bodySize": 0
        },
        "cache": {},
        "timings": {
          "blocked": -1,
          "dns": 2066,
          "connect": 0,
          "ssl": 0,
          "send": 0,
          "wait": 0,
          "receive": 0
        },
        "time": 2066,
        "_securityState": "insecure",
        "pageref": "page_1"
      },
      {
        "startedDateTime": "2024-09-11T21:23:01.604+01:00",
        "request": {
          "bodySize": 0,
          "method": "GET",
          "url": "https://localhost:17230/login?t=77291f2e389a09a26ca12df35537e203",
          "httpVersion": "HTTP/2",
          "headers": [
            {
              "name": "Host",
              "value": "localhost:17230"
            },
            {
              "name": "User-Agent",
              "value": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:130.0) Gecko/20100101 Firefox/130.0"
            },
            {
              "name": "Accept",
              "value": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/png,image/svg+xml,*/*;q=0.8"
            },
            {
              "name": "Accept-Language",
              "value": "en-GB,en;q=0.5"
            },
            {
              "name": "Accept-Encoding",
              "value": "gzip, deflate, br, zstd"
            },
            {
              "name": "Connection",
              "value": "keep-alive"
            },
            {
              "name": "Upgrade-Insecure-Requests",
              "value": "1"
            },
            {
              "name": "Sec-Fetch-Dest",
              "value": "document"
            },
            {
              "name": "Sec-Fetch-Mode",
              "value": "navigate"
            },
            {
              "name": "Sec-Fetch-Site",
              "value": "none"
            },
            {
              "name": "Sec-Fetch-User",
              "value": "?1"
            },
            {
              "name": "Priority",
              "value": "u=0, i"
            },
            {
              "name": "Pragma",
              "value": "no-cache"
            },
            {
              "name": "Cache-Control",
              "value": "no-cache"
            }
          ],
          "cookies": [],
          "queryString": [
            {
              "name": "t",
              "value": "77291f2e389a09a26ca12df35537e203"
            }
          ],
          "headersSize": 578
        },
        "response": {
          "status": 400,
          "statusText": "",
          "httpVersion": "HTTP/2",
          "headers": [
            {
              "name": "content-type",
              "value": "text/html"
            },
            {
              "name": "date",
              "value": "Wed, 11 Sep 2024 20:23:01 GMT"
            },
            {
              "name": "server",
              "value": "Kestrel"
            },
            {
              "name": "content-length",
              "value": "334"
            },
            {
              "name": "X-Firefox-Spdy",
              "value": "h2"
            }
          ],
          "cookies": [],
          "content": {
            "mimeType": "text/html",
            "size": 334,
            "text": "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01//EN\"\"http://www.w3.org/TR/html4/strict.dtd\">\r\n<TITLE>Bad Request</TITLE>\r\n<META HTTP-EQUIV=\"Content-Type\" Content=\"text/html; charset=us-ascii\">\r\n
Bad Request - Invalid Hostname
\r\n

HTTP Error 400. The request hostname is invalid.
\r\n"
          },
          "redirectURL": "",
          "headersSize": 135,
          "bodySize": 469
        },
        "cache": {},
        "timings": {
          "blocked": -1,
          "dns": 0,
          "connect": 513,
          "ssl": 32,
          "send": 0,
          "wait": 42,
          "receive": 0
        },
        "time": 587,
        "_securityState": "secure",
        "serverIPAddress": "<IP_ADDRESS>",
        "connection": "17230",
        "pageref": "page_1"
      },
      {
        "startedDateTime": "2024-09-11T21:23:02.592+01:00",
        "request": {
          "bodySize": 0,
          "method": "GET",
          "url": "https://localhost:17230/favicon.ico",
          "httpVersion": "HTTP/2",
          "headers": [
            {
              "name": "Host",
              "value": "localhost:17230"
            },
            {
              "name": "User-Agent",
              "value": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:130.0) Gecko/20100101 Firefox/130.0"
            },
            {
              "name": "Accept",
              "value": "image/avif,image/webp,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5"
            },
            {
              "name": "Accept-Language",
              "value": "en-GB,en;q=0.5"
            },
            {
              "name": "Accept-Encoding",
              "value": "gzip, deflate, br, zstd"
            },
            {
              "name": "Connection",
              "value": "keep-alive"
            },
            {
              "name": "Referer",
              "value": "https://localhost:17230/login?t=77291f2e389a09a26ca12df35537e203"
            },
            {
              "name": "Sec-Fetch-Dest",
              "value": "image"
            },
            {
              "name": "Sec-Fetch-Mode",
              "value": "no-cors"
            },
            {
              "name": "Sec-Fetch-Site",
              "value": "same-origin"
            },
            {
              "name": "Priority",
              "value": "u=6"
            },
            {
              "name": "Pragma",
              "value": "no-cache"
            },
            {
              "name": "Cache-Control",
              "value": "no-cache"
            },
            {
              "name": "TE",
              "value": "trailers"
            }
          ],
          "cookies": [],
          "queryString": [],
          "headersSize": 534
        },
        "response": {
          "status": 400,
          "statusText": "",
          "httpVersion": "HTTP/2",
          "headers": [
            {
              "name": "content-type",
              "value": "text/html"
            },
            {
              "name": "date",
              "value": "Wed, 11 Sep 2024 20:23:01 GMT"
            },
            {
              "name": "server",
              "value": "Kestrel"
            },
            {
              "name": "content-length",
              "value": "334"
            },
            {
              "name": "X-Firefox-Spdy",
              "value": "h2"
            }
          ],
          "cookies": [],
          "content": {
            "mimeType": "text/html",
            "size": 334,
            "text": "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01//EN\"\"http://www.w3.org/TR/html4/strict.dtd\">\r\n<TITLE>Bad Request</TITLE>\r\n<META HTTP-EQUIV=\"Content-Type\" Content=\"text/html; charset=us-ascii\">\r\n
Bad Request - Invalid Hostname
\r\n

HTTP Error 400. The request hostname is invalid.
\r\n"
          },
          "redirectURL": "",
          "headersSize": 135,
          "bodySize": 469
        },
        "cache": {},
        "timings": {
          "blocked": -1,
          "dns": 0,
          "connect": 0,
          "ssl": 0,
          "send": 0,
          "wait": 4,
          "receive": 0
        },
        "time": 4,
        "_securityState": "secure",
        "serverIPAddress": "<IP_ADDRESS>",
        "connection": "17230",
        "pageref": "page_1"
      }
    ]
  }
}

Here is the output of dotnet run

info: Aspire.Hosting.DistributedApplication[0]
      Aspire version: 8.2.0+75fdcff28495bdd643f6323133a7d411df71ab70
info: Aspire.Hosting.DistributedApplication[0]
      Distributed application starting.
info: Aspire.Hosting.DistributedApplication[0]
      Application host directory is: {REDACTED}AppHost
info: Aspire.Hosting.DistributedApplication[0]
      Now listening on: https://localhost:17230
info: Aspire.Hosting.DistributedApplication[0]
      Login to the dashboard at https://localhost:17230/login?t=b83f990577356a834d9483a2dcfddcc4
info: Aspire.Hosting.DistributedApplication[0]
      Distributed application started. Press Ctrl+C to shut down.

Bad Request - Invalid Hostname

HTTP Error 400. The request hostname is invalid.

Can you share a screenshot of this?

This looks like a proxy on your machine doing some blocking of traffic.

I've checked any proxies running with the chrome://net-export/ tool (using this guide), it doesn't mention anything. I don't have any proxies configured in my windows settings either, so I am not sure where it is picking up a proxy from? Any idea or tools on

running netsh winhttp show proxy in terminal returns:
Current WinHTTP proxy settings:

    Direct access (no proxy server).

Do you have fiddler?

I do not, I can install it if it will provide extra info?

Nope I’m just wondering what is returning that bad request page. It’s likely not the dashboard.

So apparently the only thing that fixed this was a windows reinstall. Not really sure what the issue was.

I am sorry we could not get to the bottom of it, but I am glad you are finally unblocked.


feat: use fetchApi core plugin for Buildkite API client

:heavy_check_mark: Checklist

[ ] Added tests for new functionality and regression tests for bug fixes
[ ] Added changeset (run yarn changeset in the root)
[ ] Screenshots of before and after attached (for UI changes)
[ ] Added or updated documentation (if applicable)

@alecjacobs5401 and I are pretty sure this will make the frontend client behave and properly attach authentication to the fetch() calls made to /proxy. this is probably busted for anyone currently gating backend plugins with auth (like us)

Nice spot! Yes it shouldn't work at the current state thanks for this PR.
Could you pls add a changeset?
in the root of the repo run:
yarn changeset

I think a patch bump should be good for this one.
And regarding the CI tsc failed because you'll need to add the new dependency in the test also. You should be able to get a   MockFetchApi from the @backstage/test-utils package

Thank you for the quick response!
My teammate, @alecjacobs5401, is going to pick this up for us and address your feedback 🙏

Hey @kissmikijr - made the requested changes you suggested!

Thank you for this work!


Feature Request: Add support for MDX Files

I tried to apply a status in an mdx file with the following syntax.
<Meta title="Style Guide/Colors" parameters="{{ status: 'stable' }}"/>

This didn't work, is the add-on missing support for it?

My bad...
This works.
<Meta title="Style Guide/Colors" parameters={{ status: 'stable' }} />

Phew! Good spot


Web based editor

While the Octopress targeted more towards 'hackers', a web based UI for creating or editing entries would be handy. This could take form of a sister project, if one does not already exist.

:+1:

I think this feature would not happen, because it is not the way for hackers to write blog.

Take a look at MeetHyde. https://github.com/MeetHyde/MeetHyde

Take a look at https://tinypress.co/ it's a web-based editor for a Jekyll powered blog hosted on GH.

You can also use editors like dillinger if you want to work online or, with some customization tools like Ulysses.
Googling Markdown Editor gives plenty of possible solutions.

All look good. MeetHyde looks closer to what I am thinking, since it means you can host the UI on your own setup.
As for the "it won't happen" comment, it doesn't need to happen as part of the core Octopress project and I am sure the interest of Octopress is not limited to hackers, even if that is the focus user base? This is partly why I suggested a sister project or 'compatible' third-party project, so it wouldn't burden the main project. As a website owner my focus is reduce the DB as the Achilles heel to upgrades.


:cdo does not abort on error (and the test for it seems wrong)

Describe the bug
:cdo is expected to stop when it encounters an error. As far as I (and others) can tell, it does not.
Additionally, the test for this seems, well, broken:
" If the executed command fails, then the operation should be aborted
enew!
let subst_count = 0
exe "silent!" . Xdo . " s/Line/xLine/ | let subst_count += 1"
if subst_count != 1 || getline('.') != 'xLine1'
  call add(v:errors, 'Abort command on error test failed')
endif

I cannot see how the given :cdo command is expected to fail performing the substitute; further, the test actually wants it to succeed, and only "fails" if the substitute is not done! This to me is not "abort on failure" but rather "succeeds at this particular substitute operation."
To Reproduce
Detailed steps to reproduce the behavior:

Run vim --clean (or gvim --clean, etc.)
:help :cdo
:vimgrep /cdo/ %
:cdo norm! cwtest
:messages to see far more than just one error; if you check :cc, you'll see we are not stuck on the first location, but have traversed the entire list.

Environment (please complete the following information):

Vim version (below)
OS: macOS 10.14.5
Terminal: Terminal.app combined with tmux

VIM - Vi IMproved 8.1 (2018 May 18, compilé Aug 16 2019 02:18:16)
Version macOS
Rustines incluses : 1-1850
Compilé par Homebrew
Énorme version sans interface graphique.
  Fonctionnalités incluses (+) ou non (-) :
+acl               -farsi             -mouse_sysmouse    -tag_any_white
+arabic            +file_in_path      +mouse_urxvt       -tcl
+autocmd           +find_in_path      +mouse_xterm       +termguicolors
+autochdir         +float             +multi_byte        +terminal
-autoservername    +folding           +multi_lang        +terminfo
-balloon_eval      -footer            -mzscheme          +termresponse
+balloon_eval_term +fork()            +netbeans_intg     +textobjects
-browse            +gettext           +num64             +textprop
++builtin_terms    -hangul_input      +packages          +timers
+byte_offset       +iconv             +path_extra        +title
+channel           +insert_expand     +perl              -toolbar
+cindent           +job               +persistent_undo   +user_commands
-clientserver      +jumplist          +postscript        +vartabs
+clipboard         +keymap            +printer           +vertsplit
+cmdline_compl     +lambda            +profile           +virtualedit
+cmdline_hist      +langmap           -python            +visual
+cmdline_info      +libcall           +python3           +visualextra
+comments          +linebreak         +quickfix          +viminfo
+conceal           +lispindent        +reltime           +vreplace
+cryptv            +listcmds          +rightleft         +wildignore
+cscope            +localmap          +ruby              +wildmenu
+cursorbind        +lua               +scrollbind        +windows
+cursorshape       +menu              +signs             +writebackup
+dialog_con        +mksession         +smartindent       -X11
+diff              +modify_fname      -sound             -xfontset
+digraphs          +mouse             +spell             -xim
-dnd               -mouseshape        +startuptime       -xpm
-ebcdic            +mouse_dec         +statusline        -xsmp
+emacs_tags        -mouse_gpm         -sun_workshop      -xterm_clipboard
+eval              -mouse_jsbterm     +syntax            -xterm_save
+ex_extra          +mouse_netterm     +tag_binary
+extra_search      +mouse_sgr         -tag_old_static
         fichier vimrc système : "$VIM/vimrc"
     fichier vimrc utilisateur : "$HOME/.vimrc"
 2me fichier vimrc utilisateur : "~/.vim/vimrc"
      fichier exrc utilisateur : "$HOME/.exrc"
 fichier de valeurs par défaut : "$VIMRUNTIME/defaults.vim"
               $VIM par défaut : "/usr/local/share/vim"
Compilation : clang -c -I. -Iproto -DHAVE_CONFIG_H   -DMACOS_X -DMACOS_X_DARWIN  -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Édition de liens : clang   -L. -fstack-protector-strong -L/usr/local/lib -L/usr/local/opt/libyaml/lib -L/usr/local/opt/openssl/lib -L/usr/local/opt/readline/lib  -L/usr/local/lib -o vim        -lncurses -liconv -lintl -framework AppKit  -L/usr/local/opt/lua/lib -llua5.3 -mmacosx-version-min=10.14 -fstack-protector-strong -L/usr/local/lib  -L/usr/local/Cellar/perl/5.30.0/lib/perl5/5.30.0/darwin-thread-multi-2level/CORE -lperl -lm -lutil -lc  -L/usr/local/opt/python/Frameworks/Python.framework/Versions/3.7/lib/python3.7/config-3.7m-darwin -lpython3.7m -framework CoreFoundation  -lruby.2.6

The :cdo command stops when there is an error in switching to the next buffer after making
changes to the current buffer. In this it behaves similar to the :bufdo, :windo, tabdo, argdo,
and :cfdo commands. The difference is that those commands run once for each buffer in the
list. But the :cdo command runs for each entry in the list (multiple times for the same buffer).
The above referenced test behaves as expected. The :cdo command fails because the buffer is
not saved after making changes to the buffer. So the command is not able to edit the
next buffer in the list.
In the case of help buffers, as they are readonly, the command is able to switch to the
next buffer, even though it is not able to make the changes. So the command runs
through all the entries.

@yegappan thanks for the comparison to the other do commands, for the explanation of the test, and for demonstrating that that definition of :cdo explains basically all the behavior.
It is still unexpected behavior, and here is why:
:help :cdo

<			When the current file can't be |abandon|ed and the [!]
			is not present, the command fails.
			When an error is detected execution stops.
			The last buffer (or where an error occurred) becomes
			the current buffer.

I see where you might have a point re: abandoning buffers. But the help says: "When an error is detected execution stops." Does this mean an error in :cdo (like the aforementioned abandon failure)? Or does this mean an error in {cmd} given to :cdo? Most users (myself included) seem to believe it's the latter—are you clarifying it is the former? Either way, we must update the help to be unambiguous (and it may be more useful to use the latter as actual behavior, given that :cdo operates at each entry, like :global (which, in fact, stops at the first error)).

@yegappan Thanks for the explanation.
IIUC, cdo stops execution if and only if last entry in a buffer that make changes cause an error.
In another word, if an error happens,  the current buffer after cdo might not be the error buffer, the only way to locate the entry that cause an error after cdo is to go through the message ?

Describe the bug
:cdo is expected to stop when it encounters an error. As far as I (and others) can tell, it does not.
Additionally, the test for this seems, well, broken:
" If the executed command fails, then the operation should be aborted
enew!
let subst_count = 0
exe "silent!" . Xdo . " s/Line/xLine/ | let subst_count += 1"
if subst_count != 1 || getline('.') != 'xLine1'
  call add(v:errors, 'Abort command on error test failed')
endif

I cannot see how the given :cdo command is expected to fail performing the substitute; further, the test actually wants it to succeed, and only "fails" if the substitute is not done! This to me is not "abort on failure" but rather "succeeds at this particular substitute operation."
To Reproduce
Detailed steps to reproduce the behavior:

Run vim --clean (or gvim --clean, etc.)
:help :cdo
:vimgrep /cdo/ %
:cdo norm! cwtest
:messages to see far more than just one error; if you check :cc, you'll see we are not stuck on the first location, but have traversed the entire list.

I would say this works as intended, since it's the same as with other
commands that loop over a list.  But the documentation should say:
When going to the next entry fails execution stops.

This is so it doesn't get stuck in one position and loop forever.
If you use ":argdo s/xxx/yyy" you get as many failures as you have
arguments.
--
ARTHUR:       Now stand aside worthy adversary.
BLACK KNIGHT: (Glancing at his shoulder) 'Tis but a scratch.
ARTHUR:       A scratch?
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

@brammool I would appreciate a correction to the documentation.
That said, I understand why argdo, bufdo, cfdo, &c. stop on failures in a single buffer (file).
But cdo is far more like global—shouldn't it stop on the first entry that errors? (This probably all applies to ldo too, but I imagine they share some code in the implementation, so I'm ignoring that for now.)

@yegappan The patch posted to the mailing list gives global-like behavior (stopping at the first error).