text:
Some tests fail if stdin is redirected

Steps to reproduce
Run the tests with > /dev/null
Expected behavior
All the tests passes
Actual behavior
https://salsa.debian.org/ruby-team/capistrano/-/jobs/304495

This is a problem that we've found on Debian a little but more than 1 year ago, I didn't report it earlier because it doesn't look serious.
Some of the tests fail under our testing environment, probably because of input redirection, I started a thread on the ruby team to talk about it and this was the reply I've got from one of the team members:
I tried locally: with a simple `gbp buildpackage` the tests pass
consistently. Under sbuild, however, they fail consistently.

Looking at the failure messages, it looks like the failing tests are
somehow poking at stdin. one difference between a simple `gbp
buildpackage` and sbuild is that on the first one stdin is left alone,
while under sbuild stdin is redirected.

tried `gbp buildpackage < /dev/null` and it fails consistently

the problem seems to be in lib/capistrano/configuration/question.rb,
method `gets`. if I remove the `return unless $stdin.tty?` from there,
the tests that failed before with `< /dev/null` now pass, but then there
is a test for that specific behaviour that now fails. I think this is
something to discuss with upstream. the key to reproduce is just to run
the tests with `> /dev/null`

You can see the log of the failures here:
https://salsa.debian.org/ruby-team/capistrano/-/jobs/304495
And the patch we apply on Debian to circumvent that (disable the failing tests):
https://salsa.debian.org/ruby-team/capistrano/blob/fcd89e1042db23548771112abb8b5daabf32fc5c/debian/patches/skip_tests.patch
Thanks for making capistrano!

Thanks for the detailed report! First impression, we could make a slight change to question.rb so that $stdin could be substituted with another object for the purpose of unit testing. I'll investigate that.

I'd be curious if there was a way of wrapping the test execution in a bash instance so that it has a tty available…

What do you think of this fix? https://github.com/capistrano/capistrano/pull/2033

I added them and some tests stopped failing (13 vs 7 failures):
https://salsa.debian.org/ruby-team/capistrano/-/jobs/306437
The 7 failures are all like:
expected block to output SOMETHING to stdout, but output "\nGems\n"
So I wonder if the left ones are not related to the stdin difference but rather to something that debhelper is doing with ruby packages and its relation with gems/deps.
What do you think?
Thanks for your fast response and quick proposed solutions :)

@samueloph could you open a new issue for the "\nGems\n" errors? This seems like a slightly different problem (stdout vs stdin 🙂). What would really help is if you could document a simple way to reproduce the error. With the stdin problem I could reproduce by running the tests with < /dev/null. For the stdout case I am not sure how to trigger that.

@mattbrictson of course, I'm gonna gather more information about the stdout problem and then I'm gonna open a new issue for that one.
Thank you!

Took a look at other failures, and it looks like its related the way debhelper deals with ruby and its gems, it's doesn't look like it's gonna affect anything and I will disable these tests.
Thanks,

authors: mattbrictson samueloph will-in-wi

repo: capistrano/capistrano


text:
Prevent Creation of Dashboard with same name.

Different users can create dashboard with same name. The System should prevent that and api should return an error code(400 Bad Request) with helpful message.

Fixed with https://github.com/capitalone/Hygieia/pull/853

source: gharchive/issue

repo: capitalone/Hygieia

license_type: permissive

license_source: github-api


text:
ASG network-location filter errors when filtering with security-group

The network-location filter errors out when checking against an ASG and you use a condition of compare: ["resource","security-group"].  The relevant parts of the dump are (line numbers relate to released version 0.8.28.2, the same error also happens with code currently in the repo):
  File "c:\python27\lib\site-packages\c7n\filters\vpc.py", line 117, in process
    related_sg = self.sg.get_related(resources)
  File "c:\python27\lib\site-packages\c7n\filters\related.py", line 53, in get_related
    related_ids = self.get_related_ids(resources)
  File "c:\python27\lib\site-packages\c7n\resources\asg.py", line 132, in get_related_ids
    cfg = self.configs.get(asg['LaunchConfigurationName'])
