Improving newsroom code

Was working on https://github.com/lfph/lfph.io/issues/74 and noticed a few other issues with newsroom so decided to fix those along with a refactor/tidy.

Fixed default thumbnail issues so the SVG is centered https://github.com/lfph/lfph.io/issues/74
Changed aspect of images so scaling is improved and more consistent
Removed expanded view https://github.com/lfph/lfph.io/issues/73
Reworked the date + author line so it wraps nicely (for instance if authors name is long)
Amended "sticky"/featured skew tag
Slight amendments to columns and spacing within archive pages

I had to amend the LF MU plugin slightly, so if this is pulled in to live before this PR is merged default images may break (although I don't think there are any currently on LFPH)

Using the archive page:
Home (News) - https://pr-79-lfph.pantheonsite.io
Blog - https://pr-79-lfph.pantheonsite.io/blog/
In the News - https://pr-79-lfph.pantheonsite.io/news/
Search - https://pr-79-lfph.pantheonsite.io/?s=test
Need to regenerate thumbs though

Looks good.  Can you LMK when this is finalized and I'll do a final review and merge?

It looks like the dateline and byline are now on two different lines here whereas I think they look better on the same line as on the live site.

Ah not intentional, have reverted the styling for that. Anything else? (p.s. Pantheon issues seems to have borked the above e build)

CircleCI seems to be having issues with npm...

Do we need to regenerate thumbnails when we deploy?

Do we need to regenerate thumbnails when we deploy?

Yes, these image names have changed

newsroom-260
newsroom-325
newsroom-540
newsroom-600
newsroom-1200

# only missing (it should pick up the dimensions have changed)
terminus wp lfph.live -- media regenerate --only-missing --yes

# per image size (dont think you can do multiple)
terminus wp lfph.live -- media regenerate --image_size=newsroom-260 --yes
terminus wp lfph.live -- media regenerate --image_size=newsroom-325 --yes
terminus wp lfph.live -- media regenerate --image_size=newsroom-540 --yes
terminus wp lfph.live -- media regenerate --image_size=newsroom-600 --yes
terminus wp lfph.live -- media regenerate --image_size=newsroom-1200 --yes

# just do everything
terminus wp lfph.live -- media regenerate --yes


Cow: Watch upload.engrz

Cow requests the watch of the watch_keyword upload\.engrz. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

upload\.engrz has been seen in 3 true positives, 0 false positives, and 0 NAAs.

Approved by Nick in Charcoal HQ


go-charset github.com/rogpeppe/go-charset/charset/data

Building fails with util.go:20:2: cannot find package "github.com/rogpeppe/go-charset/charset/data" in any of...
But, don't hurry - there is plenty time until I need a new calendar 📆

Fixed a long time ago. Now we are using go.mod.


Fix invalid html anchor

What is the context of this PR?
Describe what you have changed and why, link to other PRs or Issues as appropriate.
The link to go to the previous page had a name attribute which is invalid html 5. Changed to be an id
How to review
Describe the steps required to test the changes (include screenshots if appropriate).
All tests pass
html is valid

@hamishtaplin could you review


Sticky Locks Removed - Bug

Sticky Locks Removed - Bug
Sticky locks are being removed after a deployment

Note: I'm just making note of this here and will update the issue later on

Replication

.lock to obtain a lock
.deploy and the lock gets removed after the successful deployment - this is a bug and sticky locks should not be removed in this manner

Does this bug affect previous releases or only the latest one?


Container has runAsNonRoot and image has non-numeric user(envoy-operator), cannot verify user in non-root

Resolved by adding user with numeric value add permission in Dockerfile it worked.


I cant't load my javascript pages - error

I recevied this post (when I try to read My Bins: "This page isn't here. How about heading back to the homepage instead? It's nice there and there are lots of things to click on. If you think there is supposed to be something here that isn't let us know via the Issues page". I see that there is 542 programs, but I can't read it. Please, help :)

I recevied this post (when I try to read My Bins: "This page isn't here. How about heading back to the homepage instead? It's nice there and there are lots of things to click on. If you think there is supposed to be something here that isn't let us know via the Issues page". I see that there is 542 programs, but I can't read it. Please, help :)

I recevied this post (when I try to read My Bins: "This page isn't here. How about heading back to the homepage instead? It's nice there and there are lots of things to click on. If you think there is supposed to be something here that isn't let us know via the Issues page". I see that there is 60 bins programs, but I can't open and do anything with it. Please, help :)

Hi dev team, same error for me. :)

I'm assuming xalosi/5/edit instead of https://jsbin.com/xalosi/5/edit in the My Bins view.

"Hey dev team" - this is me. I'm 100% jsbin and there's no one else. Just a reminder.
I'll fix this later today (8am atm).

Pretty sure this is the cause, triggering the URL to become absolute: https://github.com/jsbin/jsbin/commit/170ad3d169d8e8116d3aed950c1c06f074eff1a1#r25974640

Fixed in live.

Thank you!
Sent from my Samsung device
-------- Original message --------
From: Remy Sharp<EMAIL_ADDRESS>Date: 1/12/2017 9:52 PM (GMT+10:00)
To: jsbin/jsbin<EMAIL_ADDRESS>Cc: dermalplating<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [jsbin/jsbin] I cant't load my javascript pages - error (#3160)
Pretty sure this is the cause, triggering the URL to become absolute: 170ad3d#r25974640https://github.com/jsbin/jsbin/commit/170ad3d169d8e8116d3aed950c1c06f074eff1a1#r25974640
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/jsbin/jsbin/issues/3160#issuecomment-348430108, or mute the threadhttps://github.com/notifications/unsubscribe-auth/Aa6WzoaQOsgbmG1O_BiBVhVTE8N1Bs61ks5s77VGgaJpZM4QxCut.


feat: 1221 spz list endpoint modification

Description
Closes #1221
Changelog
New

None

Changed

/api/area-of-use/tested-parent-trees/spz-list is now/api/area-of-use/spz-list/vegetation-code/{vegCode} The old SPAR lets users select any spz they want then deny them once a user submits the data if it's invalid. This modified endpoint provides users with valid options to begin with so TSC admins should can age slower.
moved /api/orchards/area-of-use/spu/{spuId} under its own Area Of Use section as/api/area-of-use/spu/{spuId} so it makes more sense

Removed

None

How was this tested?

[ ] 🧠 Not needed
[x] 👀 Eyeball
[x] 🤖 Added tests

What gif/image best describes this PR or how it makes you feel?

Thanks for the PR!
Deployments, as required, will be available below:

Frontend
Backend
Oracle-API

Please create PRs in draft mode.  Mark as ready to enable:

Analysis Workflow

After merge, new images are deployed in:

Merge Workflow

thanks for the review @RMCampos, all issues should be addressed in this commit https://github.com/bcgov/nr-spar/pull/1225/commits/141103444da582adcccfe177485fb266d472fba9


minor css adjustments

resolves #5359

reduces line height and improves borders

@sbcgua i don't see the dark grey hover you have, which theme are you using?

Hover works fine with default theme. I also tested dark and belize.


Web interface does not respond with tornado 4.5.1 and bokeh 0.12.5

Upgrading from bokeh 0.12.4 to 0.12.5 pulled down version 4.5.1 of tornado. This caused the web ui to never respond. Rolling back to 0.12.4 and 4.4.3. has resolved it for me for now.
I replicated this on centos and OS X.

Apparently this is a known issue with tornado 4.5.1 and not related to dask! Apologies.

Thanks for reporting it on Github regardless.  You're certainly not the
only person that this will affect.  Hopefully others who come by will see
this issue and learn what's going on.
Thanks!
On Mon, Apr 24, 2017 at 3:03 PM, Samantha Hughes<EMAIL_ADDRESS>wrote:

Closed #2252 https://github.com/dask/dask/issues/2252.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask/issues/2252#event-1055380862, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AASszFdN0yiDIXi6BFQD2BQ9XpAeqV6Xks5rzPISgaJpZM4NGk1N
.

Reference of upstream Bokeh issue: https://github.com/bokeh/bokeh/issues/6152
The issue is fixed on Bokeh master and should therefore be solved once a new Bokeh version is released.

FYI conda installing 0.12.6 should now no longer allow tornado 4.5, the dependencies for the package in the defaults channel were updated to exclude it.


Notification on successful backup

Great work! You make an otherwise tedious backup task really simple.
I was wondering if it is somehow possible to automatically send notifications to an email address on successful (or failed) backups?

Hello please look here: #59. This repository is deprecated. No feature requests are accepted.

Please consult this in order to add your notifications: https://github.com/blacklabelops/volumerize#post-scripts-and-pre-scripts-prepost-strategies

Closed due to inactivity.


Reimplement Series.cov using prange

@kozlov-alexey adding test which reproduce the issue here https://github.com/IntelPython/sdc/pull/465


Refractor Search Use Case

Made both the input data and output data an interface instead of a class.
Has two unnecessary classes called CommonSearchRecipeOutputData and SearchRecipeResponseData
Does not follow Clean Architecture

Completed


Chrome 64 uses "text-decoration-skip-ink: auto" by default

https://www.chromestatus.com/feature/5631679087509504
Looks like this:

If #693 is approved then nothing needs to be changed.
Otherwise text-decoration-skip-ink: none can be added to remove the skips.

#693 was merged. Thanks

I would actually have preferred to set the default text-decoration-skip-ink style on links as 'none' for a couple reasons:

Leaving it up to the browser results in a number of different skip behaviours across all modern browsers, which I think defeats the purpose of using normalize.

Edge, IE, and Firefox won't have any gaps. Chrome uses 'ink' and has gaps on descenders. Safari uses 'skip' and has gaps, but I'm not sure if the behaviour is the same as 'ink' on Chrome.

Skipping text decoration on descenders (as Chrome now does by default) can make a single text link look like multiple text links. I think text-decoration-skip can be a nice typographic treatment for non-interactive text, but I don't think it should be applied by default to all links.

Agreed. Especially since there is already a way to make link underlines look pretty — by using border-bottom:

Agreed. Especially since there is already a way to make link underlines look pretty — by using border-bottom:
border-bottom breaks if a link spans over multiple lines though (i.e only the very bottom margin has a border).

@tomasz1986 That's not true for inline elements (like anchors are by default).
This post has some examples of ways to style "underlines":
https://css-tricks.com/styling-underlines-web/

That's not true for inline elements (like anchors are by default).

I stand corrected. I got confused when trying to use border-bottom on anchors set to inline-block and did not re-test it with default CSS properties.


Add example of monitoring existing tasks

Hi there @tylere and @gena,
I have made a task manager using ipywidgets, I am not sure if it is what this issue refers to, but you may want to have a look at it: https://github.com/gee-community/gee_tools/blob/aa7c75cce10111a0c75f2b4d508e617643bcd52e/geetools/ipytools.py#L241
It's in the develop brunch yet
Cheers


Create cask for 'ungoogled-chromium'

Checklist

[x] The commit message includes the cask’s name and version.
[x] brew cask audit --download {{cask_file}} is error-free.
[ ] brew cask style --fix {{cask_file}} left no offenses.

Additionally, when adding a new cask:

[x] Checked there are no open pull requests for the same cask.
[x] Checked there are no closed issues where that cask was already refused.
[ ] When naming the cask, followed the token reference.
[x] brew cask install {{cask_file}} worked successfully.
[x] brew cask uninstall {{cask_file}} worked successfully.

As per the token reference, this should be eloston-chromium.

Details of software names and brands will inevitably be lost in the conversion to a minimal token. To capture the vendor’s full name for a distribution, use the name within a Cask. name accepts an unrestricted UTF-8 string.

Though on this particular case, I was a bit ambivalente if it wasn’t worthy of an exception. I leaned towards “no”, though. This had a (somewhat) meteoric rise, but I wonder for its future. As I’ve seen pointed out, trading known evil (Google) for binaries made by an unknown third party is a dubious move. It’s not a bad idea, though, and it’s conceivable other projects like this might pop up in the future. Rather than treat “Ungoogled Chromium” as something special due to a catchy name (not saying this in a bad way), we should treat this as just another fork, just like freesmug-chromium, because in the end, that’s what it is.

Not sure what I'm doing wrong.
$ brew search ungoogled-chromium
No formula found for "ungoogled-chromium".
==> Searching pull requests...

Rather than treat “Ungoogled Chromium” as something special due to a catchy name (not saying this in a bad way), we should treat this as just another fork, just like freesmug-chromium, because in the end, that’s what it is.

It was added as eloston-chromium.


Duplicated tests for React.memo

Flow version: 0.102
Actual behavior
The tests in this file are duplicated. It looks like the second chunk is intended for MemoComponentWithEqual.
const MemoComponent = React.memo(Component);

const _a = <MemoComponent foo={3} />;
const _b = <MemoComponent />; // Error missing foo
const _c = <MemoComponent foo={3} bar={3} />; // Error extra bar
const _d = <MemoComponent foo="string" />; // Error wrong type for foo

const MemoComponentWithEqual = React.memo(Component, (props1, props2) => props1 === props2);

const _e = <MemoComponent foo={3} />;
const _f = <MemoComponent />; // Error missing foo
const _g = <MemoComponent foo={3} bar={3} />; // Error extra bar
const _h = <MemoComponent foo="string" />; // Error wrong type for foo

Only the tests look off, there is no issue about typing.

Good catch!

I'd like to give this a try :)
I've updated the components as well as the test exp files accordingly, and have managed to make the current test suite pass. I'm wondering, how should I test the with equal function?

Sorry, I must have missed this notification. Thanks for cleaning it up! The current tests seem fine to test it-- you can just replace _e -> _h with MemoComponentWithEqual. The idea is that providing the equality function shouldn't break type checking.

Fat fingered that, my b

Hey @jbrown215 I've pulled up the branch but noticed that there are some failed tests. They don't seem to be related with these changes though?

Which test was failing? CI looks like it's passing on master right now.

I realize that my tests are run on my earlier build of flow. But when I tried to rebuild flow, I ran into this error
File "src/server/protocol/socketHandshake.ml", line 1:
Error: The files src/stubs/flowEventLogger.cmi
       and src/monitor/serverStatus.cmi make inconsistent assumptions
       over interface FlowEventLogger
Command exited with code 2.
Compilation unsuccessful after building 89 targets (88 cached) in 00:00:02.
make: *** [build-flow] Error 10

So I tried to go through the installation steps again and I got a parse error from opam
[ERROR] File "/Users/wgao19/.opam/4.05.0/packages.dev/flowtype/opam", line 44, character 0-1: parse error.
[WARNING] Errors in opam file from flowtype source, ignored (fix with 'opam pin edit')

The .opam/4.05.0/packages.dev/flowtype/opam file looks like this

Sorry I'm really very inexperienced with this..

Try make clean

@goodmind thanks for the pointer, rebased and rebuilt and the test is passing now!

@wgao19 is this fixed?

Hi @goodmind yes it is fixed and I believe the PR has landed internally. Thanks again!


Cassandra metrics receiver

Cassandra metrics receiver first draft. As Cassandra is JVM/JMX based, there are no additional open telemetry receivers required for this integration.
Metrics collected are listed here: https://github.com/open-telemetry/opentelemetry-java-contrib/blob/main/jmx-metrics/docs/target-systems/cassandra.md
One possibly contentious aspect of this PR is that the Cassandra receiver can be configured to also collect JVM metrics via a configuration parameter (collect_jvm_metrics). I chose to allow this to be configurable, to give users more control over their metrics. If we want to simple always collect JVM metrics I can remove this configuration.

Per conversation about metrics, waiting on the following PRs to be ready.

https://github.com/open-telemetry/opentelemetry-java-contrib/pull/113
https://github.com/GoogleCloudPlatform/opentelemetry-operations-collector/pull/58


Make compatible for both common and module callers

Backend caller should be able to require or import the temp logger package.

I think the current problem preventing module callers is that the TS compiler is replacing all uses of the import method with require.
Promise.resolve().then(() => require('chalk'))


UVI Request

--- UVI JSON ---
{
  "vendor_name": "Linux",
  "product_name": "Kernel",
  "product_version": "versions from v5.6 to before v5.10.44",
  "vulnerability_type": "unspecified",
  "affected_component": "unspecified",
  "attack_vector": "unspecified",
  "impact": "unspecified",
  "credit": "",
  "references": [
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=59c324683400b41caa6d85b091e812ee3d5415c3",
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e0b518a2eb44d8a74c19e50f79a8ed393e96d634"
  ],
  "extended_references": [
    {
      "type": "commit",
      "value": "59c324683400b41caa6d85b091e812ee3d5415c3",
      "note": "introduced"
    },
    {
      "type": "commit",
      "value": "e0b518a2eb44d8a74c19e50f79a8ed393e96d634",
      "note": "fixed"
    }
  ],
  "reporter": "joshbressers",
  "reporter_id": 1692786,
  "notes": "",
  "description": "gpio: wcd934x: Fix shift-out-of-bounds error\n\nThis is an automated ID intended to aid in discovery of potential security vulnerabilities. The actual impact and attack plausibility have not yet been proven.\nThis ID is fixed in Linux Kernel version v5.10.44 by commit e0b518a2eb44d8a74c19e50f79a8ed393e96d634, it was introduced in version v5.6 by commit 59c324683400b41caa6d85b091e812ee3d5415c3. For more details please see the references link."
}
--- UVI JSON ---

This issue has been assigned UVI-2021-1000961


document: support env

We should add document about support env.

Currently, MSEdge does not work. maybe


Looks amazing, cant wait to see where it goes!

Looks good Pini!
I also have a few ideas for a RPi project but i am waiting until we move into our new house to start them. Maybe by then i can use this project as a template!

Thanks @AsternA ❤
Sure, feel free to use this repo as your template. Maybe I'll do it myself, create another skeleton project to fork as base for future projects.


HTTP redirect from https://www.instagram.com/graphql/query to https://www.instagram.com/accounts/login/

When i try to scrape some profile using python:
bot = instaloader.Instaloader()
bot.login('user', 'password')
profile = instaloader.Profile.from_username(bot.context, 'username')
I get this redirect
"HTTP redirect from https://www.instagram.com/graphql/query to https://www.instagram.com/accounts/login/ "
Why is this happening?
How can I solve it?

Try to change IP address
Probably banned

Thanks, I will try it.


Fix inferring fiducials from EEGLAB

Fixes #11641 (I can successfully load the files linked in this issue). However, he code is likely still dysfunctional, because we are currently searching for labels "Nasion", "Right periauricular point", and "Left periauricular point" (case sensitive). I am not sure if these names are even standardized, but "periauricular" seems to be a typo on our end, because I have only ever heard the term "preauricular".
But unless we know more about how fiducials are stored in EEGLAB files, we are stuck with what we have I guess.

Hmmm. Why does Sphinx not find mne.io.read_epochs_eeglab()?

but "periauricular" seems to be a typo on our end, because I have only ever heard the term "preauricular".

I've seen both -- periauricular shows up in the BIDS docs for example https://bids-specification.readthedocs.io/en/stable/04-modality-specific-files/02-magnetoencephalography.html

I don't think periauricular point is correct though. Peri = around, so this refers to the area around the ear, not a specific point. If we're talking about the fiducial point, I think only preauricular (pre = in front of) is correct.

I've seen both -- periauricular shows up in the BIDS docs for example https://bids-specification.readthedocs.io/en/stable/04-modality-specific-files/02-magnetoencephalography.html

The BIDS specs contain both terms, even on the same page … Clearly either these must be interchangeable or (probably most likely) people mis-type / mis-read these, as they're easy to confuse. In either case, it's always RPA and LPA that's meant.

I think they are interchangeable, as "peri" means "around", and "pre" means before -- and both terms apply to the point around/before the ear we are talking about


Error in TTS error description

The line is in a TTS class, but the error refers to STT:
https://github.com/huggingface/speech-to-speech/blob/d8afa799ac72c3411ab27846af4e0f50137a187f/TTS/parler_handler.py#L71

Hey @danijel3, thanks for finding this typo!
Fixed in this commit, added you as a co-author 😊


Modify valid range for sun_elevation to be -90-90.

Fixes #853
Related Issue(s): #853
Proposed Changes:
As mentioned in #853, a negative view angle can be validly recorded in remove sensing data. Besides the example listed by the issue author, I've hit up against this in ASTER L1T data, in which the product specification states values will range from -90 to 90, and a many of the images record such a value in the HDF metadata.
This change modifies the spec text and JSON schema to allow for sun_elevation values ranging from -90 to 90.
PR Checklist:

[x] This PR is made against the dev branch (all proposed changes except releases should be against dev, not master).
[x] This PR has no breaking changes.
[ ] I have added my changes to the CHANGELOG or a CHANGELOG entry is not required.
[ ] This PR affects the STAC API spec, and I have opened issue/PR #XXX to track the change.

+1 on this, it's come up several times. Most users will consider the absolute value, but the +/- will indicate port/starboard depending on platform.

I agree with @cholmes https://github.com/radiantearth/stac-spec/issues/853#issuecomment-645585134 that it feels like it is overloading the view angle as it may not be intuitively clear what a negative value could mean and maybe it should be considered go with an (additional?) and more general view:night: true/false or so. But as this seems to be used across multiple providers, it might also just be a best practice that has been established for night shots to just use negative values and then I think it's fine. 🤷♀

I'm ok with the negative value, since it looks like you're seeing it across multiple providers @lossyrob but I agree with Matthias that we should add a bit of explanation in the table that a negative value means it was taken at night.

Not sure why I didn't remember this before, but I ended up re-implementing the solar angle calculation in the processing of ASTER L1 for LPDAAC a few years ago in Cumulus, so I'm familiar with this particular case. It was using old FORTRAN code that was last updated in 1997, and I switched to using Skyfield.
But to the point...
A negative sun elevation does not necessarily mean "night", or at least it depends on your definition of "night".  The most accepted definitions are:

ASTER has a day/night flag, and it defines night as astronomical twilight, so 12 degrees below the horizon.

@lossyrob - can you add a bit more explanation on negative values? What they mean? Doesn't have to be a lot. If not I can take a crack at it, but it'd be good to get this merged in.

@cholmes thanks for the ping. @m-mohr does the additional text work for additional explanation?

I think this is a necessary change but think we should expand on "this data was captured at night" because "night" isn't really a boolean by itself.  Suggest updating text to be:
Negative values indicate the sun is below the horizon, e.g. sun elevation of -10° means the data was captured during nautical twilight or dawn.
Including the link provides users a simple and concise explanation of night vs day.

I think this is a necessary change but think we should expand on "this data was captured at night" because "night" isn't really a boolean by itself.  Suggest updating text to be:
Negative values indicate the sun is below the horizon, e.g. sun elevation of -10° means the data was captured during nautical twilight or dawn.
Including the link provides users a simple and concise explanation of night vs day.

@matthewhanson included your example and the link, if good by you then merge away!


Enable syntax hightlighting for code blocks in the documentation

Turns out, enabling it was not difficult as long as you can figure out it has to be enabled in the mkdocs.yml file.
See: https://squidfunk.github.io/mkdocs-material/reference/code-blocks/

Fixes #76

Beautiful , gonna check this branch out now


How does the HTML search work?

I can't figure out how to use the search on the left to go from the first found text to the next. Am I missing something obvious?

In the above, I have typed in "Ouput" and the first match appears on the right highlighted. How to go to the next match?

I think that the interface is on a per page basis. It highlights all pages. The nav is supposed to work with arrows within the page. Seems broken though.

The fine people at bookdown suggest this could be easily fixed (in JavaScript) if anyone would like to try: https://github.com/rstudio/bookdown/issues/657#issuecomment-444677908

FYI I just fixed https://github.com/rstudio/bookdown/issues/657. Thank you!

To fix this for the book, I think we only need to use the new bookdown to re-generate the html and pdf.

I deployed manually using devtools (https://jupyter4edu.github.io/jupyter-edu-book/) and it works for me. We can either wait for a release or make Travis use devtools::install_github('rstudio/bookdown').

Let's go ahead and use the Travis solution and once a release cuts we can swap to that.


FIX: optimize image loading time duration

as we are loading the images from github which is time taking due to that web browser is taking lot of time to load the page.

As per ChatGPT below solution will work
Image Optimization:
Compress and resize images appropriately before uploading them to your server.
Consider using modern image formats like WebP.

This ensures that only the images in the viewport are loaded initially, improving the initial page load time.

CDN (Content Delivery Network):
Use a CDN to distribute images across multiple servers globally.
This reduces latency by serving images from a server closer to the user.

Optimize Server-Side:
Optimize your server for performance with caching, compression, and possibly a CDN.
Ensure your server responds quickly to image requests.

Responsive Images:
Use the srcset attribute for responsive images to load different sizes based on the user's device and screen size.
This ensures that smaller images are loaded on smaller screens, improving performance.

Asynchronous Loading:
Load images asynchronously using JavaScript to prevent them from blocking the rendering of the rest of the page.
This allows other page elements to load while images are fetched.

Preloading:
Use the preload attribute to start loading critical images as soon as possible.
This can be particularly helpful for images that are expected to be visible to the user shortly after the page loads

To handle the situation on immediate basis implementing below solutions

Lazy Loading
Preloading

since we can't do much on server side as the images are stored in github below solutions can't be considered

CDN (Content Delivery Network)
Optimize Server-Side

Since system currently only dealing with one image size below solution can't be considered as well

Responsive Images

only optimization left to implement is below one

Asynchronous Loading

Load images asynchronously using JavaScript to prevent them from blocking the rendering of the rest of the page.
This allows other page elements to load while images are fetched.

Closing it for now as lazy loading seems sufficient as per current load tesing


2.2.8.RELEASE compiled with prerelease Kotlin version

Describe the bug
Looks like Kotlin support for Spring cloud gateway was compiled with prerelease Kotlin version. IDE shows error and compilation is not possible.
Sample
I have Kotlin 1.4.32, upgraded to Hoxton.SR11 which updated Spring Cloud Gateway to 2.2.8.RELEASE, using Kotlin in gateway configuration. Project is not possible to compile because:
Class 'org.springframework.cloud.gateway.route.builder.RouteDslKt' is compiled by a pre-release version of Kotlin and cannot be loaded by this version of the compiler

Gateway uses the version of kotlin supplied by spring boot. We don't define a kotlin version anywhere.

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

@spencergibb I tried fresh project generated from Spring Initializr and the problem is even there, so it's probably not our missconfiguration.
Reproducer: https://github.com/matejuh/gateway-hoxton11-kotlin-issue run: ./gradlew build when version changed to hoxton.sr10, it compiles.

I'm seeing the same issue when updating to Hoxton.SR11 using either Kotlin 1.4.32 or 1.5.10 (latest release version). Hoxton.SR10 works with both Kotlin versions though

Hoxton.SR12 fixed the issue


[Unexpected Behavior] Game framerate seems to affects polling rate

What you're using
On the latest version of Stepmania 5.3, limiting the game's framerate using VSync in-game or with external tools seems to introduce artifacts in the timing charts on the Simply Love/Soundwaves themes that suggest input polling issues (distinct lines and spikes in the offset graphs, screenshots linked below under each person involved in this).
This issue seems to be mostly hardware/OS independent (as I've confirmed this issue on Win 10/NVidia and Debian/AMD, among other setups other people have reported this on), and seems to not appear on Stepmania 5.1 (also confirmed by myself and others).
In addition to my findings, credit to shockdude, Haley Halcyon, and Mr. ThatKid for also confirming this issue on different setups/songs/themes, and slaugaus for the initial report with my screenshots (see #troubleshooting on the Project Moondance discord for more context/information).
Also thanks to Yumry/Crazy4321/stevereen for helping identify this issue on other discord servers as well.
Expected behavior
Input seems like it shouldn't be tied to the game's framerate, since you'd be able to arbitrarily improve your timing by turning off vsync.

Thanks for the credit! Looking forward to a fix.
Other screenshot of mine attached.

Right, so I've been investigating this, and i can confirm the following:

Input is not tied to frame-rate. if it was, you would have VERY different spikes.
di.ts (Device Input Time Stamp) does not report polling rate times, nor locked times when you're playing. I've confirmed this with multiple tests and with many different devices.
The graph seems to be doing something weird here, as it shows a 'jagged' polling error but this is NOT actually the case. We need to investigate this further.
The Histogram needs to be also investigated. This is likely a maths problem over anything else here.
The Input Thread runs outside the 'vblank' loop, which was something i thought it was within, however, when vsync is on, we can report sub 16.67ms button presses.
This is a massive rabbit hole and will take more time to identify what is at fault. The game however is NOT tied to frame-rates i can guarantee this.

Will update more when I have finished my investigation.

@shockdude @48productions can you run a test on the latest alpha for this please?
Many thanks

Issue still exists in latest alpha.

Tried again, Peak position seems inconsistent?

Logs.zip

Not totally sure how helpful it is/isn't at this point but I was able to mostly confirm this issue on the latest alpha as well. Same PC as before, but with different code for the pad (that decided to go full cursed mode for the first few songs before I enabled debounce in SM), and a 120BPM song instead of 180BPM. Not exactly the most scientific way of testing this, but it got the job done.
Worth nothing both joystick/gamepad scores were in the fancy new legacy mapping mode, as Stepmania hung when I tried to map the pad in the xinput mapping mode. I might play around with this a bit more in the future to see if I can get any more details on what specifically is going on.

So after spending some more time on this, we have deduced the following.

The thread is actually a Lua issue, there is a pass-through of (DeltaTime) causing an odd update to 60 FPS locking.
The scaling of the graph affects the stepping.
We are looking into how to display this better when the points are 'lumped together' or 'stepped'.
Input is definitely on it's own thread, - there are no issues there.

We'll keep on investigating. This is still on our 'wtf is going on' list.

Right, this has been identified and finally squashed thanks to lots of head scratching from me and Jous to get the solution.
The issue is due to the way we initialised the Low Level window, and the way Input was initialised. in the TL;DR of it, The loop for input could slip into using the message loops fDeltaTime for the timestamps (which were aligned to Vsync).
It didn't happen all the time, and it was weird for us here as it was tough to isolate. We have fixed it by moving everything input uses to its own thread, so there is no possible chance for times to weird out. The way we did the threading initialisation was not as optimised as we could, so it has been rewritten to be better. We have fixed a few issues with keyboards and some legacy joysticks using this system. It'll need some testing yet, but I am pleased to say it's behind us.
Thanks for the patience on this one, it's been a pretty crazy ride!

Is this still being worked on? The bug is still present in 4.9.6

Is this still being worked on? The bug is still present in 4.9.6


 The way to fix that is to group all your DOM reads together before doing any DOM writes. Simply rearranging these few lines, we were able to remove all of the forced synchronous layouts and we saw a noticeable performance boost even in Chrome. Should be even more noticeable in other browsers.
For reference, prior to this change, every mousemove event was taking ~11.20ms:

After this change, it was down to ~4.30ms (~60% performance boost):

That might seem trivial, but it is actually very significant given it is happening on every single mousemove event as you drag an item.

@burtonjc I like this patch a lot. thanks for the work.

No problem, happy to do it! Thank you for the merge!


⚠ Mobitopup has degraded performance

In d9596d3, Mobitopup (https://napcard.voz.tech) experienced degraded performance:

HTTP code: 200
Response time: 7851 ms

Resolved: Mobitopup performance has improved in 79ffcce.


Paths to google buckets in workspace data show up as links when they aren't

I took this screenshot from an AMP-PD workspace where the "Workspace Data" section displays values that are references to google storage buckets as clickable links. Most users will expect a clickable link to resolve to the content.

@seanhorgan, this should resolve to the content. It appears that these objects either do not exist or you lack access to them. The object names are potentially an issue- do the links there begin with gs://bucketname/... ?

I am going to close this as 'invalid' for now, as the issue appears to be with the content rather than a bug in the system. @seanhorgan Please re-open if you believe this not to be the case


cmd/atlas/internal/sqlparse: fix drop index concurrent lint (#2375)

Closed with https://github.com/ariga/atlas/pull/2377.


[Performance] mlx.core.conv_general is really slow

Describe the bug
Method mlx.core.conv_general is significantly slower than PyTorch analog. Can vary from 10x to 150x slower.
To Reproduce
Just run the attached code.
Include code snippet
import mlx.core as mx
import time
import torch

def mlx_sample():
    x = mx.random.normal([8, 16, 128, 128, 32], dtype=mx.float32)
    weight = mx.random.normal([4, 1, 1, 1, 32], dtype=mx.float32)
    stride = [1, 1, 1]
    padding = [0, 0, 0]
    dilation = [1, 1, 1]
    start = time.time()
    n = 10
    for _ in range(n):
        out = mx.conv_general(x, weight, stride, padding, dilation, stream=mx.gpu)
        mx.eval(out)

    print(f'MLX time: {(time.time() - start) * 1000 / n:0.2f}ms')

def torch_sample():
    x = torch.randn([8, 32, 16, 128, 128], dtype=torch.float32, device='mps')
    weight = torch.randn([4, 32, 1, 1, 1], dtype=torch.float32, device='mps')
    bias = torch.randn([4], dtype=torch.float32, device='mps')
    stride = [1, 1, 1]
    padding = [0, 0, 0]
    dilation = [1, 1, 1]
    start = time.time()
    n = 10
    for _ in range(n):
        out = torch.convolution(x, weight, bias, stride, padding, dilation, False, [0, 0, 0], 1)
        out.max()

    print(f'MPS time: {(time.time() - start) * 1000 / n:0.2f}ms')

def main():
    mlx_sample()
    torch_sample()

if __name__ == '__main__':
    main()

Output:
MLX time: 20.65ms
MPS time: 0.93ms
Expected behavior
At least the same speed as in PyTorch.
Desktop (please complete the following information):

OS Version: [e.g. MacOS 14.6.1]
Version [e.g. 0.17.3]
Tested on M2 Ultra and M1 Pro Max

Indeed, we are aware that there are performance cliffs in our convolutions, see e.g. #1313
Thanks for the benchmark though! We will make sure to include the 3D stuff in our optimizations.
FYI, there are a few problems with your benchmark:

Make sure you eval the inputs before running the function you want to benchmark
Always use a warmup (this also ensures the above will be true)
Make sure you synchronize on the MPS device as well

Here is an improved version:
def mlx_sample():
    x = mx.random.normal([8, 16, 128, 128, 32], dtype=mx.float32)
    weight = mx.random.normal([4, 1, 1, 1, 32], dtype=mx.float32)
    stride = [1, 1, 1]
    padding = [0, 0, 0]
    dilation = [1, 1, 1]

    # Warmup
    for _ in range(5):
        out = mx.conv_general(x, weight, stride, padding, dilation, stream=mx.gpu)
        mx.eval(out)

    start = time.time()
    n = 10
    for _ in range(n):
        out = mx.conv_general(x, weight, stride, padding, dilation, stream=mx.gpu)
        mx.eval(out)
    print(f'MLX time: {(time.time() - start) * 1000 / n:0.2f}ms')

def torch_sample():
    x = torch.randn([8, 32, 16, 128, 128], dtype=torch.float32, device='mps')
    weight = torch.randn([4, 32, 1, 1, 1], dtype=torch.float32, device='mps')
    bias = torch.randn([4], dtype=torch.float32, device='mps')
    stride = [1, 1, 1]
    padding = [0, 0, 0]
    dilation = [1, 1, 1]
    # Warmup
    for _ in range(5):
        out = torch.convolution(x, weight, bias, stride, padding, dilation, False, [0, 0, 0], 1)
        torch.mps.synchronize()

    start = time.time()
    n = 10
    for _ in range(n):
        out = torch.convolution(x, weight, bias, stride, padding, dilation, False, [0, 0, 0], 1)
        torch.mps.synchronize()

    print(f'MPS time: {(time.time() - start) * 1000 / n:0.2f}ms')

Finally, for a 1x1x1 convolution, I'd encourage you to use a Linear layer / matmul. That will be way faster for now. I ran the revised benchmark on an M2 Ultra:
MLX time: 5.26ms
MPS time: 1.38ms

MLX with matmul instead:
MLX time: 0.90ms

That looks like this:
    x = mx.random.normal([8, 16 * 128 * 128, 32], dtype=mx.float32)
    weight = mx.random.normal([4, 32], dtype=mx.float32)
    out = x @ weight.T

Thanks a lot

After some digging, the main issue is channel size of input and first dimension of weight. PyTorch has implemented convolution using native code MPSGraphConvolution3DOpDescriptor.
P.S. convolution with next params can't be calculated at all due to error "libc++abi: terminating due to uncaught exception of type std::runtime_error: [METAL] Command buffer execution failed: Internal Error (0000000e:Internal Error)" I guess kernel timeout or something like this.
    x = mx.random.normal([8, 142, 16, 64, 64], dtype=mx.float32)
    weight = mx.random.normal([22, 142, 7, 7, 7], dtype=mx.float32)
    bias = mx.random.normal([22], dtype=mx.float32)
    stride = [1, 1, 1]
    padding = [3, 3, 3]
    dilation = [1, 1, 1]

Is there a way to get a metal buffer from an array? Then I'll be able to use native function to calculate 3d convolution.

You have a couple of options:

use the Python buffer protocol memoryview(a)
get the DLPack capsule a.__dlpack__()

More info in the docs on converting to other frameworks.


[FEAT]:

I have built a simple JavaScript Timer can I push it to the repo and get my PR accepted.

Thank you

Can you please tell me how to remove the .git file this error is the first time for me.

You can remove .git from terminal. Like this if done on a linux os.
rm -rf .git

And you can find other way in other os.


Use olap4j parseIdentifier in extract_dimension_name

I ran into this bug, which I couldn't find an explanation for.
I had a Query instance which had a where clause of the form:
["[Geography].[Region].&[1]", "[Date].[Year].[2015]"]

The result of Query#to_mdx call, as expected, was:
SELECT NON EMPTY {[Measures].[RCA], [Measures].[FOB US]} ON COLUMNS,
NON EMPTY [Export HS].[HS4].Members ON ROWS
FROM [exports]
WHERE ([Geography].[Region].&[1], [Date].[Year].[2015])

However, after exactly 13 calls (!), the WHERE clause generated by Query#where_to_mdx was {[Geography].[Region].&[1], [Date].[Year].[2015]} (i.e., a set instead of a tuple).
I traced that to Query#extract_dimension_name. For some reason, after those 13 calls, the RE didn't match the identifiers in the WHERE clause. Replacing that RE match with olap4j's parseIdentifier fixed that behaviour.
I'm officially stumped by this bug. Bug in JRuby, maybe?

This seems strange. Can you provide the details which JRuby and Java versions you were using? Can you reproduce the issue just with multiple executions of regular expression matching?
I would prefer to avoid such patches as regular expression matching is faster than calling Java methods (execution time is insignificant in this case but anyway) and it would be better to understand the root cause for this problem.

JRuby is <IP_ADDRESS>, Java is 1.8.
It is indeed strange. I spent many hours trying to track down the source of this bug, but couldn't.
I understand that you wouldn't want to merge this PR without understanding the issue first. But in any case, org.olap4j.mdx.IdentifierNode.parseIdentifier feels (to me) more correct than parsing an identifier with a regex.

Found out that due to this change the following test fails https://github.com/rsim/mondrian-olap/blob/master/spec/query_spec.rb#L459-L469
The current implementation with regex tries to find the first occurrence of the dimension name ignoring, for example, function names before that.

I am closing the PR for now as it breaks some tests, see comment above.


How to train and test on my custom dataset

Hi, thanks for your work.
I am interested in this paper and I would like to train and use this model for my datasets.
How can I train this model on my dataset?
All the best.
Kazuki

Hello, have you solved the problem? @kazuki-can


docs(readme) add trello and license info

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our guidelines: https://github.com/igroup-opole/yesterday-api/blob/master/CONTRIBUTING.md
[ ] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[x] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Other... Please describe:

Does this PR introduce a breaking change?
[ ] Yes
[x] No

 [backend & frontend] Update readme


There is a note in the Readme which speaks of moving to. I was wonderng if there is a timeline for that? Would like to try Fabric out but i would prefer to do it after the moveto Go to avoid python. But if that's too far, then I can still go for it.

I was also going to post something about the migration -- what's the best way to know when it happens?


stop fetching memory blocks when an elf is found

When scanning multiple memory blocks, we should stop as soon as a valid elf is found. This was broken as the "break" applies to the switch, and not the outer loop. Fix this by reworking the code to remove the switch.
This bug had two repercutions:

instead of parsing the first memory block that contains an elf, it returned the last one, or actually even worse, a mix of all elfs depending on which values are set again or not. This however should not manifest in normal situations, notably during process scanning, as I suppose only one memory region would contain an elf executable.

the module caused the fetch of all memory blocks instead of stopping as soon as one was found, which is worse performance wise.

@plusvic anything blocking this MR that I need to modify?


Can't enable Embedded Ansible

Hi!
I try enable Embedded Ansible with no success:
tail -f evm.log | grep -i "EmbeddedAnsible"
[----] I, [2018-06-18T07:56:59.619206 #2156:b7dd9c]  INFO -- : MIQ(DockerEmbeddedAnsible#start) Waiting for Ansible container to respond
[----] I, [2018-06-18T07:57:00.951231 #2156:b7dd9c]  INFO -- : MIQ(DockerEmbeddedAnsible#start) Waiting for Ansible container to respond
[----] I, [2018-06-18T07:57:08.503775 #2156:b7dd9c]  INFO -- : MIQ(EmbeddedAnsibleWorker::Runner#setup_ansible) Finished starting embedded ansible service.
[----] I, [2018-06-18T07:57:16.150046 #2156:b7dd9c]  INFO -- : MIQ(EmbeddedAnsibleWorker#log_status) [Embedded Ansible Worker] Worker ID [69], PID [], GUID [aee9e33b-605f-4503-b2fb-ab87da354287], Last Heartbeat [2018-06-18 11:56:27 UTC], Process Info: Memory Usage [], Memory Size [], Proportional Set Size: [], Unique Set Size: [], Memory % [], CPU Time [], CPU % [], Priority []
[----] E, [2018-06-18T07:57:16.150310 #2156:b7dd9c] ERROR -- : MIQ(EmbeddedAnsibleWorker::Runner) ID [69] PID [2156] GUID [aee9e33b-605f-4503-b2fb-ab87da354287] {"detail":"A server error has occurred."} Worker exiting.

Kind Regards!

[root@manageiq ~]# docker ps
CONTAINER ID        IMAGE                     COMMAND                  CREATED             STATUS              PORTS                                NAMES
e249619df4cb        ansible/awx_task:latest   "/tini -- /bin/sh ..."   2 minutes ago       Up 2 minutes        8052/tcp                             awx_task
91f2dcf273ef        ansible/awx_web:latest    "/tini -- /bin/sh ..."   2 minutes ago       Up 2 minutes        <IP_ADDRESS>:54321->8052/tcp              awx_web
f50e2db8bf1f        memcached:alpine          "docker-entrypoint..."   2 minutes ago       Up 2 minutes        11211/tcp                            memcached
1509723120b0        rabbitmq:3                "docker-entrypoint..."   2 minutes ago       Up 2 minutes        4369/tcp, 5671-5672/tcp, 25672/tcp   rabbitmq
but after a few moment docker ps shows:
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

I'm not sure it is related but with yesterday's build (manageiq-ovirt-gaprindashvili-20180704-afd03d7488.qc2), I have a similar behavior: ManageIQ continuously tries to start AWX and fails. In the awx_web container logs, I have the following stack trace right before the container dies:
2018-07-05 15:33:28,504 ERROR    django.request Internal Server Error: /api/v1/hosts/
Traceback (most recent call last):
  File "/var/lib/awx/venv/awx/lib/python2.7/site-packages/django/core/handlers/exception.py", line 41, in inner
    response = get_response(request)
  File "/usr/lib/python2.7/site-packages/awx/wsgi.py", line 65, in _legacy_get_response
    return super(AWXWSGIHandler, self)._legacy_get_response(request)
  File "/var/lib/awx/venv/awx/lib/python2.7/site-packages/django/core/handlers/base.py", line 249, in _legacy_get_response
    response = self._get_response(request)
  File "/var/lib/awx/venv/awx/lib/python2.7/site-packages/django/core/handlers/base.py", line 187, in _get_response
    response = self.process_exception_by_middleware(e, request)
  File "/var/lib/awx/venv/awx/lib/python2.7/site-packages/django/core/handlers/base.py", line 185, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/var/lib/awx/venv/awx/lib/python2.7/site-packages/django/utils/decorators.py", line 185, in inner
    return func(*args, **kwargs)
  File "/var/lib/awx/venv/awx/lib/python2.7/site-packages/django/views/decorators/csrf.py", line 58, in wrapped_view
    return view_func(*args, **kwargs)
  File "/var/lib/awx/venv/awx/lib/python2.7/site-packages/django/views/generic/base.py", line 68, in view
    return self.dispatch(request, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/awx/api/generics.py", line 299, in dispatch
    return super(APIView, self).dispatch(request, *args, **kwargs)
  File "/var/lib/awx/venv/awx/lib/python2.7/site-packages/rest_framework/views.py", line 494, in dispatch
    response = self.handle_exception(exc)
  File "/var/lib/awx/venv/awx/lib/python2.7/site-packages/rest_framework/views.py", line 454, in handle_exception
    self.raise_uncaught_exception(exc)
  File "/var/lib/awx/venv/awx/lib/python2.7/site-packages/rest_framework/views.py", line 491, in dispatch
    response = handler(request, *args, **kwargs)
  File "/var/lib/awx/venv/awx/lib/python2.7/site-packages/rest_framework/generics.py", line 244, in post
    return self.create(request, *args, **kwargs)
  File "/var/lib/awx/venv/awx/lib/python2.7/site-packages/rest_framework/mixins.py", line 21, in create
    self.perform_create(serializer)
  File "/var/lib/awx/venv/awx/lib/python2.7/site-packages/rest_framework/mixins.py", line 26, in perform_create
    serializer.save()
  File "/var/lib/awx/venv/awx/lib/python2.7/site-packages/rest_framework/serializers.py", line 214, in save
    self.instance = self.create(validated_data)
  File "/var/lib/awx/venv/awx/lib/python2.7/site-packages/rest_framework/serializers.py", line 917, in create
    instance = ModelClass.objects.create(**validated_data)
  File "/var/lib/awx/venv/awx/lib/python2.7/site-packages/django/db/models/manager.py", line 85, in manager_method
    return getattr(self.get_queryset(), name)(*args, **kwargs)
  File "/var/lib/awx/venv/awx/lib/python2.7/site-packages/django/db/models/query.py", line 394, in create
    obj.save(force_insert=True, using=self.db)
  File "/usr/lib/python2.7/site-packages/awx/main/models/inventory.py", line 700, in save
    super(Host, self).save(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/awx/main/models/base.py", line 275, in save
    super(PrimordialModel, self).save(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/awx/main/models/base.py", line 164, in save
    super(CreatedModifiedModel, self).save(*args, **kwargs)
  File "/var/lib/awx/venv/awx/lib/python2.7/site-packages/django/db/models/base.py", line 808, in save
    force_update=force_update, update_fields=update_fields)
  File "/var/lib/awx/venv/awx/lib/python2.7/site-packages/django/db/models/base.py", line 848, in save_base
    update_fields=update_fields, raw=raw, using=using,
  File "/var/lib/awx/venv/awx/lib/python2.7/site-packages/django/dispatch/dispatcher.py", line 193, in send
    for receiver in self._live_receivers(sender)
  File "/usr/lib/python2.7/site-packages/awx/main/signals.py", line 146, in emit_update_inventory_on_created_or_deleted
    update_inventory_computed_fields.delay(inventory.id, True)
  File "/var/lib/awx/venv/awx/lib/python2.7/site-packages/celery/app/task.py", line 461, in delay
    return self.apply_async(args, kwargs)
  File "/var/lib/awx/venv/awx/lib/python2.7/site-packages/celery/app/task.py", line 573, in apply_async
    **dict(self._get_exec_options(), **options)
  File "/var/lib/awx/venv/awx/lib/python2.7/site-packages/celery/app/base.py", line 345, in send_task
    options = router.route(options, name, args, kwargs)
  File "/var/lib/awx/venv/awx/lib/python2.7/site-packages/celery/app/routes.py", line 50, in route
    route = self.lookup_route(task, args, kwargs)
  File "/var/lib/awx/venv/awx/lib/python2.7/site-packages/celery/app/routes.py", line 78, in lookup_route
    return _first_route(self.routes, task, args, kwargs)
  File "/var/lib/awx/venv/awx/lib/python2.7/site-packages/celery/utils/functional.py", line 233, in _matcher
    answer = getattr(maybe_evaluate(obj), method)(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/awx/main/utils/ha.py", line 58, in route_for_task
    (changed, instance) = Instance.objects.get_or_register()
  File "/usr/lib/python2.7/site-packages/awx/main/managers.py", line 106, in get_or_register
    return (False, self.me())
  File "/usr/lib/python2.7/site-packages/awx/main/managers.py", line 88, in me
    raise RuntimeError("No instance found with the current cluster host id")
RuntimeError: No instance found with the current cluster host id

And right after the container dies, I have the same error message as @smopihub :
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

Any idea ?

I think this was solved in the Hammer RC-1 build.
I believe one of the main fixes that allows this to work in Hammer is #17407 which has been requested for Gaprindashvili backport.

I think this is tracking the same issue as #17738 going to close this as a duplicate.


Send FIL failed

Describe the bug

The wallet test failed, and the FIL was not sent. The target wallet didn't receive anything and the transaction is not visible in the source wallet. https://calibration.filscan.io/address/general?address=t1ac6ndwj6nghqbmtbovvnwcqo577p6ox2pt52q2y
(it should've happened around 2023-03-23 17:47:17, target t1fye76pfymru4y2fqbgdxswpwqt3ukeems2nzfna)
This means that either we have a bug in the test setup or the send command doesn't always send the funds, which would be a significant issue.
To Reproduce
It happened in this PR https://github.com/ChainSafe/forest/pull/2709 (which didn't introduce any logic changes)
The job failed: https://github.com/ChainSafe/forest/actions/runs/4503553182/jobs/7926889785
Log output
Wallet tests
Importing preloaded wallet key
t1ac6ndwj6nghqbmtbovvnwcqo577p6ox2pt52q2y
Exporting key
Fetching metrics
--2023-03-23 17:47:17--  http://localhost:6116/metrics
Resolving localhost (localhost)... ::1, <IP_ADDRESS>
Connecting to localhost (localhost)|::1|:6116... failed: Connection refused.
Connecting to localhost (localhost)|<IP_ADDRESS>|:6116... connected.
HTTP request sent, awaiting response... 200 OK
Length: 28751 (28K) [text/plain]
Saving to: ‘metrics.log’

     0K .......... .......... ........                        100%  404M=0s

2023-03-23 17:47:17 (404 MB/s) - ‘metrics.log’ saved [28751/28751]

Listing wallet balances
Address                                   Default Balance
t1ac6ndwj6nghqbmtbovvnwcqo577p6ox2pt52q2y           ~100 FIL
Creating a new address to send FIL to
t1fye76pfymru4y2fqbgdxswpwqt3ukeems2nzfna
Listing wallet balances
Address                                   Default Balance
t1ac6ndwj6nghqbmtbovvnwcqo577p6ox2pt52q2y  X        ~100 FIL
t1fye76pfymru4y2fqbgdxswpwqt3ukeems2nzfna           0 atto FIL
Sending FIL to the above address
Checking balance of t1fye76pfymru4y2fqbgdxswpwqt3ukeems2nzfna...

Screenshots

Environment (please complete the following information):

OS: buildjet runner, Ubuntu 20.04
Rust version(e.g. rustc --version)
Branch/commit 2dc3442

Other information and links

Most likely the send command is not working as we expected. The test setup should be good, only incomplete regarding message behaviour.
From Lotus doc:

If messages are not deemed attractive enough by storage providers to be included in new blocks, they may become stuck in the message pool. This is usually a consequence of the GasFeeCap being too low, for example, when the Network’s BaseFee is high. It can also be a consequence of the GasPremium being too low if the network is congested.

This might be our issue. As a start we should print message ID and check if it is not stuck in the message pool.
https://calibration.filscan.io/tipset/pool-message-list
In that case, maybe trying resending a new message with increased gas premium could be a solution.

I've been trying to reproduce the issue and it was pretty easy. Found out that between two subsequent messages where the first one was mined and the second is stuck in Forest message pool, the only significant differences were a lower GasFee cap and GasPremium:
First:
    "Nonce": 1,
    "Value": "550",
    "GasLimit": 1330063,
    "GasFeeCap": "101191",
    "GasPremium": "100137",
    "CID": {
      "/": "bafy2bzacedcyrn74duk6sbxmaqdwk7zkqlufv2e2tjat5xnxqikvnbxp6jk6c"
    }

Second:
    "Nonce": 2,
    "Value": "300",
    "GasLimit": 1330063,
    "GasFeeCap": "100864",
    "GasPremium": "99810",
    "CID": {
      "/": "bafy2bzacecttsvw2yhxvuhgtqe2o5n7yawreawlh7g5tp5yba2fyhzc6yf6ee"
    }

I think that a bad message Nonce could cause the transaction to fail.
In Forest node I can see:
WARN forest_message_pool::msg_chain: encountered message from actor t1ekkzekiozleakm4jauekqqc6uhn3dcwzcrrqrry with nonce 53 less than the current nonce 54
Let's sum up what is happening here:
The sending actor has its Nonce with a value of 53.
We're sending to t1mljyv5pzvu7jgzuvzfog2ycsd5fdh4y7c2z6t6q 500 afil. Forest creates the message using the Nonce from sending actor Nonce (53).
Transaction is mined successfully in block bafy2bzaceacr42ctk3z7i7vuqkdyfzydscvcv47dgzzdiunbh3qmcc6dp65su.
Sending actor Nonce is somewhat being updated in the blockchain to 54 (todo: find who does that).
We're sending a new transaction (500 afill to t1i63uuuqrgqvntdekae4wmomz5abgnwltm3buyia). Nonce used here is still 53 (this could be our issue):
{
  "Message": {
    "Version": 0,
    "To": "t1i63uuuqrgqvntdekae4wmomz5abgnwltm3buyia",
    "From": "t1ekkzekiozleakm4jauekqqc6uhn3dcwzcrrqrry",
    "Nonce": 53,
    "Value": "500",
    "GasLimit": 5866637,
    "GasFeeCap": "100374",
    "GasPremium": "99320",
    "Method": 0,
    "Params": "",
    "CID": {
      "/": "bafy2bzacedw3qgd4dy3qyizg3ian44i5yefkjtzknetdksqqwi7khc2cuvpbq"
    }
  },
  "Signature": {
    "Type": 1,
    "Data": "1drZdRSXUCMEv0niS/3XSCd8MhE3UZkFei4EYpjh+ismkBpVDGqNwAyXRxccVy8Uqhoj2mFkmOMI6GliekqC0wA="
  },
  "CID": {
    "/": "bafy2bzacecmeugxrjtaaxkp5nci7oqblt2bccsqcrc57dqx3do6kfvymhgqa6"
  }
}

Transaction is rejected because it would expect a Nonce of 54.
It's not even reaching the Lotus node running the explorer (probably because detected as invalid by network nodes during p2p message broadcast).
Generally speaking, even if we didn't had this issue here, there could be a race between two CI jobs since we use the same sending actor.

To sum up:

The gas_limit error was due to some mutation bug and I've fixed it in 5f090e1
The Nonce issue was fixed in bba7724 (I was using this branch for troubleshooting because it has support for mpool pending which is very useful)
I'm actually unable to reproduce the suspected race I was speaking about using two Forest nodes on my network with the same sending address. Sending a message and pressing enter at the same moment on this two nodes is giving me always two different Nonces (i.e. 166 and 167).
Checking for some transaction with same sender around the date when your error occurred show nothing on a calibnet explorer (https://calibration.filfox.info/en/address/t1ac6ndwj6nghqbmtbovvnwcqo577p6ox2pt52q2y)
Adding back the script to the CI worked (#2942) and I managed to run a send command 40 times without any hurdles

I still don't get why it is happening. I would like to reproduce in again on the CI and see the json message (we need to merge the PR with mpool pending first).
Maybe also looking at how Lotus handles this message when reaching its Mempool.

@LesnyRumcajs did you try to run the script locally? Like sending to an address 40 times.

I can do it today. Should I use the latest main?

I can do it today. Should I use the latest main?

Yes, just run forest-cli send a couple of times in a loop and see if you can reproduce. Did not try on my Fedora, only macOS.

@elmattic Can't reproduce it locally. All of the messages arrived. I sent:

1 test transaction
1000 transactions with 0.1s delay
3000 transactions with no delay

I'll try doing it in parallel with different nodes.

We already discussed this in Slack, so just for the record. We managed to reproduce it by running sending FIL in two separate locations (Germany and Poland).
Sending 500atto from t1es57egc3chszrnlprkkfl2x6g36zlxvrdcdz76i to t1gbwtv52gqukzhe5rmhu4n5jclpf3lc6bdn3m5eq for the 8417 time
Error: {"code":0,"message":"gas price is lower than min gas price"}
Sending 500atto from t1es57egc3chszrnlprkkfl2x6g36zlxvrdcdz76i to t1gbwtv52gqukzhe5rmhu4n5jclpf3lc6bdn3m5eq for the 8418 time
bafy2bzaceclc3dxyhmyfmnr76gvswlu6fwcaq5xgr2kwrtttsrc53oadiice4
Sending 500atto from t1es57egc3chszrnlprkkfl2x6g36zlxvrdcdz76i to t1gbwtv52gqukzhe5rmhu4n5jclpf3lc6bdn3m5eq for the 8419 time

@LesnyRumcajs I had another try reproducing this issue. The issue is still there but not easy to reproduce.
Using only one node, I managed to reproduce the issue two times on around 1500 runs.
The way I'm doing it. First create a new sending account and fill it using some calibnet faucet.
Then:

This account will send each time 500 attoFIL to a newly created account.
Print Forest pending mpool and wait for the sent message to be mined.
If successful, rince and repeat from step 1.

Looking at the message payloads in send_log.txt, the send is failing because the message Nonce wasn't correctly incremented, it should be 1451 but it still equals to 1450.
Looking at the forest daemon logs around 03:09:34 we can see a fork happening, so that's likely explain our issue.
send_log.txt
forest_log.txt

Thanks. Do we know if Lotus has the same issue? If not, how does Lotus handle it?

Not 100% sure but they do have some code that can react to HEAD changes and republish previously mined messages.
See https://github.com/filecoin-project/lotus/blob/3fd57ff7d90a3f4c51975b89dfc98135116d52de/chain/messagepool/messagepool.go#L1262

@elmattic Would you like to contact Lotus devs to validate that this is the solution to the same problem?

@elmattic do you recall what's the status of this? Is sending FIL still failing every now and then?

@LesnyRumcajs I will check our CI. But, AFAIK, the pesky bug is still present.

@elmattic do you recall what's the status of this? Is sending FIL still failing every now and then?

https://github.com/ChainSafe/forest/actions/runs/9204884823/job/25319573657
We can now update the status to "still broken".


kpt fn sink outputs invalid JSON to .json files

Expected behavior
> mkdir config
> echo '{"a": "a long string that would absolutely certainly see a newline introduced by the YAML marshaller"}' >config/a.json
> kpt fn source config | kpt fn sink config
> cat config a.json
{
  "a": "a long string that would absolutely certainly see a newline introduced by the YAML marshaller"
}

Actual behavior
> mkdir config
> echo '{"a": "a long string that would absolutely certainly see a newline introduced by the YAML marshaller"}' >config/a.json
> kpt fn source config | kpt fn sink config
> cat config a.json
{"a": "a long string that would absolutely certainly see a newline introduced by the
    YAML marshaller"}

As you can see this is not valid JSON because of the newline in the string, which is treated as just a single whitespace in YAML.
Information
Kpt version: 0.39.2
This could be seen as a follow up to #647 and kubernetes-sigs/kustomize/pull/2546.
I have opened kubernetes-sigs/kustomize/pull/3934 to address the issue but I haven't seen much activity there. Even if it gets accepted I'm not sure how easy it will be to get it into kpt considering the kustomize deps here are lagging a bit and there have been breaking changes since (as described in the PR).
For more context on the relevance of this I was trying to run a function on a directory containing a Kustomization using the new custom OpenAPI feature, which requires you to have a JSON formatted OpenAPI schema in the same directory (YAML is not supported and it can't be placed outside of the kustomization directory). I wanted to run this imperatively, writing the output to another directory before doing kustomize build so changing the schema file extension to something other than .json wouldn't work either since it wouldn't be included in the output.

@Shell32-Natsu and @natasha41575  is the PR something you can take a look at on the kustomize side?

I have opened kubernetes-sigs/kustomize/pull/3934 to address the issue but I haven't seen much activity there. Even if it gets accepted I'm not sure how easy it will be to get it into kpt considering the kustomize deps here are lagging a bit and there have been breaking changes since (as described in the PR).

Thanks for the PR, it's nicely done. I just reviewed it and have a minor comment. I will check how easy it will be to get this in on master branch. On next branch, we have been proactive in using recent versions of kyaml.

For more context on the relevance of this I was trying to run a function on a directory containing a Kustomization using the new custom OpenAPI feature, which requires you to have a JSON formatted OpenAPI schema in the same directory (YAML is not supported and it can't be placed outside of the kustomization directory). I wanted to run this imperatively, writing the output to another directory before doing kustomize build so changing the schema file extension to something other than .json wouldn't work either since it wouldn't be included in the output.

I will discuss with @natasha41575 if there is a way to solve this issue and post an update.

YAML is not supported and it can't be placed outside of the kustomization directory

Would it resolve your issue if kustomize supported specifying the OpenAPI schema in yaml? We might be able to do that.

@yhrn Had a chat with @natasha41575 . Using krmignore file to ignore the openschema file is another option, she is going to try that out and confirm if that will solve the original issue you are running into.

YAML is not supported and it can't be placed outside of the kustomization directory

Would it help if kustomize supported specifying the OpenAPI schema in yaml? We might be able to do that. Please feel free to file an issue for that in kustomize if that's something you want to see and I can follow up.

That would be another way of solving the exact use case I had here and it would also be nice to have regardless, but I also think the PR I opened makes sense regardless. Opened an issue: kubernetes-sigs/kustomize/issues/3961

@yhrn Had a chat with @natasha41575 . Using krmignore file to ignore the openschema file is another option, she is going to try that out and confirm if that will solve the original issue you are running into.

Can you provide some more info on krmignore? If it causes kpt fn source to completely ignore the file then I can achieve the same thing by changing the extension and it won't solve my use case since I'm reading from one directory and writing to another. But if the file is still read by kpt fn source but bypasses any functions before being written by kpt fn sink then it's a great option.

but I also think the PR I opened makes sense regardless.

Totally agreed.

Can you provide some more info on krmignore? If it causes kpt fn source to completely ignore the file then I can achieve the same thing by changing the extension and it won't solve my use case since I'm reading from one directory and writing to another. But if the file is still read by kpt fn source but bypasses any functions before being written by kpt fn sink then it's a great option.

Aah, you are right, krmignore won't solve the problem and yes it is equivalent to changing the extension.
So if this is an imperative workflow, one (not-so-great) option is to copy the schema in the destination dir at the beginning of the imperative steps (also adding it to krmignore file so that kpt source ignores it). It's way of telling kpt ignore this file, I will handle it myself, but it will be available for kustomize build step in the destination directory after the kpt chain.

Aah, you are right, krmignore won't solve the problem and yes it is equivalent to changing the extension.
So if this is an imperative workflow, one (not-so-great) option is to copy the schema in the destination dir at the beginning of the imperative steps (also adding it to krmignore file so that kpt source ignores it). It's way of telling kpt ignore this file, I will handle it myself, but it will be available for kustomize build step in the destination directory after the kpt chain.

Yes, but I really would like to avoid that because I'm trying to put a generic pattern in place with some tooling around it where I apply a set of functions, defined in one directory, to another source directory, then run kustomize build on the fn output and finally writing that to a separate destination. Given this I would need to introduce some mechanism/convention for copying some files separately between the source and destination, which I think would be very unfortunate.

@yhrn completely agree.  I see that the kustomize PR is merged (Huge thanks for that), we will have the kpt next branch (v1.0+) updated very soon as we are waiting for a few more fixes in the kyaml pkg to land.
@natasha41575 is investigating how easy it is to get kpt alpha updated with latest kyaml. Given that it hasn't been updated in a while, update might be bumpy.

kyaml v0.10.21 is released that contains the @yhrn PR. https://github.com/GoogleContainerTools/kpt/pull/2181 upgrades kpt next branch to latest kyaml release.
So far the upgrade of kyaml on kpt alpha isn't looking bad. Hoping to get this merged today.

I spoke with @droot and @mortent and it looks like this change will be difficult to get into v0 without breaking something. It may make more sense to close this issue as the fix is in v1 and we are hopeful that customers will be able to migrate to it soon. Have you had the chance to try out v1 yet?

I haven't had time to try v1 a lot yet and I'm not sure how quickly it will be an option for us. Even if all the features are there I assume it will take some time for it to stabilize enough for production usage. I realize v0 is viewed as some kind of alpha but it's still been in use for quite a while.

@yhrn Understood. We are working to see what we can do about the breaking changes in go-yaml. After that we will revisit this and see if doing the upgrade in v0 is feasible.

@natasha41575 I guess another option is to release a patched kyaml v0.10.17 version, e.g. v0.10.17-patch1 that only adds the relevant fixes to kyaml v0.10.17. I have already done this here and here (note that the replace directive is only necessary because I'm referencing my fork of Kustomize where the module paths don't match the repo)

I guess another option is to release a patched kyaml v0.10.17 version, e.g. v0.10.17-patch1

Will keep this in mind if the change in go-yaml isn't enough, but it looks like someone is working on fixing the indentation issue (https://github.com/go-yaml/yaml/issues/720) after which I am hoping we won't need a replace directive anymore.
I'm going to keep this in the backlog while we wait for an update on that.


barcode scanner sometimes reads wrong barcodes

The following enties have been created from the same product:
http://de.openfoodfacts.org/produkt/18151535/limited-no-8-birthday-edition-true-fruits
http://de.openfoodfacts.org/produkt/4260122390014
the actual barcode seems to be<PHONE_NUMBER>014

Fixed; thanks.

@TaciteOFF can I close the issue?


Upgrade dependencies

Updates to LlamaKit’s parameterized errors.
Note that this still uses Swift 1.1.

LGTM


[Azure Search] Final prep to ship 8.0-preview

Updating release notes, regenerating code, fixing broken tests, and updating all session records.
FYI @Yahnoosh @natinimni @shmed @ishansrivastava90 @updixit

@azuresdkci Retest this please


Avoid reparsing Json when integrating JsonObjectSerializer with generated layer

The code generator doesn't support serializing any old object to Json. In order to build this support into the Event Grid SDK, we needed to wrap our payload in an internal class that implements IUtf8JsonSerializable. In our Write method we end up needing to serialize object to Json stream, and then parse back to JsonDocument. Ideally, we could avoid doing this duplicate work. Also, we should look into whether it is possible to move this type into shared source that can be used by other libraries.
public void Write(Utf8JsonWriter writer)
        {
            var stream = new MemoryStream();
            _serializer.Serialize(stream, _customEvent, _customEvent.GetType(), _cancellationToken);
            stream.Seek(0, SeekOrigin.Begin);
            JsonDocument.Parse(stream).WriteTo(writer);
        }

.NET 6 WriteRawValue would help here.


Following FB sync. Locked to single day

Did an import of my FB data.
at the end of sync, it doesn't update the view state to show all data. The app correctly messages during sync that new items are being added.

Reloading the page causes all data to load correctly for view

"live" views are still a WIP, most of the pieces are in place for them to function, just need to spend time in that area.  Good to have feedback that it felt missed.

@merc3po, assigning to you as this has been a concern for a while. Not sure whether we need to address it immediately or not, but passing it off to you.

I'm going to mark this as a request. Not sure we want to spend time improving our default apps in a piecemeal fashion.


Dashmate uses outdated docker images for drive and dapi

The dashmate version v0.22.7 pulls the Docker images dashpay/dapi:0.22.0-dev.7 and dashpay/drive:0.22.0-dev.7.
Expected Behavior
I would expect the dashmate version v0.22.7 to pull the Docker images dashpay/dapi:0.22.7 and dashpay/drive:0.22.7.
Possible Solution
Change default images in packages/dashmate/configs/system/base.js to the recent ones.
Context
After an update of a testnet masternode using dashmate, the drive crashes because it fails to connect to MongoDB.
I believe this is a result of dashmate expecting to use grovedb, which is why it doesn't start a MongoDB, while the old drive at 0.22.0-dev.7 expects a MongoDB to be available.
Your Environment
I have tested this on platform version v0.22.6, but it doesn't seem to be fixed in v0.22.7.

Dashmate now uses latest stable versions (dashpay/drive:0.22 for example)


Visual studio code getting slow while working on large projects [tab] not work and live scss stop works also intellisense get lazy

Its happening with me alot of time when my project getting bigger vsc code stops working tab is not working intellisense not working and live scss watcher stops working its saving files so slow i am attaching the video for better understanding.

when i restart vsc its start working fine but when its open for sometime its doing things like this.

The scss watcher is provided by an external extension. Can you find out if the slowness is caused by that extension by disabling all extensions?


Can't see bounding box in rviz.

Checklist

[X] I've read the contribution guidelines.
[X] I've searched other issues and no duplicate issues were found.
[X] I'm convinced that this is not my fault but a bug.

Description
I use the following command.
ros2 launch autoware_launch logging_simulator.launch.xml map_path:=$HOME/work/rosbag_map/universe/sample-map-rosbag vehicle_model:=sample_vehicle sensor_model:=sample_sensor_kit | grep centerpoint
I get the log as below.
[INFO] [lidar_centerpoint_node-27]: process started with pid [586904]
[lidar_centerpoint_node-27] Loading from /home/autoware/install/lidar_centerpoint/share/lidar_centerpoint/data/pts_voxel_encoder_centerpoint_tiny.engine
[lidar_centerpoint_node-27] Loading from /home/autoware/install/lidar_centerpoint/share/lidar_centerpoint/data/pts_backbone_neck_head_centerpoint_tiny.engine
[lidar_centerpoint_node-27] [WARN] [1667293552.178222006] [lidar_centerpoint]: Could not find a connection between 'base_link' and 'map' because they are not part of the same tree. Tf has two or more unconnected trees.
[lidar_centerpoint_node-27] [WARN] [1667293552.178362394] [lidar_centerpoint]: Fail to preprocess and skip to detect.
[lidar_centerpoint_node-27] [WARN] [1667293552.688393673] [lidar_centerpoint]: Could not find a connection between 'base_link' and 'map' because they are not part of the same tree.Tf has two or more unconnected trees
In the GPU monitoring, I can see the relevant process information and the normal use of the GPU.

According to the above information, you can see that the engine has been generated and the GPU is in normal use. Do you know why I can't see the blue rectangle around objects like cars on other lanes?

Expected behavior
The bounding box can be seen in rviz.
Actual behavior
Can't see bounding box in rviz.
Steps to reproduce

ros2 launch autoware_launch logging_simulator.launch.xml map_path:=$HOME/work/rosbag_map/universe/sample-map-rosbag vehicle_model:=sample_vehicle sensor_model:=sample_sensor_kit | grep centerpoint
ros2 bag play /home/inspur/Downloads/sample-rosbag

Versions
-OS: Ubuntu 20.04
-ROS: Galactic
Possible causes
none
Additional context
none

I have not been able to reproduce the issue with the latest version of Autoware following the instructions from https://autowarefoundation.github.io/autoware-documentation/main/tutorials/ad-hoc-simulation/rosbag-replay-simulation/.
Did you make any modification to Autoware or to the Rviz configuration ?
Also, can you please share the full log file found in $HOME/.ros/log/DATE_TIME/launch.log ?

@maxime-clem
launch.log
The full log file is shown in the attachment.
I mainly use the https://github.com/tier4/CARET_report tool, but this tool is mainly used for tracing and should not affect perception module in theory.

Thank you for sharing the full log file. I cannot see any issue from the log file.
Are you able to see some messages when running the following command ?
ros2 topic echo /perception/object_recognition/objects

If you see some messages being published, then maybe the issue comes from rviz. Can you make sure the visualization of the /perception/object_recognition/objects topic is correct ?

@maxime-clem
Thank you, using the command the result is as follow.
ros2 topic echo /perception/object_recognition/objects
The message type 'autoware_auto_perception_msgs/msg/PredictedObjects' is invalid

@maxime-clem Thank you, using the command the result is as follow. ros2 topic echo /perception/object_recognition/objects The message type 'autoware_auto_perception_msgs/msg/PredictedObjects' is invalid

You need to run source install/setup.sh in the autoware folder and then it should work.

@maxime-clem
No message is published.

@maxime-clem
I further analyzed the .log and found that the node object_lanelet_filter_node is not working. The relevant logs are as follows.
[object_lanelet_filter_node-31] /home/inspur/autoware/install/detected_object_validation/lib/detected_object_validation/object_lanelet_filter_node: symbol lookup error: /home/inspur/autoware/install/detected_object_validation/lib/libobject_lanelet_filter.so: undefined symbol: _ZNK5utils17FilterTargetLabel8isTargetEh
$ c++filt _ZNK5utils17FilterTargetLabel8isTargetEh
utils::FilterTargetLabel::isTarget(unsigned char) const
Recompiling the detected_object_validation package does not solve the above problem.
Do you have a better suggestion?

@nainaigetuide

Do you have a better suggestion?

To completely recompile the detected_object_validation package, it may be necessary to first remove the corresponding build and install folders in your workspace:
rm build/detected_object_validation install/detected_object_validation -rf

Can you try that and see if it fixes the issue ?

@maxime-clem
Thank you. Solved in the following way.
https://github.com/autowarefoundation/autoware.universe/commit/cf91d1a1425e8ee0682af91add418936788932aa
The specific reason is that my version is a little behind the current latest version.


[SPARK-33084][SQL][TEST][FOLLOW-ON] Add ResetSystemProperties trait to SQLQuerySuite and use newer Ivy property for local directory override.

What changes were proposed in this pull request?
Add the ResetSystemProperties trait to SQLQuerySuite so that system property changes made by any of the tests will not affect other suites/tests. Specifically, the system property changes made by SPARK-33084: Add jar support Ivy URI in SQL -- jar contains udf class are targeted here.
Additionally, update the system property used by the test to adjust the Ivy home directory from ivy.home to ivy.default.ivy.user.dir.
Why are the changes needed?
PR #29966 added a new test case that adjusts the ivy.home system property to force Ivy to resolve an artifact from a custom location. At the end of the test, the value is cleared. Clearing the value meant that, if a custom value of ivy.home was configured externally, it would not apply for tests run after this test case. Additionally, the ivy.home property is treated by Ivy as synonymous to the ivy.default.ivy.user.dir property, except that the latter takes precedence. Thus, if ivy.default.ivy.user.dir was externally configured, this test would fail, since the ivy.home value would not take effect.
Does this PR introduce any user-facing change?
No, this is only in tests.
How was this patch tested?
Previously, if the tests were launched with a system property value of ivy.default.ivy.user.dir = /path/to/custom/location, the test in question would fail. Now, it succeeds.

cc folks from PR #29966: @viirya @maropu @wangyum @HyukjinKwon @dongjoon-hyun

Test build #135604 has started for PR 31694 at commit 0c64be6.

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

Test build #135604 has finished for PR 31694 at commit 0c64be6.

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

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

Looks like a valid failure, so could you check it?

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

Test build #135616 has finished for PR 31694 at commit 89c88e8.

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

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

The CliSuite test passed in the new run, but the modified SQLQuerySuite test failed. Not sure why that wasn't showing up in the first test execution.
I dug a bit deeper and it turns out what I said in the description wasn't quite right (will update now). The issue is that the behavior of IvySettings#getDefaultIvyUserDir is different from that of IvySettings#load when it comes to ivy.home and ivy.default.ivy.user.dir. For getDefaultIvyUserDir, only ivy.home is used, even though the logs claim it is using ivy.default.ivy.user.dir:
    public synchronized File getDefaultIvyUserDir() {
        if (defaultUserDir == null) {
            if (getVariable("ivy.home") != null) {
                setDefaultIvyUserDir(Checks.checkAbsolute(getVariable("ivy.home"), "ivy.home"));
                Message.verbose("using ivy.default.ivy.user.dir variable for default ivy user dir: "
                        + defaultUserDir);
            } else {
                setDefaultIvyUserDir(new File(System.getProperty("user.home"), ".ivy2"));
                Message.verbose("no default ivy user dir defined: set to " + defaultUserDir);
            }
        }
        return defaultUserDir;
    }

But for load, ivy.default.ivy.user.dir is checked, and if present, it is used to set the value ivy.home (within setDefaultIvyUserDir):

    public synchronized void load(File settingsFile) throws ParseException, IOException {
        ...
        if (getVariable("ivy.default.ivy.user.dir") != null) {
            setDefaultIvyUserDir(Checks.checkAbsolute(getVariable("ivy.default.ivy.user.dir"),
                "ivy.default.ivy.user.dir"));
        } else {
            getDefaultIvyUserDir();
        }
        ...
    }

So for the new IvySettings case, ivy.home takes precedence, but for the (new IvySettings).load(...) case, ivy.default.ivy.user.dir takes precedence. In our environment we configure a custom Ivy settings file so I was only testing the latter case initially.
I have updated the patch to leave the system property as ivy.home. The test will still break if spark.jars.ivySettings and ivy.default.ivy.user.dir are used in tandem, but this should be a corner case and I don't think there is a way to resolve it further without modifying Ivy itself.

Test build #135672 has started for PR 31694 at commit 840b630.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40254/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40254/

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

Test build #135672 has finished for PR 31694 at commit 840b630.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

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

Merged to master

Thanks @HyukjinKwon and @maropu ! Much appreciated.


Coding standards: Python files

As a monolithic issue (#3916) does not make it easy to discuss specific points, let's split some topics in their own issue (always referencing the main one) so that we can progress forwards.

We have various Python files in the source, mostly related to the buildsystem or some helper scripts.
I'd propose to follow the Python standard for those, PEP 8: https://www.python.org/dev/peps/pep-0008/
The main disruptive change of PEP 8 for us would be that it enforces space indentation (:innocent:), while we currently have a stronger tendency to use tabs (though it's not done consistently and we have a lot of mixed situations).
Since most auto-formatting tools enforce spaces, I'd propose to use that convention too for our Python files (not C++ of course, where we should stick to our de facto tabs standard).
Alternatively, we can decide to use PEP 8 and tabs for indentation, we just need to tweak the PEP 8 checking tools to disable some warnings and errors related to indentation. One advantage of keeping tabs is that we're consistent with the C++ code, so we don't have issues with conflicting IDE configs.

IMHO the convention, which is spaces for PEP8.

Since PEP 8 defines indentation with spaces, it's better to use spaces. Users used to Python will likely use spaces when contributing and having a different settings and tooling for Godot should not be necessary.

I prefer to use spaces in general. Some text editors make it a bit tedious (backspace removing one space at a time instead of 1 indent) but that's the only problem I would have with it.

Let's go with spaces then.
One thing not covered by pep8 (or at least not touched by autopep8) is the use of parenthesis around conditionals:
if (cond):
    do_stuff()

vs
if cond:
    do_stuff()

Which one do we want to enforce? I think the 2nd one is more idiomatic python, but the former one is currently used more often as the buildsystem was written by C++ guys :)

I prefer the second one (no parenthesis) both in Python and GDScript.

I prefer the second one too, also I don't understand why the first one would be useful?

I don't understand why the first one would be useful?

It has no use, but it's what C/C++ programmers are used to use, so they might find it more aesthetic (at least judging by its extensive usage in all our python files :)).

Personally I prefer the first one (with parenthesis) because it clearly separates the if keyword from the whole condition. (Might be that I'm used to C syntax though... :-))

First one is useful if multiple conditions and/or in one if statement. I think GDScript lets us use both styles anyways? I use the first one for complex conditions and the no parenthesis one for more simpler ones

Now I'm trying to embrace the Python culture I also feel no parentheses is the best.
And although I like tabs for Python and GDScript I think that folliwing a well-defined set of rules like PEP8 is a good thing, so ident with spaces is good for me.

Alright, so the consensus so far seems to be:

We follow PEP8, including 4-space indent.
We use the pythonic if cond: instead of the C-style if (cond):. Parenthesis can still be used when relevant, especially for multiline line conds.

Two other points that come to mind and not (fully) covered by the above:
Line wrapping
PEP8 advises to wrap lines at 79 chars, and 72 chars for docstrings. They allow going over 80 chars and up to 99 chars on lines that make more sense when long than when arbitrarily wrapped, if there is an agreement in the team about it:

Some teams strongly prefer a longer line length. For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the nominal line length from 80 to 100 characters (effectively increasing the maximum length to 99 characters), provided that comments and docstrings are still wrapped at 72 characters.

I must say that arbitrarily cropping lines at 79 chars often produces weird code, so we need to stay clever and try to ensure that we keep short lines while keeping readability. So I think allowing the "up to 99 chars when relevant" clauses would be good for us, with a strong encouragement to keep below 79 when possible. WDYT?
Single vs double quotes for string literals
I don't think there is an official Python recommendation for this, but the use case I've seen so far is to use single quote ('hello') for "functional" strings/tokens/identifiers (e.g. keys to a dict, etc.), while using double quotes ("Hello world.") for real "text" strings, like sentences meant to be printed (and maybe paths too?).
I've tried using that in my last PR, thus producing code like:
opts.Add('tools', "Build the tools a.k.a. the Godot editor (yes/no)", 'yes')
Feedback welcome on this one, especially if you know of more formal conventions we could follow, which would be better than just following one's gut feeling about the "purpose" of a given string literal.

I usually always write double quotes because I got used to it from C, C++, Java, C# and GDScript. Also because my azerty keyboard requires only one keypress to get one (though qwerty requires shift).
I like the idea of using them for visible text VS functional, although localization would make these transform into single-quoted identifiers anyways, so in the end only non-translated, dev messages would end up like that (but considering the scope of this issue I don't think they will ever be localized :p).

Python console seems to  prefer single quotes:
# ~ $ python
>>> "text"
'text'
>>> 'text'
'text'

Tested on Python 2.7.12 and Python 3.5.2.
This may be considered pythonic way.

Also can an prettifier tool understand the distinction between "functional" and "printable" text if it will be used for enforcing standards?

+1 for PEP8 compliance - it was done for BCE and now the code is much easier to maintain since there is some static checking (flake8). I honestly think that with all the debates on coding style on the web, PEP8 is the one thing that everybody can settle on.
Also, I would also go with single quotes.

What about multi-line comments?
Any plans to support them anytime soon?
Testing groups of logic is harder without them.

Is this considered resolved by #37421?

Yes. We still have to document this in godot-docs but this should be tracked there.


connected() not reliable test

I have the ubidots/ubidots-mqtt-esp/issues/3 with Ubitdots using pubsubclient that the test of client.connected() is positive but actually broken.
Not entirely sure why this happens, it might be related to ip changes occuring.
Is there a better way to test if the subscription is still active?

I have the same issue. Client.connected() and client.state() both return true indicating the connection is present even if I disconnect the wifi module completely during operating.

Hi, if the underlying client claims to be connected then we believe it. The underlying network isn't the responsibility of this client. Which client are you using and have you asked on their issue tracker?

Ah hmm. I'll just look into how that might affect it , I'm using tinyGSM https://github.com/vshymanskyy/TinyGSM/ to connect via GPRS to IBM Bluemix. Thanks for the hint.


feat(card): introducing static variant with tag-group

Related Ticket(s)
#5962
Description
DDSCard will becoming "static" if no link is passed to the href attribute. This new variant includes the light theme, with optional tags.
Changelog
New

Card static variant when no href is passed in

Changed

set delegateFocus in this.attachShadow to false due to focus bug only happening in Chrome

Shouldn't the Static card get the outline from Card group?

Hover on text link should get the underline (pls double check to make sure this doesn't affect the other components! I think we've seen the underline in link too often in the wrong places)

Knobs should have: these options:

In addition to some of Shixie's comments, can we get a knob to toggle the light variant theme on and off, and maybe able to see it with an image and eyebrow. I'm really curious about how it's impacted with an image in there.


Uniformly allow abstract numeric types

Summary
In most cases throughout the codebase, this converts type checks of the
form
isinstance(x, int)
or similar with float or complex with comparisons to
numbers.Integral, numbers.Real or numbers.Complex as appropriate.
This is because there are common types which still behave like numbers,
but do not subclass the built-in types, such as numpy.int64 and
friends.  A few places in the code already attempted to handle these,
but it was not uniform throughout, and so using numbers taken from a
Numpy array would work with some parts of the codebase, but not others.
Very little in Qiskit relies on the underlying numbers being exactly
the built-in types, so allowing any type that fulfills the interface of
the relevant ABC is appropriate.  Things like equality and hash are
fixed by the specification, so all representations of the number 1,
for example, count as the exact same object when used as a dictionary
key or whatever, no matter if they are really int, np.int32 or
anything.
In general, type-validation functions are modified to return their
outputs as a built-in type, if possible, in order to be flexible in what
Qiskit functions accept, but prescriptive in what they return.  This
should make code a bit more robust for users.
There are a few places where it was not appropriate to modify the type
checks.  Of particular note is in qpy_serialization, where maintaining
the exact binary representation of the inputs means that the exact type
is important; numpy types have different widths, and are handled
separately.

Details and comments
This builds on a few far more targeted PRs (e.g. #6910), with the intent of unifying numeric handling across Terra.  The main use-case is handling numbers that are taken out of Numpy arrays, and making it so these should be more uniformly accepted, rather than only working in functions that people have previously raised issues for.

This was done in the past and resulted in a noticeable performance regression, see:
https://github.com/Qiskit/qiskit-terra/pull/4591 and https://github.com/Qiskit/qiskit-terra/issues/4791
Have you tested the performance of this and confirmed this doesn't cause the same regression?

I'm kind of inclined to do away with PEP3141 numeric tower elements completely since they don't actually seem to do what you want them to. For example even built-in stdlib Decimal is neither real nor rational. Guido van Rossum appears to agree https://github.com/python/mypy/issues/3186#issuecomment-294889558


Latest Dev Version (#74) Right Click NPC Error

Get this error in the console when I right click an NPC to finish a stage.
http://pastebin.com/y6DvQni8
Update: I found that this was an issue with capitalisation with the enchantnemt and the Reward item given. I did enchantment-unbreaking 10 instead of enchantment-Unbreaking 10.
Maybe this should be pointed out as an error when doing /questsadmin reload, something like incorrect enchantment on item reward? Make it easy for players to configure this properly.

I see no-one was able to resolve your issue. If this is still a problem, please create a new ticket. Thanks!