AttributeError: 'NoneType' object has no attribute 'get'

The problem is that the self.configs object is not initialized before it is being used.  It seems that it is only initialized for a filter that is explicitly of type launch-config.  This may require conditionally initializing the LaunchConfigFilterBase class in the NetworkLocation class if an asg resource is being processed.

Thanks for the bug report Tim, I've pushed a fix for it here: #2665

I updated my local code base with the fix and still get the error, probably because the configs object has never been created.
File "<my-local-directory>\custodian\cloud-custodian\c7n\resources\asg.py", line 140, in get_related_ids
    cfg = self.configs.get(asg['LaunchConfigurationName'], {})
AttributeError: 'NoneType' object has no attribute 'get'

Ah gotcha, misread the initial comment, i'll close the existing pr and take a better look at what's going on. Thanks.

ok yeah, looks like we're using the get_related_ids function before we're initializing for the security-group filter in asg, i have a update that should fix this locally

authors: thisisshi tim-elliott

repo: capitalone/cloud-custodian


text:
Switch to use  component to list docker registery in router deployment

At the time of writing, clicking Docker Image Registry list in Turing UI leads to an error page. This happens because of "Maximum update depth exceeded" which happens usually as infinte re-rendering is blocked. While toggling the popover, the state re-rendering is causing infinte reload. I couldn't find any extra value addition in using "EuiPopover" over the simple EuiSuperSelect.
The MR fixes the issue by choosing switching from "EuiPopover" to use "EuiSuperSelect" component
Test plan - https://drive.google.com/file/d/1CLl-RoVwO8dhiDmv8YUMJRNT3IJdMiK3/view?usp=sharing (limited access)

Thanks for this PR! Hmm do you have any idea what's causing the infinite re-rendering? The popover's supposed to have an effect that's similar to what's shown in the video below:
https://github.com/user-attachments/assets/bf9078f1-a1d5-4b3d-90f6-36f862e22daf
You can take a look at the code snippet here corresponding to that part above (which looks super similar to what you're working on) and maybe you might figure out what's causing the popover to break 🤔

**deadlycoconuts ** commented Nov 14, 2024

@deadlycoconuts yeah valid point, I was unsuccessful cornering the setstate which is causing the exception. I suspect, the dropdown updates registry, on change of registry, it re-renders the parent component, but as mentioned I was not able to corner it. So I moved away to use "EuiSuperselect" which helped
Maximum update depth exceeded. This can happen when a component repeatedly calls setState inside componentWillUpdate or componentDidUpdate. React limits the number of nested updates to prevent infinite loops.
    at checkForNestedUpdates (http://localhost:3001/turing/static/js/vendors-node_modules_react-dom_index_js.chunk.js:23602:15)

Attaching more manual testing details for adding new registry

New registry could be configured from privateDockerRegistries config
Adding a new registry will look like - image
Successful deployment of router with new registry with publicly available docker image - link

hi @deadlycoconuts thanks for sharing the comments. I have addressed your comments with the latest commit. I have kept those open for you to take a look again. Thanks and let me know your thoughts in case there are any more to address!

Thanks a lot for addressing them! I think we're good to merge this PR! Once this is done we can cut a patch release like this one here https://github.com/caraml-dev/turing/releases/tag/v1.20.2!

source: gharchive/pull-request

authors: deadlycoconuts vinoth-gojek

repo: caraml-dev/turing


text:
Error page: UI/Vis design study

Wonil-Suh1 created the following on Aug 13:
User story
As a user, I need to be informed of the error that occurred and the next steps.
Notes
Acceptance criteria

[ ] multiple design directions have been produced
[ ] minimum two candidates have been presented to DGC design review
[ ] identified the final direction

Current design

Original issue: https://github.ibm.com/webstandards/digital-design/issues/1448

Latest design explorations with modified display-03 type.

An example - we could show the 2x grid behind the message like this.

One concept idea:
404 error happened because:

We made a mistake. Help us fix it.
You are looking for something greater. Let's work together to make it happen!

Duplicate

authors: jeffchew oliviaflory wonilsuhibm


text:
fix(leadspace-block): align to non-gutter grid

Related Ticket(s)
#4969
Description
Align leadspace-block to non-gutter grid
Changelog
New

use content-layout and content-layout__body to adjust alignment
add display: block to media component

Thanks for this Ari! Small thing – it looks like LinkList is misaligned for both versions
React

Web components

updated!


text:
fix(masthead-logo): accessibility issues with tabindex

Related Ticket(s)
#8345  #9422
Description
dds-masthead-logo had an unnessary tabindex causing issues with the accessibility checker.
I checked mobile and desktop tabbing and logo with/without tooltip seem to continue to function properly
Changelog
Removed

tabIndex

Checker is not identifying the issue now.

authors: ariellalgilmore gopinathan-n


text:
Contribution: City Icon Hamburg - Elbphilharmonie

1. Team name
IBM Studios Hamburg
2. Icon name
City Icons / Hamburg / Elbphilharmonie
3. Please briefly describe what the icon is supposed to represent and the use case(s) its being used for.
The alternative city icon is derived from the world famous Elbphilharmonie located at Hamburg harbour. It should be used for IBM Developer / IBM Garage location Hamburg.
4. Box Link
https://ibm.box.com/s/5z49kionp55gnhs3x9uy2tcpo8ypouph
5. Screen Shot

Close-up screen shot of the icon with the pixel grid turned on

Better. I like the one with arc that applied a thumbs up to. I think maybe the scalloped too is to steep. I also wonder if the bottom can reflect the panel structure more versus just single lines?

@mjabbink
Awesome - yeah I get what you say. I tried to be a little more natural also in terms of the lines. What about that?

I think maybe one more unit between top and bottom parts. I also think you can remove the details of the roff that are in the back
these details get fussy and close in when smaller

Are you using the right stroke weight? Should be .72pt. Also please reference other water to make sure you’re aligned in scale or the ends of the line being rounded.

Looks like water is rounded. You can download the master file here:
https://www.ibm.com/design/language/iconography/pictograms/design/#resources

@fabianklonsdorf somehow your last image is not appearing in the repo?

@fabianklonsdorf to do a final assessment can you place the pinto among 10 or so other city pictograms.

@mjabbink strange, just tried to edit a word.
yeah - used the 0.72px stroke weight and also used the water thats used in the pictogram master.
Will work on your other hints and provide the final assessment soon. :)

@fabianklonsdorf - will provide some additional feedback and we can then take the picto through the final stages + commit process.

@silviohajdin okay, I'll wait then for your additional feedback and will provide you then with the latest proposal. :)

@fabianklonsdorf - pls. consider the following:

• We're normally aiming for straight-on view, viewing from the ground/water level if showing the entire structure. Using that view, and looking at the straight-on reference photo above, it seems that you wouldn't even see the back 'spikes' on the roof. To Mike's point, these tend to plug in and lose clarity when the pictogram is used at smaller sizes. Recommend to remove back 'spikes' and only keep the front ones per your single-roof-outline studies above.
• Looking at our 'water' pictograms comparison, with your current treatment in the middle, consider adding some more separation between the water wave and the structure. This will give the pictogram more clarity and will convey that 'raising from the water' concept you're showing with the Elbphilharmonie, just like we're doing with the Stockholm pictogram immediately to the left of your treatment. Adding 1-2 unit wave separation would work well.
• As Mike already commented, adding another unit between the brick base and glass superstructure will help with clarity when used at smaller sizes.
• Additionally, if the available grid structure will allow for it, consider adding another unit between the 4 vertical 'pillar' lines to accentuate them better, especially when the pictogram is reduced.

@silviohajdin thank you for the great feedback. I did several iterations and came up with that one. Also put it into context with other city pictograms. I needed to work on the brick base as it looked a little weird when the water lines are under the brick base. Furthermore, I did some rework on the water in order to be visually pleasant and prevent distraction.
what do you think?

@silviohajdin sorry for the confusion. as I was seeing the png in github I saw, I need to change something.
What about that:

this could also work?

or should the basement better be made of same sized brick basement parts?

this would be also an option, but the base now looks a little like a piano, which is not the worst relation, as it's basically an opera house.

@fabianklonsdorf - good iterations, you can see how some of these simple interventions quickly bring essential features forward, and hold clarity well when the pictogram is scaled down to smaller sizes. As we always strive to be as true and as close to the chosen motif, a couple of remaining interventions would be great, and we'll then be ready to share with Mike for his final review:

• consider connecting the glass superstructure to the brick base by adding two inset verticals per screenshot above (otherwise the floating glass superstructure is kind of disconnected and literally detached from the base, which isn't true to the real building)
• connecting the top horizontal all the way across is great, like you did in the last iteration above, but using an earlier rendition from today, shown below - that one to me lends itself best as the basis for the final, connected version:

@fabianklonsdorf - one final observation - looking at the straight-on reference photo, the last / right-most roof 'spike' is only marginally lower than the third one. To that same point around being as true to the original as we can in our style and grid structure, consider accentuating that last spike.

@silviohajdin AWESOME! Thank you.
Based on your feedback, I connected the basement with the glass structure. Also I positioned the 3rd spike a little more like the reality.

Here with a few other pictograms.

@fabianklonsdorf - great, thanks for the tweaks. Please humor me and create the second version that connects the top of the brick structure into a single base/foundation for the glass superstructure, and we'll put both of these forward to Mike.
While the latest connected treatment works really well, it leaves impression (especially in larger views) that the glass superstructure is supported by stilts, which isn't the case in reality. We can call your final design above, version 'A', and the version per quick intervention below can be version 'B'. Please follow each version with the contextual depiction with other pictograms as you have it above, and we'll send it Mike's way for review and approval - thanks!

@silviohajdin awesome. Here are the two versions. Also both in context with some other pictograms. Let me know if you have more thoughts on that. :)

@fabianklonsdorf - great, thanks. @mjabbink please take a look at the two versions above; both now work well at smaller sizes and in the context of other pictos, with my slight preference for the version on the right as it's more true to the actual structure.

These work and probably agree the right one is best in the set as well as it being more true to the structure.
Is the roof line still too steep? The images of the actual architecture show the right side with a slight pitch than it increases as it goes towards the left side of the structure. Minor detail but a distinctive part of the roof

maybe it kills the drama of pictogram if we get to accurate but worth a try first.

@mjabbink cool, thanks for the feedback.

done. 👍

thanks @fabianklonsdorf who never sleeps :D
final thoughts @mjabbink ? a bit more tame but sill works nicely, and more true to the real thing.

I can go either way if Nefertiti’s not true

Maybe to tame. I prefer the previous

Great exploration though.

thanks @mjabbink - we have the winner @fabianklonsdorf in the previous, more dramatic rev below:

really nice work @fabianklonsdorf and a great motif choice - please generate the SVG per https://www.ibm.com/design/language/iconography/pictograms/contribute and attach it here.

@silviohajdin @mjabbink Awesome, thank you!
Attached, you'll find the SVG export. :)
2020-02-17_Carbon-Icon-HAM-Elphilharmonie.svg.zip
Feel free to reach out for any other comments. 👍

@joshblack is this in the wrong repo?

authors: fabianklonsdorf mjabbink silviohajdin vpicone

repo: carbon-design-system/carbon-icons


text:
Update contributing guide with release flow

Similar to https://github.com/carbon-design-system/carbon-components-svelte/pull/1627, this repo should:

Update CONTRIBUTING for consistency
Add steps on how to upgrade the icons dependency
Add a maintainers section on the release flow

Done via 39c797e


text:
feat(tutorial): complete step 5

http://carbon-tutorial-pablodotnet.mybluemix.net/

Done! Link in the description

repo: carbon-design-system/carbon-tutorial


text:
Services: Fetching lang/country from DDO always returning false

Detailed description

Describe in detail the issue you're having.

Even if the digitalData object is configured correctly, the logic in the LocaleAPI is always returning as false.

Is this a feature request (new component, new icon), a bug, or a general
issue?

bug

Is this issue related to a specific component?

LocaleAPI

What did you expect to happen? What happened instead? What would you like to
see changed?

Return lc and cc properly if the digitalData object is configured properly
Steps to reproduce the issue

Set digitalData.page.pageInfo.language to it-IT and digitalData.page.pageInfo.ibm.country to IT
Load the page with masthead/footer or dotcomshell
Notice that the masthead/footer is defaulting to us-EN

Additional information

Theoretically, the fallback should be the html lang attribute, and if that's configured to the corresponding language/locale, should load with that instead.
ibm-common.js will load in the digitalData object with us-EN if it is not configured properly.

Turns out was a configuration issue. I think the takeaway is that this should be more of a documentation update instead so that it's more clear on how the language is set on the page.

repo: carbon-design-system/ibm-dotcom-library


text:
Accessibility checker is not working correctly

What will this achieve?
Currently, some tests with potential violations are failing when they shouldn't.
We have an accessibility checker config stating to only fail on violations but clearly this isn't the case when running the test suites.
ibm-cloud-cognitive/packages/core/accessibility-checker/index.js
module.exports = {
  failLevels: ['violation'],
  policies: ['WCAG_2_1'],
};

To try to fix it @matthewgallo and I tried moving the achecker.js file to the root, since the #accessibility-at-ibm channel instructed us to.

When doing this, the potential violations went away, but now a bunch of component suites are failing their a11y checks

Will need to continue to look into this.

authors: AlexanderMelox elycheea

repo: carbon-design-system/ibm-products


text:
Allow Datagrid filters to render display labels

I am guessing we will need to change the filtering implementation a bit to improve the way the labels are displayed (sentence case + i18n) — but think business logic should be separated here — can discuss the approach to achieve this separately.
Seems like we are using accessor, column, and id for the filtering + filter summary labels, but may need a way to show displayed labels other than the identifier.
e.g. passwordStrength: normal should be displayed as Password strength: Normal.
May need a separate issue to address this for date (see comments), but we can use this issue to evaluate first in case they can be contained.

Filter summary

Where's the 'List all' chevron?
Label should match sentence case (first letter capitalized)

Originally posted by @sdignum in https://github.com/carbon-design-system/ibm-products/issues/2500#issuecomment-1343315181

[ ] Date format presented in the Filter panel are mm/dd/yyyy and in the tags formatted as dd/mm/yyyy

Originally posted by @My-Money29 in https://github.com/carbon-design-system/ibm-products/issues/2500#issuecomment-1801908211

Actually, I think this scenario may still be possible. I can open a separate issue for this as suggested!

https://github.com/carbon-design-system/ibm-products/issues/3899

authors: elycheea matthewgallo


text:
feat(ui): UI Error messages: generic error

Description
Show common error when unhandled error or exception occur.
Checklist before requesting a review
Issue ticket number and link

[x] This PR has a valid ticket number or issue: DTIS-1236

Testing & Validation

[x] This PR has been tested/validated in IOS, Android and browser.
[x] The code has been tested locally with test coverage match expectations.
[x] Added new Unit/Component testing (if relevant).

Security

[x] No secrets are being committed (i.e. credentials, PII)
[x] This PR does not have any significant security implications

Code Review

[x] There is no unused functionality or blocks of commented out code (otherwise, please explain below)
[x] In addition to this PR, all relevant documentation (e.g. Confluence) and architecture diagrams (e.g. Miro) were updated

Design Review

[x] If this PR contains changes to the UI, it has gone through a design review with UX Designer or Product owner.
[x] In case PR contains changes to the UI, add some screenshots to notice the differences

UI
IOS

Android

Revert action when error occur
https://github.com/user-attachments/assets/dce4ba57-0899-40dc-87ab-36b4dcec4a68

showing the error message is enough. In the videos I captured below, I think we should revert the last action (for example navigate back).

Done. I updated capture video on PR description. Please help me check.

repo: cardano-foundation/cf-identity-wallet


text:
Design document

Content
The first design document for our implementation. Superceeds #29.

@cardano-scaling/team-alba please give your high level feedback since I haven't polished all details. Thanks.

@djetchev I will address your comments, but do you have feedback about the overall structure first?

In addition to the points I mentioned in my review, I would like to add the following:

The protocol explanation sections could be more concise, referencing the relevant parts of the paper for additional details (as you've done in some parts).
The emphasis on the projects Peras, Leios, and Mithril should be reduced. Focusing too heavily on these projects makes it seem like ALBA is a protocol exclusively designed for and applicable to them. Instead, we should present ALBA in a more general context, highlighting its broader potential and flexibility. This approach would allow readers to better understand the protocol's capabilities and explore its boundaries.
The document's purpose should be articulated more clearly. For the introduction section, the Overview of ALBA could be more concise, and Applications of ALBA could adopt a broader perspective. Most importantly, the introductory paragraph should be more explanatory. It would be helpful to describe the document's structure, outlining what is covered in each section, the rationale for this organization, and the intended flow of information.
The roadmap should be more detailed and specific. We can collaborate to determine its exact content.
Success criteria should be included and connected to the roadmap. These criteria should be quantitative and provide clear benchmarks for evaluating the project's progress and outcomes.

authors: curiecrypt tolikzinovyev

repo: cardano-scaling/alba


text:
[React] Add redux, puzzle deletion UI/API

Exactly the same interface as the current site. For #251, depends on #253
Originally I wrote this UI without redux (mostly cuz I've never used it) but triggering things from inside the individual table cells (like opening a modal) was already getting complicated and there was no good way to make the UI reflect the changes instantly without waiting for a full refresh. So I bit the bullet and worked through some redux docs... I'm sure there's some unidiomatic or outright bad stuff in here.
There's a lotta boilerplate/scaffolding but hopefully now the other actions can just follow these patterns.

I kinda fucked up the git history here, moving to #256

repo: cardinalitypuzzles/smallboard

license: MIT


text:
Open card in right stack

Opens the search results card in stack in interact mode.
Implementation for a real card would be much easier. However, currently the only "card" we have displayed in chat is the CommandResult, which is actually a FieldDef and not a CardDef. It is a field of Command card, which is a generic card for commands. My approach: Create an unsaved SearchResult card and open it in the stack.
This involved adding @provide CardContext to the InteractSubmode component, since the necessary stack context actions live there.
Below is how the results card look. Would be nice to have a design for it.

Issues:

On refresh, we lose the card that opened in the stack. This is because it is not saved. (I noticed that the results embedded card in the chat also disappears as of the latest main.)
For some reason, the overlay works on each card but it is only visible on the last item. Investigating this.

I tried this locally and couldn’t find any cards listed:

but the cards are there, in code mode and can be visited via search

unsure if this is related to your PR or the general chaos of the repository but will look in more detail at your code

I see you pushed to the branch, I erased what I had and then it worked! 🎉

I tried this locally and couldn’t find any cards listed:
unsure if this is related to your PR or the general chaos of the repository but will look in more detail at your code

Sorry about that, it was certainly a strange a low point. Fixed now

Am I doing it wrong? I don’t get the type of listing in your screenshot:

The code looks good though I’ve so far failed to properly exercise it. This kind of workaround-ish special handling with it being unsaved sometimes worries me but I don’t have a suggestion of how it could work without it!

I agree. It would be better if we only implemented this for cards that actually exist in our database instead of trying to open a search results fielddef that is not saved

Am I doing it wrong? I don’t get the type of listing in your screenshot:

I noticed that the search prompts need some tweaking. You can try giving a more specific card type like "search for Product card type" and hopefully the query will have { eq: { _cardType: 'Product' }}

I noticed that the search prompts need some tweaking. You can try giving a more specific card type like "search for Product card type" and hopefully the query will have { eq: { _cardType: 'Product' }}

That worked, thanks!

Closing this as I have a different branch with the updated work

authors: backspace burieberry

repo: cardstack/boxel


text:
Rename "Popochiu" example game

This is trivial/low priority, but the example game inside the popochiu-dev repository is itself named "Popochiu" and sports the same string everywhere. This makes things a bit confusing for first-time contributors. It also makes it harder to search inside the repo (even if excluding the game folder is actually an easy solution).
The fact that  the engine's logo also matches the characters' apperance makes it worse :)
We can rename the example game and try to exclude the work "Popochiu" in it.

There is one thing that worries me about this. I'm using that popochiu folder to check if the plugin is ready to be used. When it is installed, the plugin creates the folder and put some files there (including PopochiuData.cfg, PopochiuSettings.tres, and PopochiuGlobals.gd). Then when Godot starts the plugin checks if the folder exists, and if it does, then it continues with all the logic for the Popochiu dock.
One option is to get rid of the popochiu folder and make all those configuration files and the folders for rooms, characters, inventory items and dialog trees to be in the project's root: res://.
Maybe another option is to ask devs how they want to name the folder and store that in the PopochiuData.cfg for later validations.

The game folder has been long renamed game and this is no more an issue. Closing

authors: mapedorr stickgrinder

repo: carenalgas/popochiu


text:
Ways to draw the map (and actors)

I know in no_rendering_mode.py you have a way to draw the map in pygame. I would like to ask the following questions concerning the drawing of the scene.

Is there any way to get the information of no_rendering_mode.py in a more standard way? Within the file you use things such a carla_map.get_topology() to get information about the map, shouldn't be with the opendrive standard?
With world.get_map().to_opendrive() I can get the map in the standard format of opendrive, is there a nice way to plot this info? (I cannot find any)
carla-ros-bridge seems to use opendrive in the topic /carla/map which is type string and not map, therefor it cannot be used in rviz (somehow related to the previous bullet point)
Is there any work on passing this information in a way such as ChauffeurNet for learning purposes?

Hi @silgon,

There has been some work on exporting all the useful info in no_rendering_mode.py as a Python dictionary (road layout, actor transforms, signals, etc); @manishthani and @felipecode, any updates?
Functions like get_topology, get_waypoint, etc. are part of our higher level API to navigate OpenDrive files. They are built exclusively on top of the OpenDrive file provided with the map. The information is exactly the same, we just convert it to something easier to digest for the common use cases (get closest waypoint, get next waypoints, get waypoint on the left, ...) so you don't need to parse the OpenDrive file yourself.
world.get_map().to_opendrive() dumps the *.xodr file as string (also save_to_disk), you can use any OpenDrive visualizer to view the road, e.g. OpenDRIVE Viewer. Alternatively, for a quick visualization with our API you can plot the waypoint locations, to generate waypoints everywhere use generate_waypoints(distance).

Hi, when I use an OpenDRIVE file as the map for Carla, the world.get_map().get_topology() will be empty. Do you know the reason?

Hi @silgon,

There has been some work on exporting all the useful info in no_rendering_mode.py as a Python dictionary (road layout, actor transforms, signals, etc); @manishthani and @felipecode, any updates?
Functions like get_topology, get_waypoint, etc. are part of our higher level API to navigate OpenDrive files. They are built exclusively on top of the OpenDrive file provided with the map. The information is exactly the same, we just convert it to something easier to digest for the common use cases (get closest waypoint, get next waypoints, get waypoint on the left, ...) so you don't need to parse the OpenDrive file yourself.
world.get_map().to_opendrive() dumps the *.xodr file as string (also save_to_disk), you can use any OpenDrive visualizer to view the road, e.g. OpenDRIVE Viewer. Alternatively, for a quick visualization with our API you can plot the waypoint locations, to generate waypoints everywhere use generate_waypoints(distance).

Hi, @nsubiron ,
when I use an OpenDRIVE file as the map for Carla, the world.get_map().get_topology() in global planner will be empty. Do you know the reason?

authors: MayDGT silgon

repo: carla-simulator/carla


text:
lane detection ground truth

Hello everyone,
i would like to implement a lane detection ground truth, which means that i would like to get the lane information, for example in waypoints, to generate labeled data containing the lane informations.
Are there already ways to do that or do you have idears?
My idea would it be to extract the opendrive waypoints. How can i get the Opendrive waypoints?
Is there a way to get the waypoints from the "RoutePlanner" Objects directly inside the unreal editor?
Best regards
Atlunch

I'm having the same problem, i want to generate the ground truth to train a lanenet model


text:
Navigating ego vehicle through custom waypoints

I'm trying to simulate some near-collision instances such as two vehicles passing close by. To do so, my plan was to setup two PID-controlled ego vehicles rigged with cameras navigating through custom waypoints in two adjacent lanes. These waypoints were to based on the waypoints already on the map and modified so that one set of waypoints comes closer to the other, as shown below.
            waypoints = world.get_map().get_waypoint(vehicle.get_location())
            waypoint = np.random.choice(waypoints.next(0.5))
            waypoint.transform.location.y += 1.5

However, it seems that the waypoints are static and cannot be modified (they are always right in the middle of a lane) as their transform is not affected as expected. Is there any other way of achieving this?
Thanks.

I'm trying to simulate some near-collision instances such as two vehicles passing close by. To do so, my plan was to setup two PID-controlled ego vehicles rigged with cameras navigating through custom waypoints in two adjacent lanes. These waypoints were to based on the waypoints already on the map and modified so that one set of waypoints comes closer to the other, as shown below.
            waypoints = world.get_map().get_waypoint(vehicle.get_location())
            waypoint = np.random.choice(waypoints.next(0.5))
            waypoint.transform.location.y += 1.5

However, it seems that the waypoints are static and cannot be modified (they are always right in the middle of a lane) as their transform is not affected as expected. Is there any other way of achieving this? Thanks.

"  Having the same issue as you described. May I know how did you resolve it. This is the link to my posted issue:https://github.com/carla-simulator/carla/issues/5516

@JunadMQ Sorry, wasn't able to do this. Tuning the PID parameters was the best I could do.

authors: JunadMQ TR-Monash


text:
Semantic Tags Out of Date in Documentation

The table of semantic tags in the documentation is currently out of date with the values defined in the source. Relevant lines linked.
https://github.com/carla-simulator/carla/blob/f14acb257ebf44c302b225b02080ac5f0eedcf7f/Docs/ref_sensors.md?plain=1#L715
https://github.com/carla-simulator/carla/blob/f14acb257ebf44c302b225b02080ac5f0eedcf7f/LibCarla/source/carla/rpc/ObjectLabel.h#L16.

I think now it is updated, could you check it again in our latest versions?

authors: Blyron wbridewell


text:
calculate the distance along route TS4

Descriptio
Use distance along route to activate scenario 04

This change is

Done