Click the refresh icon and get a new joke every time:)

I submitted the request with screenshot .

can you modify the existing dad joke extension

It is already edited, i have added a refresh button so without closing you
can get a new joke.
So,i would apreciate it very much if you could merge this one
On Tue, Oct 5, 2021, 00:41 Paras Yadav @.***> wrote:

if not tell me i will merge this one, I would suggest you atleast try.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/DaNnyKg07/Chrome-Extension-hacktober2021/pull/6#issuecomment-933775448,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AVMORZZPXYRFAUBJZKLZKSLUFH36BANCNFSM5FJZZVDA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

👍


FunC reports "lvalue expected before...." on a program accepted by the Tact compiler

Are you using the latest released (or pre-released, a.k.a. "next") version?

[X] I'm using the latest Tact version

Tact source code
struct MapWrapper {
    m: map<Int,Int>
}

contract Test {

    get fun test(): Int {
        let m: map<Int,MapWrapper> = emptyMap(); // Nested map simulated using a wrapper struct
        m.set(100, MapWrapper {m: emptyMap()});
        m.get(100)!!.m.set(10, 5);  // This line causes the problem.
        return 0;
    }
}

Relevant Tact/build system log output
Func compilation error: /..../test_Test.code.fc:22:109: error: lvalue expected before `~__tact_dict_set_int_int`
      $MapWrapper$_get_m($MapWrapper$_not_null($MapWrapper$_load_opt(__tact_dict_get_int_cell($m, 257, 100))))~__tact_dict_set_int_int(257, 10, 5, 257);

What happened?
No response
What did you expect?
Tact should reject the program, because FunC does.
Steps to reproduce
No response
How do you run Tact?
No response
Anything else?
No response

m.get(100)!!.m.set(10, 5);

should be allowed, but since it's useless code it needs to be reported either by Tact or by misti.
The intuition here is that the code modifies the nested map, but it's not going to happen since .get returns a copy of the corresponding map value and not some kind of reference to it. We should just supported nested maps at the language level.

Just to provide further examples where the error occurs when using user-defined mutating and extends functions.
Continue with the same setting described by the bug above.
Define the following functions:
extends fun unwrapAndCopyMap(self: MapWrapper): map<Int,Int> {
    return self.m;
}

// The only difference with the previous function is that this one is a mutating function.
extends mutates fun unwrapMap(self: MapWrapper): map<Int,Int> {
    return self.m;
}

// The identify function as a mutating function
extends mutates fun reflectMap(self: MapWrapper): MapWrapper {
    return self;
}

Then each of the following lines will produce the error:
get fun test2() {
        let wm = MapWrapper {m: emptyMap()};
        wm.unwrapAndCopyMap().del(1);        // FunC error
        wm.unwrapMap().del(1);               // FunC error
        wm.reflectMap().unwrapMap().del(1);  // FunC error
}


fix: get the max contributed day error

Summary
If the max contributed day is the first day in the year, its index is 0, so we will get the error result by old code.
new Date(2021, 0, 0)  // Thu Dec 31 2020 00:00:00

Test Plan
The parameter day of new Date is a real date, which is not like a index as the parameter month, so we can fix it by format the index to real date.
new Date(2021, 0, 0 + 1)  // Fri Jan 01 2021 00:00:00

Thanks for noticing this error, LLawliet.
The current solution works sometimes:

This is my result with maxDayIndex + 1:

What would be another approach to generating a date from the maxDateIndex-th day of year?


Prototype WeakRef support with a SpiderMonkey shell polyfill

https://gist.github.com/tschneidereit/51dd7d5b51e16e21f8281b111fe638d1 is a polyfill for the upcoming WeakRef proposal, and we're definitely going to want to make use of it to avoid the need to manually call free on Rust structs exported to JS.
We should add an option to wasm-bindgen (probably an env var for now) to tailor output of wasm-bindgen for the SpiderMonkey JS shell and use these weakref bindings!

cc @tschneidereit

I might be wrong, but my understanding is that the WeakRef proposal does not guarantee that the destructors will run in a timely manner, so there could be an arbitrary amount of time before the object is garbage collected, so it would still be useful to manually call free to guarantee fast and deterministic cleanup.

I might be wrong, but my understanding is that the WeakRef proposal does not guarantee that the destructors will run in a timely manner, so there could be an arbitrary amount of time before the object is garbage collected, so it would still be useful to manually call free to guarantee fast and deterministic cleanup.

I agree that it's good to also provide a way to manually free memory. The idea isn't to use finalizers as some kind of RAII mechanism; if you know when to call free, then you should definitely do that.
However, there are a lot of situations where you simply cannot know when you should free a resource. E.g. if you have data associated with a DOM node whose lifetime you don't control—when do you free that data? Without finalizers, you only have the two options of either leaking memory, or somehow restructuring things such that you do control the node's lifetime. In particular if you want to use WebAssembly for only part of your application and keep the rest in JS, the latter often won't be possible.


run str_to_midi.py error

when I run str_to_midi.py. the error occur:
  File "/xxxxxxxxxxxxxxxxxxxxxx/MIDI-LLM-tokenizer/midi_util.py", line 93, in from_json
    return cls(**config)
TypeError: VocabConfig.__init__() missing 1 required positional argument: 'velocity_bins_override'

could you help me? what error it is and how to solve it?

This fixed it for me:

Delete this line:

    velocity_bins_override: Optional[List[int]]

Add this at the end:

    velocity_bins_override: Optional[List[int]] = None

See screenshot:

thanks， I use vocab_config_v2_wip.json is also OK!!

I wouldn't recommend using the WIP vocab config. It won't work with any existing models

Fixed by https://github.com/briansemrau/MIDI-LLM-tokenizer/commit/734d081c9b56ebf77d52cff8612a3e5451b3086a


Also read /etc/luminaDesktop.conf.

On (at least) OpenBSD, external packages are installed under /usr/local
but SYSCONFDIR is always /etc. That is external applications will
install their configuration file under /etc even if the binaries are
under /usr/local.

Looks good!

This is also good for Linux as well


Revised IE: Implement callbacks with strict ordering

OnObjectX callbacks differ from OnX callbacks in that OnX callbacks are called per InteractionHand. InteractionBehaviours provide another set of callbacks that are hand-independent, to provide an easier interface for specifying interaction behavior that is not duplicated when two hands are near the same interaction object. OnObjectHoverX callbacks are implemented but are not documented, and are neither implemented nor documented for OnObjectGraspX and OnObjectContactX.

Callback ordering is going to be a little tricky with the new planned callback setup in leap-gui-interaction.

Strict ordering to abide by:
OnGraspEnd
OnObjectGraspEnd
OnContactEnd
OnObjectContactEnd
OnPrimaryHoverEnd
OnObjectPrimaryHoverEnd
OnHoverEnd
OnObjectHoverEnd

OnHoverBegin
OnObjectHoverBegin
OnPrimaryHoverBegin
OnObjectPrimaryHoverBegin
OnContactBegin
OnObjectContactBegin
OnGraspBegin
OnObjectGraspBegin

OnHoverStay
OnObjectHoverStay
OnPrimaryHoverStay
OnObjectPrimaryHoverStay
OnContactStay
OnObjectContactStay
OnGraspHold
OnObjectGraspHold

Implemented as of latest interaction-callbacks-revamp, to be merged shortly into feature-leap-gui


parquet-pig should not throw an exception reading a timestamp from impala file

Hi, I need to load impala table with timestamp columns with pig. I think loading timestamp cols is still a NYI feature. Waiting for #218 TBD, pig-parquet should not throw an exception but at least should bind Int96 into a bytearray (users can write their own UDF to convert it into pig datetime type).
Is there anyone working on that?
Reporter: gpolaert
Note: This issue was originally created as PARQUET-195. Please see the migration documentation for further details.

Ryan Blue / @rdblue:
Could you post the exception you're getting from Pig when you try to read a timestamp? We've added support for the underlying data type (int96 as you noted) to show up as a byte array, so I think this might be a bug rather than a NYI feature.

gpolaert:
I've just patched the 1.5.0 branch for my own purposes; it's the same thing with the master and 1.6.0rc4 branches . I don't have my code right now but the exception comes from PigSchemaConverter class  (line 238).
The patch simply return a DataType.BYTEARRAY instead an exception.

Cesar Delgado / @beettlle:
[~gpolaert] it looks like a change similar to what you've described is already in Parquet master here.  Does that change work for you?

Ryan Blue / @rdblue:
Okay, so the int96 support is only in the common libraries and Avro, but not Pig. Would you mind posting your fix as a pull request so we can fix master? Thanks!


iFrame in iOS is huge

The space of the iframe in iOS is way bigger than the iFrame itself.

Fixed at https://github.com/wp-pwa/wp-pwa/commit/15bcd30791e5724baf272b70f2e68051d81b7900

@DAreRodz what was the problem?

@luisherranz  It's a bug on iOS that resizes iframes to the full size of their content. I used a workaround with CSS to avoid this and now it's working in Chrome and Safari iOS.

Good to know! Thanks.


The CreateRepositoryRequest class is missing the RepositoryPolicyText property

Hello, I'm using the ECR client, latest version (v<IP_ADDRESS> as of today).
The class Amazon.ECR.Model.CreateRepositoryRequest does not contain the RepositoryPolicyText which is documented here, on the CloudFormation guide.

Is this intended?
Thanks.
EDIT: I know I can set the policy by invoking SetRepositoryPolicyAsync right after che repository creation but I wonder If you could still add the RepositoryPolicyText property for consistency with CouldFormation. All of the other request classes I've used so far seem to be consistent.

Thanks for reporting this.  We'll reach out to the ECR team to see if we can get this added.

Hi @Halleymedia,
Good afternoon.
I was going through backlog and came across this issue. This does not appear to be an issue. Kindly refer the CreateRepositoryRequest service API operation. It also does not define RepositoryPolicyText property. On the similar lines, model class CreateRepositoryRequest in AWS SDK for .NET does not define any such property.
The guide you are referring to is for the CloudFormation template. There might not be one-to-one mapping between CloudFormation and service model classes. AWS .NET SDK model classes are based on service API model classes.
For you scenario, you might want to use SetRepositoryPolicyRequest class with AmazonECRClient.SetRepositoryPolicyAsync method.
Hope this helps.
Thanks,
Ashish


AUTH : Fix version check to avoid crashing on API detection through v…

Dear Maintainer,
I've ecountered an error using the GIT version of Etcd, you get versions such as "3.2.0-rc.1+git"
Previous code led to this error:
"/usr/lib/python2.7/site-packages/etcd/auth.py", line 25, in legacy_api
major, minor, _ = map(int, self.client.version.split('.'))
ValueError: invalid literal for int() with base 10: '0-rc'

This proposes a (very) simple fix by only keeping the beginning of the version string.
Regards,
Jean-Baptiste.

Coverage remained the same at 88.071% when pulling 30650f6c98b8abd508a8d12d7df7fc3633c8c454 on besnardjb:master into b227f496c038b2b856c4d76c9525b3547e5c8dc4 on jplana:master.


Optional data - links

[x] configure remove_links.  Set as default false to maintain backwards compat.
[x] ensure included not merged into payload if not configured.

I also removed the included data if not configured at view level as a second commit.  Lmk what you think!

Updated branch with master.

@snewcomer ugh brain fart, thank you!

@snewcomer should also fix the credo complaints <3 and then I'll merge this. I'm planning on cutting a new release tomorrow evening.

@doomspork fixed!  Possible to squash in the github UI when you merge?  If I do squash, I think I'll lose your comments.  Lmk if that is not the case and I'll squash!

Thanks! @snewcomer!


Why is function registerTranslation not merging translations with same $code?

Let's assume you are developing an app that is using @shoelace-style/shoelace and two completely independent third-party component libraries @author1/some-datepicker and @author2/some-datagrid.
All three are using @shoelace-style/localize for localization.
All three have their own translation files for locale en.
Function registerTranslation is not merging translations if several translations with the same $code value are provided, means already given translations will be completely overridden and translation information will get lost.
The logical conclusion is that either it may not be a good idea that registerTranslation is not merging given translations with the same $code value, or that libraries NEVER should call registerTranslation, only applications should call registerTranslation and merge given library translations by themself.
To make a long story short: I claim that registerTranslation should really merge given translations with same $code and that this fallback: Translation variable should be replaced by fallbackCode: string.

Good suggestion. As you stated, registerTranslation() will currently overwrite any existing translation with the same code. It would be convenient to have an official way to extend translations.
Currently, the only way to do this at runtime is to import the translation and do this:
import translation from '../en.js';

translation.newTerm = 'New Term';
translation.complexTerm = val => `The value is `${val}`;

While this works, it's not an ideal solution for extending because you need to know where the translation file lives to import it and, if it's strongly typed, you'll need to re-export a new type and keep track of this each time you extend the translation.
My only questions are:

Should this be done in registerTranslation() or in a new method, e.g. mergeTranslation()?
What does this mean for users of strongly typed translations? i.e. if I've typed all my terms, what does it look like to combine them in a way that TypeScript still understands?

This is not really tested properly, but I think something like this should (hopefully :wink:) work (rest remains as is):
//
// Registers one or more translations
//
export function registerTranslation(...translation: Translation[]) {
  translation.forEach(t => {
    const code = t.$code.toLowerCase();

    if (translations.has(code)) {
      Object.assign(translations.get(code), t);
    } else {
      const t2 = { ...t };
      translations.set(code, t2);

      // The first translation that's registered is the fallback
      if (!fallback) {
        fallback = t2;
      }
    }
  });

  update();
}

@claviska Thanks for altering function registerTranslation to use "merging" instead of "overwriting".
I'll close this isse then.


How to start a crop only when we already have image file/uri?

User has an image file selected somewhere in my app, and now user just want to start cropping that image. What code should I use?

I have same question about it. Did you solve it? @andj207

@sinhpn92 I don't know how with this lib, I decided to use the lib here https://github.com/ArthurHub/Android-Image-Cropper

@andj207 Humzzz.
Thanks. I have used uCrop for my project. uCrop was used by this lib too.

@andj207 https://github.com/ArthurHub/Android-Image-Cropper is deprecated and @sinhpn92 ucrop has issues with Android 10/11
I'm using https://github.com/CanHub/Android-Image-Cropper that come from the one @andj207 said. And is maintaned.

@vcuk21 I have tested uCrop on Android 11/ Samsung galaxy s10+ and emulator pixel 3 with android 10. It's working fine.

hmm, I saw many issues and this one: https://github.com/Yalantis/uCrop/issues/715
So I'm going for the one which is more maintained, but if works for you use, is an amazing lib!

@andj207 ImagePicker doesn't support crop-only feature. You can use uCrop library directly in your project.


Update the patch file of geographiclib

 ${TOOLS} should be removed from the export command, otherwise cmake config will fail. This is a mistake in my previous pull request, which is changed locally but not made in the patch file.

@saedrna,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by Microsoft. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

Thanks for the fix!


Error using Tesseract for java via Maven dependency

Environment ::
Tesseract  for java : 3.4.3
Platform: Ubuntu 16.04 64 bit
Current Behaviour ::
I am using maven dependency
<!-- https://mvnrepository.com/artifact/net.sourceforge.tess4j/tess4j -->
<dependency>
    <groupId>net.sourceforge.tess4j</groupId>
    <artifactId>tess4j</artifactId>
    <version>3.4.3</version>
</dependency>

When calling OCR to get text from png file, the result from using Tess4J in Java displays the following error. The text (default output) is not created.
Error opening data file ./tessdata/eng.traineddata
Please make sure the TESSDATA_PREFIX environment variable is set to the parent directory of your "tessdata" directory.
Failed loading language 'eng'
Tesseract couldn't load any languages!
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f5b4791bac7, pid=8466, tid=0x00007f5ba3fdb700
#
# JRE version: OpenJDK Runtime Environment (8.0_151-b12) (build 1.8.0_151-8u151-b12-0ubuntu<IP_ADDRESS>-b12)
# Java VM: OpenJDK 64-Bit Server VM (25.151-b12 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libtesseract.so.3.0.4+0x9dac7]  tesseract::Tesseract::recog_all_words(PAGE_RES*, ETEXT_DESC*, TBOX const*, char const*, int)+0x5e7
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/grid/eclipse-workspace/jumpstart/hs_err_pid8466.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

Expected Behaviour ::
The expected behaviour is that it should ocr the png file as I am using the maven repository , so there should not be any issue regarding the tesseract could not load any languages.
Suggested Fix ::
Check the maven repository for Tesseract for java as I have used two versions 3.4.3 as well as 3.2.1 . In both of them I get the same error that I have mention above.

We do not support 3rd party projects. Please respect instruction for posting issues.

Hello @zdenop
Sorry it's my fault that I have raised the issue here instead of in tess4j .


Support for album having multiple artists

Enable support that an album can have multiple artists
Including backwards compatibility
Including database migration
No rescan of existing media, a simple "refresh" on an album will reveal the additional artist(s)

fixes https://github.com/music-assistant/hass-music-assistant/issues/220
fixes https://github.com/music-assistant/hass-music-assistant/issues/241


Updated Android Gradle

This is an update to android embedding and gradlle dependencies

@benthemobileguy
Sorry for the late confirmation. 🙏
No problem, I'll merge it.
Thanks for the great job! 👍
I'll fix the conflicts here.


bug: swipe to close modal does not use custom animation

Bug Report
Ionic version:

[x] 5.x
Current behavior:

Modal with custom leave animation is not used when swipeToClose = true. The standard card-style animation is used.
Expected behavior:

I would expect that users can provide a custom animation to the swipe to close modal.
Steps to reproduce:

Open https://codepen.io/ionic/pen/ExapZBZ.
Set modalElement.mode = 'ios'.
Set modalElement.swipeToClose = true.
Open modal and attempt to swipe closed.

Code for possible fix: https://github.com/ionic-team/ionic/blob/master/core/src/utils/overlays.ts#L129-L132

Resolved by https://github.com/ionic-team/ionic/pull/20585


more style fixing

Codecov Report

Merging #523 into master will decrease coverage by 87.12%.
The diff coverage is 2.22%.

@@            Coverage Diff             @@
##           master    #523       +/-   ##
==========================================
- Coverage   91.64%   4.52%   -87.13%
==========================================
  Files          36      36
  Lines        2802    2809        +7
==========================================
- Hits         2568     127     -2441
- Misses        234    2682     +2448

Impacted Files
Coverage Δ

setup.py
0% <ø> (ø)
:arrow_up:

vent/api/actions.py
1.56% <0%> (-91.28%)
:arrow_down:

vent/core/rmq-es-connector/rmq_es_connector.py
40.47% <0%> (-59.53%)
:arrow_down:

vent/core/rq-worker/test_rq_worker.py
41.17% <0%> (-58.83%)
:arrow_down:

vent/api/plugins.py
0.74% <2.43%> (-91.37%)
:arrow_down:

vent/menus/help.py
0% <0%> (-100%)
:arrow_down:

vent/menus/services.py
0% <0%> (-100%)
:arrow_down:

vent/core/rq-worker/settings.py
0% <0%> (-100%)
:arrow_down:

vent/menus/inventory_forms.py
0% <0%> (-100%)
:arrow_down:

vent/menus/tutorials.py
0% <0%> (-100%)
:arrow_down:

... and 30 more

Continue to review full report at Codecov.

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


Add initial app version

This PR :

adds the initial chart

Depends on https://github.com/giantswarm/config/pull/281
Checklist

[x] Update changelog in CHANGELOG.md.

@mig4 do I need to configure the oauth redirect on this ingress ?

@mig4 do I need to configure the oauth redirect on this ingress ?

No let's leave that for a follow-up patch in case it's the way to go. I still need to test with a customer login as I'm not convinced it'll work in that case.

Sure, I just have an issue with architect now :D It's not resolving the Branch and SHA in the values file: https://gigantic.slack.com/archives/C3C7ZQXC1/p1627479354101800
Maybe you have a hint ?

Sure, I just have an issue with architect now :D It's not resolving the Branch and SHA in the values file: gigantic.slack.com/archives/C3C7ZQXC1/p1627479354101800
Maybe you have a hint ?

Those jobs you linked to are green, what/where's the problem?

So basically,  architect should replace the following in the values file when generating the app and pushing it to the repo but it's not touched so helm cannot install the app:
project:
  branch: "[[ .Branch ]]"
  commit: "[[ .SHA ]]"

You can see this in the values file here: https://giantswarm.github.io/giantswarm-playground-test-catalog/macropower-analytics-panel-server-0.0.0-6a0a2ebc7ac3dc1813fb6082c9a4b0b2900f22f2.tgz


[2.6] Code is always being instrumented

backport

2.7 work: https://github.com/rancher/dashboard/issues/7649

QA shouldn't have anything to do here, similar for the 2.7 ticket.


add proguard rule to keep geosubmit classes - fix #81

This definitely fixes the problem, but may be too liberal and keep more metadata than absolutely needed for (de-)serializing reports.
I didn't have the patience to read deeper into ProGuard and try many different rules :sweat_smile:

replaced by #83


Update jquery.ui.monthpicker.js

fixed the custom jquery.effects ($.effects.effect)

Was this a change from jQuery UI update? How far back in jQuery/jQuery UI is this supported?

It seems to me that selecting an effect always used to be done by $.effects.effect[theEffect]. The jQuery UI Datepicker uses if($.effects && $.effects.effect[ showAnim ])

Looks good, thanks! :star:


Signing in with email the first time on iPad, the sign in button below the fields is often not visible

The illustration image is far too large and this pushes the button below the default window size / iPad screen size.

I have a simple workaround for this to set a max height on the image that I will make a PR for.

Wow Marc you're on fire! 🤩


Exercises: Show categories in course management

Is your feature request related to a problem?
When viewing the list of exercises, the categories that those exercises are assigned to are displayed nowhere. I can only see them when editing an exercise.
Describe the solution you'd like
It would be convenient if I could see the categories right in the list.
Describe alternatives you've considered
No response
Additional context
No response

Hi! I would like to work on this issue. Is there more information or suggestions on how this should look like when implemented?

We could display the categories for course exercises in the exercise lists. However the table is already quite wide, so we need to be careful that it does not get too wide. Probably one category per line might be appropriate with the color badge


Membership stats graph is incorrect

In gitlab by @A-Lawrence on Jan 11, 2016, 23:54
Labels "Members Division" as "Members Total" and vice versa.

In gitlab by @NFarrington on Jan 12, 2016, 17:37
@A-Lawrence addCurrentMembersStatistic() doesn't account for members with null created_at dates (of which there are many), hence why total members appears to be less than division members (which seem to be calculated from a different table, hence why the error isn't reproduced here)

In gitlab by @A-Lawrence on Feb 1, 2016, 21:24
I've manually fixed the null created_at timestamps.  I need to check if they start to occur again and then track down where it's happening (as it shouldn't be).
There are a lot of past members that have a NULL joined_at date, because they've been suspended.  I don't think there's much we can do with that.

In gitlab by @A-Lawrence on Feb 1, 2016, 21:25
Query that was ran:
UPDATE `mship_account`
SET `created_at` = `joined_at`
WHERE `created_at` IS NULL
AND `joined_at` <> '0000-00-00 00:00:00'

In gitlab by @A-Lawrence on Feb 1, 2016, 21:36
mentioned in commit 5abcb4d751ddbfff4f697a74d0c8f3aac32e3bb0

In gitlab by @A-Lawrence on Feb 1, 2016, 21:51
mentioned in commit 7a1190406e9bf396993d4ddbcd740daa6f2fb6d2

In gitlab by @A-Lawrence on Feb 1, 2016, 21:52
This should now be resolved in commit 5abcb4d7.  When the next version is deployed, all stats need to be recreated (readme updated: 7a119040)


support "AMP Real URL"

AMP Real URL
Display your site’s actual URL on your AMP pages, instead of the traditional Google AMP cache URL
Navigation: Speed > Optimization > Mobile > AMP Real URL

Hi @thanhtoan1196
Thanks for opening this issue - please can you link me to the API functionality that supports this? I can't see to find it :/
Paul

@stack72 Well, it looks like there is no api for this function
I will close the issue.

Ah I'm really sorry about that @thanhtoan1196 :/


Bump aiohttp from 3.8.5 to 3.9.0

Dependabot has upgraded aiohttp in the neofs-testcases project, and since we use neo-mamba as a dependency, we would like to fix the version conflict by upgrading aiohttp to the latest version.

coverage: 80.98%. remained the same
when pulling 5349474e02682388c038afe80384cbd358a9536d on vvarg229:update-aiohttp
into 74581fa93b1c931d5be1d2f0e48ccd646cfc851e on CityOfZion:master.


UC3/US6 Collect data from Horizon Europe projects for EU dashboard

User Story
As an IT operator at JRC-Soil
I want to find, filter and download soil data from Horizon Europe Research projects
So I can aggregate the data and make a dashboard for our policy officers which displays status of Soil Health over time
Persona
I’m confident with approaches for data publication in academia. My focus is on Horizon Europe projects, advertising their results via Cordis.
Background
This user story has been derived from the notes of the JRC Ispra meeting:
“SoilWise should contribute to EUSO elements and support the EUSO dashboard, a communication tool that includes indicators and requires the provision of data flows from results also coming from R&I projects like SOMIMO AA.
Acceptance criteria
From 5 projects in the Soil Mission round, which indicate in their DMP they provide relevant data, assess if this data is actually usable for the soil mission dashboard. An assessment should take 5 minutes at max, the assessment result should include:

[ ]	Is data discoverable with persistent identifier (Findable)
[ ]	Can data be downloaded using common protocol (Accessible)
[ ]	Options for harmonization (model and code list description and compatibility) (Interoperable)
[ ]	Has described usage constraints (data license) (Reusable)
[ ]	Has described resolution in time and space (Reusable)

Extracted Requirements:

01.1 - Data Discovery - Query Catalogue: query data from horizon Europe projects (from Cordis) including filters
04 - Download data: download data from Horizon Europe projects
06 - Data quality checks: check if data are FAIR (Persistent ID, Common Protocol, usage constraints, Spatiotemporal resolution)
08 - Vocabulary: Use of standard vocabularies/ontologies
10 - Data harmonization: data can be downloaded using common protocol


Properties renamed for proto3

The docs say that hasXyz properties are only generated for proto2 optionals, so it seems like proto3 fields don't need to be renamed. Using version 0.9.904, this:
syntax = "proto3";
message Foo {
    string bar = 1;
    string hasBar = 2;
}

results in:
var bar: String = String()

var hasBar_p: String = String()

There's no generated hasBar, so is there an option to prevent the renaming?

I'll have to go back and double check, but I don't think our renaming code checks if the files are proto2 vs. proto3 syntax when checking for a "has" or "clear" collision.
Also need to figure out if it would be confusing to only rename on the proto2 syntax case (if a developer is dealing with a message that has a field that comes from a file with the other syntax, they could see both sets of behaviors pretty easily.

IMO, having different naming schemes for proto2 and proto3 only has the potential to lead to confusion, especially as you said if proto2 and proto3 messages are mixed.
Given that the has* pattern exists throughout many of the protobuf implementations, I think it's reasonable to suggest that users not name their properties using that prefix because Swift isn't the only language where they would run into this problem.

Yup, the code that checks for these names doesn't currently factor in the syntax of the defining file to decide if there will be collisions on has/clear.
As mentioned and @allevato chiming in, the next question becomes should this not do the renaming.  There as been a few requests for having support for has even in proto3 syntax avoid having to use wrappers and directly support nullability of the fields when using JSON.  google/protobuf#1606 has a fair amount of the traffic on this; and while the current decision is no, looks like the protobuf-team seems to imply this could get revisited based on need.
So at the moment, it seems like staying consistent and avoiding a potential rename in the future is the better idea.

Actually, I'll try to find it, I thought there was discussion of also including the has methods for fields in an oneof for both proto2 and proto3.  I think a few languages already do this, and Swift might be acting differently there.
ps - I believe the logic is in part for a proto2 syntax file it makes it safer to move a field into a oneof without breaking code; and for proto3 syntax file, it lets the oneof with a single field be an easier way to add presence for for an individual field without having to use a wrapper message which does have more api and wire overhead.

It's good to know there's been discussion about this already. Based on xfxyjwf's comment, it doesn't seem like the protobuf-team is all that keen on bringing back field presence, since they deliberately dropped it for proto3.
If users are mixing proto2 and proto3, I'd expect them to be prepared for different naming schemes, but I can understand wanting to be consistent by default. What do you think about adding a swift_opt to turn off the renaming?
I'm interested in the oneof discussion. If the has properties do get included in proto3, why wouldn't they be the ones to get _p added?

It's good to know there's been discussion about this already. Based on xfxyjwf's comment, it doesn't seem like the protobuf-team is all that keen on bringing back field presence, since they deliberately dropped it for proto3.

Unknown fields were also stripped during binary parsing for proto3 and that got reversed with enough evidence at how it made things harder.   So while the current position seems to be against bringing any presence back, there's enough folks asking about it I'm hesitant to say the door is completely closed.

I'm interested in the oneof discussion. If the has properties do get included in proto3, why wouldn't they be the ones to get _p added?

Consistency with the proto2 syntax has methods and consistency with the other languages.

Trying to search for has and oneof on the google/protobuf issues and the google group isn't letting me find the thread I think I've see before.  🙁

No problem, thanks for looking!


At browser width < 768, after click on next button it is work just once. If i click again - nothing.
Prev button works fine.
After click on prev button if i click to next button, sometimes, animation is lost, and slides changing immediately.
js
` var awards = new Swiper('.js-mk-awards', {
slidesPerView: 3,
loop:true,
nextButton: ".js-mk-awards-slider-next",
prevButton: ".js-mk-awards-slider-prev",
    breakpoints: {
        1024:{
            slidesPerView: 2
        },
        768:{
            slidesPerView: 1,
            slidesPerColumn: 3
        }
    }
});`

html
`

      <button class="mk-award__close-overlay / js-mk-award-close">

      </button>

Award title

Award text.

Award quote

              —
              Award link

Award title

Award text.

Award quote

              —
              Award link

Award title

Award text.

Award quote

              —
              Award link

Award title

Award text.

Award quote

              —
              Award link

Award title

Award text.

Award quote

              —
              Award link

Award title

Award text.

Award quote

              —
              Award link

Award title

Award text.

Award quote

              —
              Award link

    <button class="mk-awards__slider-button mk-awards__slider-button--prev / js-mk-awards-slider-prev">

    </button>
    <button class="mk-awards__slider-button mk-awards__slider-button--next / js-mk-awards-slider-next">

    </button>

        <button class="awards-toggler__btn / js-toggle-hide">
          Hide text
          Show text
        </button>

`

Expected Behavior
EXPLAIN WHAT IS TO BE EXPECTED, HERE.
Infinit next rotation when i click to next button, and prev button the same
Actual Behavior
EXPLAIN WHAT IS ACTUALLY HAPPENING, HERE.
P.S. Remember, an issue is not the place to ask questions. You can use Stack Overflow
for that.
Before you open an issue, please check if a similar issue already exists or has been closed before.

I find 2 variables named translate and s.translate.
Translate calculate localy.
If i get it right, they need to calc current state and next state to make transition.
But in my case, when i click to "next" button translate and s.translate are equal. So transition is not happen.
I think there is mistake.
It is interesting.
When i click prev button active index jump between 2 and 1. If we get start edge position active index goes to latest position.
But if i click to next button, we get active index = 3, and it is not changing.

Issue is closed because of outdated/irrelevant/not actual/needed more information/inactivity.
If this issue is still actual and reproducible for latest version of Swiper, please create new issue and fill the issue template correctly:

Clearly describe the issue including steps to reproduce when it is a bug.
Make sure you fill in the earliest version that you know has the issue.
Provide live link or JSFiddle/Codepen or website with issue

Looks like it's still actual. Please check this codepen https://codepen.io/artrid/pen/jzKqxQ. There is no possibility to move next when slider is on the last slide


"WebRTC Server not available" error after migrating HAS

Hello,
I migrated HAS from an RPI4 to a generic PC and everything works fine.
However, the custom WebRTC card always gives me an error when trying to show an rtsp stream.
This happens regardless from the underlying camera. It worked before the migration though.
I reinstalled the webrtc integration and even hacs itself but nothing seems to work.
When I look at the logs, i usually see this mistake (I have no idea if it belongs to this specific error)
I am no expert so I hope someone can help in this matter. Thanks!
Logger: frontend.js.latest.202306080
Source: components/system_log/__init__.py:257
First occurred: 11:10:23 (94 occurrences)
Last logged: 12:15:02

blob:http://homeassistant.local:8123/1fbd3798-1522-4650-9868-b6f6f3ed2285:1:100 ReferenceError: t is not defined
blob:http://homeassistant.local:8123/2d698d0e-bd91-4bf7-a596-f5216c79d03e:1:100 ReferenceError: t is not defined
blob:http://homeassistant.local:8123/d845f96b-0cf0-448e-95b6-3571570de5ec:1:100 ReferenceError: t is not defined
blob:http://homeassistant.local:8123/8bf97cd0-8811-4e8c-a787-0797eba44624:1:100 ReferenceError: t is not defined
blob:http://homeassistant.local:8123/19e0a8d4-0d8f-4e1c-a323-007aba3e2ad7:1:100 ReferenceError: t is not defined

No one able to help with this? There must be someone else out there with this problem I guess?

No one able to help with this? There must be someone else out there with this problem I guess?

I have the same issue
Modify the go2rtc version to 1.2.0 and reboot HA , it works ok.

No one able to help with this? There must be someone else out there with this problem I guess?

I have the same issue Modify the go2rtc version to 1.2.0 and reboot HA , it works ok.

Hey, thanks for your answer.
Could you give me a hint as to how I modify the go2rtc version?
In my Studio Code Server I have a got2rtc.yaml but this file only includes 2 lines with api and rtsp and the go2rtc-1.5.0 file is not editable.
Can you help me out? thanks!

No one able to help with this? There must be someone else out there with this problem I guess?

I have the same issue Modify the go2rtc version to 1.2.0 and reboot HA , it works ok.

Hey, thanks for your answer.
Could you give me a hint as to how I modify the go2rtc version?
In my Studio Code Server I have a got2rtc.yaml but this file only includes 2 lines with api and rtsp and the go2rtc-1.5.0 file is not editable.
Can you help me out? thanks!

In file utils.py,  BINARY_VERSION

You can increase log level to check fail reason.

I've had exaclty the same issue. followed these steps and it works again.
Took me so much time trying to find out.

Same issue on my side after migrating HAOS from Rpi3 to N100 mini pc

After uninstalling and reinstalling webrtc it is still not working.

Hi,
Since v3.4.0 update, all seems to be back to normal.
Thanks

Had this same issue. Noticed, that nothing was running at :1984. Resolved by manually deleting "go2rtc-1.8.1" file from the Home Assistant config-directory, and then re-adding the WebRTC device via GUI.

Had this same issue. Noticed, that nothing was running at :1984. Resolved by manually deleting "go2rtc-1.8.1" file from the Home Assistant config-directory, and then re-adding the WebRTC device via GUI.

Thinks it the best solution, it work for me

config-directory, and then re-adding the

also work for me, great thanks!!!

Had this same issue. Noticed, that nothing was running at :1984. Resolved by manually deleting "go2rtc-1.8.1" file from the Home Assistant config-directory, and then re-adding the WebRTC device via GUI.

Can also confirm this worked for me.

https://github.com/AlexxIT/WebRTC/releases/tag/v3.6.0


Design of HWAddress equality and hashing

This issue is the continuation of the discussion that happens within the pull request #2. Here's @mentalisttraceur's dump of thoughts:

Quick question: do you have any thoughts on different classes, or classes with different names, hashing differently vs the same?
I was thinking that the right default is for subclass instances to compare equal to their base class instances by default (they don't right now, despite the __eq__ docstring saying that they do, due to a bug that I haven't gotten around to committing a fix for) and this means that subclasses should probably hash the same way as their parent class.
Couple examples of this:

The MAC and EUI48 classes. I think the most sensible behavior is that they're effectively aliases, so much so that maybe I should have just done MAC = EUI48 instead of class MAC(EUI48): .... However, maybe someone sees a good use-case for them to count as two different members of a set?

MAC and the MACAllowsTrailingDelimiters example - this seems like a totally clear-cut case of a situation where the difference of type or even just type name shouldn't cause objects to compare or hash differently. Of course, it was kinda bad on my part to suggest changing formats by subclassing. If I provide and encourage a better way, then this becomes irrelevant.

But the current idea of class-aware equality comparison creates a weird hashing and set membership situation.
Sets and dictionaries and so on consider things the same if they are equal, but they expect and rely on equal things to hash the same, right?
So for example, if we have two subclasses of MAC, then they both compare equal to MAC instances with the same address (once the bug I described is fixed) but they compare unequal to each other. Even if we get hashing to be the same, this means we can get different sets purely based on the order of adds to those sets! That's messed up.
For another example, if two HWAddress types compare equal, then you have to know how they hash, and if they hash differently then I think it becomes indeterministic if they get counted as one member or two in the set (deterministic only if we know the underlying implementation details and all operations done, like how many buckets are in the underlying hash table at any given moment and how the hash method's hash is mapped to each bucket).
My current thoughts are:

If addresses just reject anything that's not exactly the class that they are, it breaks the use of subclasses for various stuff, but is easy to fix by overwriting equality operations as appropriate, which could "cast" self to the class that we want to be equivalent to forward to that equality method. This is consistent with a hash by type and address value. The only reasons right now for classes to do subclassing like this are the MAC/EUI-48 situation (honestly I should probably just alias them), the formatting situation (I should probably expose the relevant logic so people could do it without subclassing - how often is there a good reason for this to actually come up anyway? never?)

If classes compare equal by just size and address value, then this is consistent with hashing by size and value. It might also break situations people have with identically-sized addresses that they want to be distinct (when though? is that a real case? I can imagine cases, but real ones? Like what if you have token ring and Ethernet MAC addresses - you probably want logic to distinguish them at the type level, but for equality or hashing purposes you might not? If you have two different hardware address types that have the same bit pattern, are you more benefitted from a "if equal: bad" case being easy to implement, or from keeping them both from colliding in a set or as dictionary keys?)

Of course I should also keep my eyes on the common cases! Those should guide a lot of these choices. The uncommon cases should just be reasonably doable.
The common case has no subclassing beyond what this library does.
The commonest appropriate use case for subclassing a HWAddress subclass would presumably be to add unrelated enriching behavior, and probably should not effect equality or hashing.
Treating MAC and EUI48 as equivalent in all ways seems like it is the right behavior more often than not. (In particular, a reasonable situation is that a user writes code like if is instance(something, Mac address.MAC), and this should not break if something was initialized by someone who used macaddress.EUI48.) So I think I've decided that MAC and EUI48 should be aliases of each other. This is a minor breaking change that would probably effect no one. The one downside of this is that error messages use the class name, so you could get error messages that refer to the other class name. Maybe this means that MAC just shouldn't exist as a name exported by this library, but that's a much bigger breaking change.
Alright that concludes this chunk of the thought dump.

That's quite a train of thoughts you have there. I'll try my best to response to all of them so if something is missing or needs clarification, please let me know.

Please ignore me accidentally closing this issue

I was thinking that the right default is for subclass instances to compare equal to their base class instances by default (they don't right now, despite the __eq__ docstring saying that they do, due to a bug that I haven't gotten around to committing a fix for) and this means that subclasses should probably hash the same way as their parent class.

I believe that the comparison should only be possible for concrete base classes and their subclasses, but not for abstract base classes if there's one. For example, comparing a MAC instance with a HWAddress should not be possible because "hardware address" is an abstract concept while MAC address is very concrete. On the other hand, comparing a MAC with any other derived MAC should be sensible, because at the end of the day, they are still MAC addresses. Well, unless the derived MAC is no longer a MAC address - when the subclass discards the original purpose and only reuses the representation and behaviors - but that's the story of bad designing and programming.
To conclude this, comparisons should only be implemented starting from the concrete class rather than the abstract base class to prevent leaking logic to other concrete classes. This is where I draw the line.
Hashing is a different story though. As far as I'm aware, the main purpose of hashing is to differentiate objects when used data structures such as set, frozenset, and dict source. Therefore, I believe that instances of different classes should produce different hashes, whether they share the same base class or not. For example, when a MAC instance and a DerivedMAC instance with the same value are added to a set, it is expected to see these two objects in the set, rather than just only one. After all, they are, semantically different objects.

Oh I see, sorry, I didn't make this clear enough: in Python, it is not allowed for two objects to both

compare equal, and
hash differently.

From the Python documentation for __hash__:

The only required property is that objects which compare equal have the same hash value

Basically __eq__ and __hash__ must be consistent: if two things compare equal, they must hash to the same value (if they don't compare equal, they can hash to the same value, but the more this happens the worse it is for performance of dictionaries, sets, and so on).
Otherwise you can get a bug that is effectively random and rare, where those two objects usually count as different objects, but sometimes count as the same object, in things like dictionaries or sets.
(This makes sense if you consider that the normal way to implement things like dictionaries and sets is with a hash table. Hash tables internally have some number of "buckets", which are lists in which elements are stored, and the number of buckets changes dynamically depending on stuff like how many objects are stored in the table. The hash of an object controls which bucket an object gets placed in, and it is normal for many hash values to map to the same bucket. A simple version would be to do hash_value % number_of_buckets to decide which bucket the object goes into. But then since buckets can hold more than one object, equality checks are used to decide if an object is the same as any other object in the bucket. So if two objects hash differently but compare equal, they may end up counting as the same object or not, depending on what their hash values are and how many buckets there are and how the implementation uses the hash value to decide what bucket to put the object into.)

You may notice that the world could actually solve the "hash must be consistent with equality" requirement. A hash table implementation could simply do hash(thing) == hash(bucket[i]) and thing == bucket[i] instead of just doing thing == bucket[i], once it has found the right bucket for a thing and is checking if it's already in it or not.
This would of course require recalculating or caching the hash value for every item in the bucket. That's probably one reason why it's not done. It adds overhead to the implementation, just to enable having more notion of "is this thing the same as that thing" in the language.
(Although it seems possible for the caching to be worth doing anyway for a speedup in cases where the hash table has a lot of rebalancing (changing the number of buckets), if the extra space overhead doesn't cause the whole thing to get big enough to lose more speed thanks to cache misses.)
Of course, there is some design benefit to minimizing the number of different but similar "is this thing the same as that thing" concepts in a language. The less different concepts and details developers have to understand and remember just to use something, the less room there is for errors in code due to edge cases that don't match human expectations.
Plus, we don't need set membership and dict let's to be based on something other than equality, because it's very easy to wrap equal objects to add a dimension of difference: for example, (type(my_object), my_object) if we want a set member or dict key to be distinct from another if are different classes.

Thank you for enlightening me more on how hashed collections work. Do you have the reference link so that I indulge myself into?
Now that I know that two objects cannot be equal and produce different hashes at the same time, I'm leaning more on the "different class, different hash" side. As in your original thought, there will be a problem with the EUI48 and MAC since they basically are aliases. But because of you decided on the "subclass route", I, as an end-user, will always expect both EUI48 and MAC objects to exist separately in a hashed collections. I guess that's a trade-off though, either you force users to learn that EUI48 and MAC are the same and educate themselves on the latest IEEE specification in the "alias route", or spoiling them with convenient debugging messages in the "subclass route". That's your call. Even if this introduces some breaking changes, I think it's worth it because technology changes and breaks more frequently than ever.
Other than that, I don't see any further problem, assuming that you still uses both the integer address value and the format structure of the address as hashing component.
Also, I don't think there is a need to create additional subclass for what the library already provided. Honestly, there shouldn't be. And if there's, that's insane!

Do you have the reference link so that I indulge myself into?

Well, the implementation of set in the Python source might be a good example, if you're fine with lower-level C code and want to work your way through the exact optimizations.

Do you have the reference link so that I indulge myself into?

Well, the implementation of set in the Python source might be a good example, if you're fine with lower-level C code and want to work your way through the exact optimizations.

I'm totally not fine at all with C, so it will probably take a while for me to digest and dipping into the low level stuffs, but thanks for the tip.
Anyway, I'm not well versed in networking, so it's your call on how you want your library to be. But with the exploding number of networking devices due to IoT, I would prefer following the IEEE specification, and, maybe, guiding users to a more updated standard?

Verdict (when+if I have time+motivation, I will post more of my reasoning for these choices):

In version 1.* releases, equality behavior will stay the same. The docstring's claim about subclasses being equal, which was what I originally intended but which is inconsistent with the behavior I actually had in every release so far, will be treated as mistaken.

I will release version 1.2.0 with hashing. Because equality behavior will not change within 1.*, instances of different classes, even if one is a subclass of the other, will be distinct as set members and dictionary keys, regardless of hashing choice.

In version 2.0.0, equality will be changed so that any HWAddress instance, including all subclasses, can be equal to any other, if the address size and address value are equal. Of the provided classes, this only effects EUI48 and MAC behavior, because all of the others have a distinct size.

In version 2.0.0, I will hash on size and address integer, to match the changes in equality logic.

In version 1.2.0, I will hash on the class and address integer. Because ideally we maximize how often instances that won't compare equal hash differently.

The exact hash choice in both versions will be an implementation detail - not a guaranteed part of the API. So this can be changed later if there is good reason.

I'm closing this issue because I like open/closed status to mean "does this need resolution?" and my mind is made up now to my satisfaction, but further comments or arguments are always welcome, even if an issue is closed.

Re: the EUI-48 vs "MAC" issue specifically:
I created #9 for further discussion of that topic in its own right.
As far as it concerns this issue, I saw the cases like this:

If we decide on no separate MAC subclass of EUI48, then these are totally independent decisions.
If we decide that a MAC subclass instance should be equal to an EUI48 class instance of the same address (same as set member and mapping key), then that is evidence in favor of a type-independent equality and hashing.
If we see a good reason for them to be unequal for the same address (or to be distinct as set members or mapping keys), then this is evidence in favor of type-dependent equality or hashing.

Options 1 and 2 are equivalent for practical purposes with regard to having this library provide a MAC vs EUI-48 distinction out-of-the-box. (Either way if you want that distinction, you have to take a conscious subclassing/composition step to create an address class which does not compare equal and does not hash equal. In one of them you would be forced to explicitly cause inequality.)
To a large extent I share @gytqby's suggestion/ preference for guiding users towards the "EUI-48" name and the EUI48 class over the "MAC" name and MAC class. This suggests option 1.
If not option 1, then option 2 seems by far more useful than option 3 to me. More on that later.

Re:

I don't think there is a need to create additional subclass for what the library already provided. Honestly, there shouldn't be. And if there's, that's insane!

Yeah, I think in the typical case, no one needs any other addresses.
However, there is the occasional good use-case.
For example, I looked around in the projects listed by GitHub's "used by" feature on this repo, and found a real-world usage of subclassing to support custom formats.
(In that situation, the subclass is just being used for validation, but we could easily imagine a similar use-case where the constructed address class is used throughout the program to represent the address, and equality and so on is actually relied-upon.)

@gytqby I made a simplified Python sketch of how a mapping type like dict could be implemented using a hash table: https://gist.github.com/mentalisttraceur/c340b63b646c54cd56ed4cb8b9e16c53 .
You may find this more helpful as an introductory reference than the C Python source.

@gytqby I came across a nice real-world example of the same equality and hashing problem: https://bidict.readthedocs.io/en/main/learning-from-bidict.html#python-surprises

I finally wrote up rationale for "The docstring's claim about subclasses being equal, which was what I originally intended but which is inconsistent with the behavior I actually had in every release so far, will be treated as mistaken" in #24.
Now here's a short rationale for "equality will be changed so that any HWAddress instance, including all subclasses, can be equal to any other, if the address size and address value are equal":
I think per something like the subclass substitution principle, a subclass instance should compare equal unless deliberately made to not compare equal. It's not exactly violating Liskov substitutability to have subclasses compare not-equal by default (after all, even if you change the answer you're still fulfilling the interface of subclasses being comparable with == and !=), but it can definitely be very unintuitive. It is certainly the case that if subclassing
This point does depend on subclassing being supported:

is subclassing worth doing in ways that don't change equality behavior often enough? I think yes, partially covered above and partially in #18 and maybe #4 .
per Hyrum's Law, or more specifically defensive coding to mitigate the bad results of Hyrum's Law, if subclasses aren't supported then they ought to be somehow prevented or at least more difficult and inconvenient than the supported alternatives - the ramification is that not supporting something needs to be worth the preventative measures, and if it isn't then it's better to accept that it's going to happen and support it... and in Python, the costs of impeding subclassing are higher than seems worth it (partially covered in #4 I think).

I'm going to consider the design choices explained enough now, unless someone has further questions.

Actually, two more rationale pieces from my old draft notes:

Consider 0 == 0.0 == False == 0. Those all collide as set members and dictionary keys, even though they are different types of object. This isn't always the right design but it's a good example of how equality across classes can be useful. It is also a good example of how Python does things, so when thinking with Python design expectations and conventions, this feels more consistent and natural.

The language gives us these two distinct things - type queries like isinstance and comparison queries like ==. When equality considers type too specifically, it answers the same questions that the type system is already designed to answer, instead of answering some other orthogonal questions that might be useful to developers. This seems like inefficient use of the available affordances of the language.

I'm finding myself really drawn to a middle ground:

class Foo(EUI48): ... should equal (and thus hash the same) and freely cast to and from EUI48, but
class Qux(HWAddress): size = 48 absolutely should not be assumed to be the same as EUI48.

Unfortunately, there's no easy way in Python to implement this - not without either

worse ergonomics for users who need to make custom address classes (adding an explicit class attribute, having to overload __init__, etc),
traversing the inheritance hierarchy (all methods for inspecting it that I know of don't work on minimal Pythons like MicroPython, where I imagine a library like this being pretty useful),
adding a metaclass or __init_subclass__ (again doesn't work on minimal Pythons like MicroPython - so __init_subclass__ is only viable for progressive enhancement like detecting nice-to-catch-in-testing usage errors - not for stuff that's necessary to make intended functionality work at all), or
replacing inheritance from HWAddress with a decorator.

If I could have a working version of same class or one is subclass of the other compatibility I would do that (possibly while retaining the same size as an additional sanity-check constraint).
But here's a somewhat not-awful compromise that gets us most of the way there:

keep equality (and hashing, why not?) behavior the same as it is in v1 (ordering could use an enhancement, so that classes of the same size are still grouped by class name rather than being arbitrarily mixable, but that's a separate matter),
adjust copy construction to allow same class, subclass, or superclass arguments (so long as they have the same size) (this way two unrelated subclasses of addresses can't accidentally convert into each other, but intentional conversion can still happen by first casting through a known-acceptable and instantiatable superclass - so if you have a MAC subclass, you know any MAC address is acceptable, and you trust third-party subclasses to be substitutable in all relevant ways, you can do my_mac_instance = MyMAC(MAC(their_mac_instance))).

(I am also starting to take for granted that subclassing-for-formatting will not be the main way to do custom formats in the future, and also that subclasses with different formats are perhaps best thought of as not interchangeable with other arbitrary subclasses.)
I need to sleep on it, but this feels like the correct way to go now.

Oh, I forgot to reply to this by @duynhaaa

I believe that the comparison should only be possible for concrete base classes and their subclasses, but not for abstract base classes if there's one.

Yeah I 100% agree, conceptually I totally see HWAddress as an abstract base, which was part of the reason for #4 (maybe I said as much there) - it's just a big challenge to do that in Python without downsides that don't sit well with me.
(Although... the original ergonomics bar was "hopefully we can think of something that Just Works automatically because that's what's normally desirable", but now since I'm leaning towards keeping our initial equality behavior by default, and have convinced myself that it's actually the right behavior most of the time, the bar is lower.)

Sightly annoying nit: if equality is based on type, but comparison/ordering is just based on size, then I think it's not strictly-speaking a "total order", because there can be addresses such that foo <= bar and foo >= bar but not foo == bar.

The flip side is that I could tighten ordering by adding type(self) vs type(other) to the comparison, but then the edge case of subclasses with the same name would sort weirdly.

Actually it would sort fine enough, I don't know what I was thinking (though I do know that I was very mentally tired at the time I wrote that, enough that simulating the cases was getting seriously hard): if I just add the id of the type as the last value of the ordering tuple, then this will restore consistency of ordering with equality.
The only sorting quirks would be when there are addresses of exactly the same length and numerical/binary value, all different classes, and one of them has a different name than the others (which should come up approximately never (and if anyone ever does have a need for better sorting of equal-but-for-type address classes, we can also add the class name to the sorting tuple after the aligned address integer and size and before class ID, and that would eliminate most problems - everything else that I've implemented or have in mind to implement also makes this an extremely self-serviceable problem for the approximately zero users who will ever have this edge case).

I do still think that the ideal is for hardware address classes to compare and hash equal when they are subclasses of the one common concrete base class.
In the case of HWAddress, the easiest "anchor" for abstract-vs-concrete is size - as if HWAddress had an @abc.abstractproperty-decorated size, except I am disinclined to use the abc stuff, at least in part due to metaclass downsides (I can't remember if I had other reasons).
So if I went down the road of making this real/enforced in the code, I would do size = None in HWAddress and then down each branch of the inheritance tree, the most rootward class to define size = {{something that quacks like an integer}} instead of None becomes a concrete base class.
Of course I imagine the size becoming "locked" within each concrete base class - a subclass of EUI48 would be allowed to leave size unset, or to set it to some size that still passes == EUI48.size, but it would not be allowed to set it to anything else (except perhaps None, to create yet another abstract subclass, for common behavior in further concrete subclasses, but those would still be limited to having their size == EUI48.size).
But in order to do that I'd need to implement some mutating stuff in __init_subclass__, so I'm going to save that for later - another one of those "wait and see if there's a good use-case or enough demand for it".


support more controller manager params for helm charts

Signed-off-by: hantmac<EMAIL_ADDRESS>

Fixes #https://github.com/streamnative/function-mesh/issues/332
Make enable-leader-election default value as true.

Motivation
Because of https://github.com/streamnative/function-mesh/pull/329, we should support more controller manager params for helm charts.
Verifying this change

[x] Make sure that the change passes the CI checks.

Documentation
Need to update docs?

[x] no-need-doc

@freeznet Do I need to update the related docs? And if need, which doc repo?

ping @Huanli-Meng, could you please help @hantmac? thanks.

@hantmac please rebase master and check my comment, thanks.

ping @Huanli-Meng, could you please help @hantmac? thanks.

OK. By the way, do we need to add doc for this PR. I noticed that a doc-info-missing label is added

@hantmac the docs can be updated at https://github.com/streamnative/function-mesh-website
@Huanli-Meng https://github.com/streamnative/function-mesh/pull/329 added some params to the controller, and user can customize them for particular purpose.

@hantmac the docs can be updated at https://github.com/streamnative/function-mesh-website @Huanli-Meng #329 added some params to the controller, and user can customize them for particular purpose.

Copy that.


uninitialized constant ActiveSupport::XmlMini::IsolatedExecutionState

Adding require "active_support/isolated_execution_state" to the top of faraday_response_middleware.rb seems to fix it (Workaround from https://github.com/rails/rails/issues/43851).
Installation using bundle, on Ruby 3.0+Linux.
ruby/3.0.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/xml_mini.rb:184:in `current_thread_backend': uninitialized constant ActiveSupport::XmlMini::IsolatedExecutionState (NameError)
	from ruby/3.0.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/xml_mini.rb:103:in `backend='
	from ruby/3.0.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/xml_mini.rb:201:in `<module:ActiveSupport>'
	from ruby/3.0.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/xml_mini.rb:11:in `<top (required)>'
	from ruby/3.0.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/core_ext/array/conversions.rb:3:in `require'
	from ruby/3.0.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/core_ext/array/conversions.rb:3:in `<top (required)>'
	from ruby/3.0.0/gems/weneedfeed-0.9.2/lib/weneedfeed/faraday_response_middleware.rb:3:in `require'
	from ruby/3.0.0/gems/weneedfeed-0.9.2/lib/weneedfeed/faraday_response_middleware.rb:3:in `<top (required)>'
	from ruby/3.0.0/gems/weneedfeed-0.9.2/lib/weneedfeed/scraping.rb:12:in `require'
	from ruby/3.0.0/gems/weneedfeed-0.9.2/lib/weneedfeed/scraping.rb:12:in `block in faraday_connection'
	from ruby/3.0.0/gems/faraday-1.10.0/lib/faraday/connection.rb:91:in `initialize'
	from ruby/3.0.0/gems/faraday-1.10.0/lib/faraday.rb:120:in `new'
	from ruby/3.0.0/gems/faraday-1.10.0/lib/faraday.rb:120:in `new'
	from ruby/3.0.0/gems/weneedfeed-0.9.2/lib/weneedfeed/scraping.rb:11:in `faraday_connection'
	from ruby/3.0.0/gems/weneedfeed-0.9.2/lib/weneedfeed/scraping.rb:77:in `response'
	from ruby/3.0.0/gems/weneedfeed-0.9.2/lib/weneedfeed/scraping.rb:68:in `parsed_body'
	from ruby/3.0.0/gems/weneedfeed-0.9.2/lib/weneedfeed/scraping.rb:52:in `call'
	from ruby/3.0.0/gems/weneedfeed-0.9.2/lib/weneedfeed/controllers/show_feed.rb:24:in `call'
	from ruby/3.0.0/gems/hibana-0.2.0/lib/hibana/controller.rb:13:in `call'
	from ruby/3.0.0/gems/hanami-router-2.0.0.alpha6/lib/hanami/router.rb:105:in `call'
	from ruby/3.0.0/gems/hibana-0.2.0/lib/hibana/application.rb:42:in `call'
	from ruby/3.0.0/gems/weneedfeed-0.9.2/lib/weneedfeed/application.rb:21:in `call'
	from ruby/3.0.0/gems/rack-capture-0.4.0/lib/rack/capture.rb:56:in `get_response'
	from ruby/3.0.0/gems/rack-capture-0.4.0/lib/rack/capture.rb:32:in `call'
	from ruby/3.0.0/gems/rack-capture-0.4.0/lib/rack/capture.rb:11:in `call'
	from ruby/3.0.0/gems/weneedfeed-0.9.2/lib/weneedfeed/capture.rb:34:in `block in call'
	from ruby/3.0.0/gems/weneedfeed-0.9.2/lib/weneedfeed/capture.rb:33:in `each'
	from ruby/3.0.0/gems/weneedfeed-0.9.2/lib/weneedfeed/capture.rb:33:in `call'
	from ruby/3.0.0/gems/weneedfeed-0.9.2/lib/weneedfeed/capture.rb:18:in `call'
	from ruby/3.0.0/gems/weneedfeed-0.9.2/lib/weneedfeed/command.rb:39:in `build'
	from ruby/3.0.0/gems/thor-1.2.1/lib/thor/command.rb:27:in `run'
	from ruby/3.0.0/gems/thor-1.2.1/lib/thor/invocation.rb:127:in `invoke_command'
	from ruby/3.0.0/gems/thor-1.2.1/lib/thor.rb:392:in `dispatch'
	from ruby/3.0.0/gems/thor-1.2.1/lib/thor/base.rb:485:in `start'
	from ruby/3.0.0/gems/weneedfeed-0.9.2/exe/weneedfeed:6:in `<top (required)>'
	from ruby/3.0.0/bin/weneedfeed:25:in `load'
	from ruby/3.0.0/bin/weneedfeed:25:in `<top (required)>'
	from /usr/lib/ruby/gems/3.0.0/gems/bundler-2.3.10/lib/bundler/cli/exec.rb:58:in `load'
	from /usr/lib/ruby/gems/3.0.0/gems/bundler-2.3.10/lib/bundler/cli/exec.rb:58:in `kernel_load'
	from /usr/lib/ruby/gems/3.0.0/gems/bundler-2.3.10/lib/bundler/cli/exec.rb:23:in `run'
	from /usr/lib/ruby/gems/3.0.0/gems/bundler-2.3.10/lib/bundler/cli.rb:483:in `exec'
	from /usr/lib/ruby/gems/3.0.0/gems/bundler-2.3.10/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
	from /usr/lib/ruby/gems/3.0.0/gems/bundler-2.3.10/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
	from /usr/lib/ruby/gems/3.0.0/gems/bundler-2.3.10/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
	from /usr/lib/ruby/gems/3.0.0/gems/bundler-2.3.10/lib/bundler/cli.rb:31:in `dispatch'
	from /usr/lib/ruby/gems/3.0.0/gems/bundler-2.3.10/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
	from /usr/lib/ruby/gems/3.0.0/gems/bundler-2.3.10/lib/bundler/cli.rb:25:in `start'
	from /usr/lib/ruby/gems/3.0.0/gems/bundler-2.3.10/exe/bundle:48:in `block in <top (required)>'
	from /usr/lib/ruby/gems/3.0.0/gems/bundler-2.3.10/lib/bundler/friendly_errors.rb:103:in `with_friendly_errors'
	from /usr/lib/ruby/gems/3.0.0/gems/bundler-2.3.10/exe/bundle:36:in `<top (required)>'
	from /usr/sbin/bundle:25:in `load'
	from /usr/sbin/bundle:25:in `<main>'

Thanks for reporting 👍
I tried it myself and reproduced it:
$ weneedfeed build --base-url=http://example.com
/home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/activesupport-7.0.1/lib/active_support/xml_mini.rb:184:in `current_thread_backend': uninitialized constant ActiveSupport::XmlMini::IsolatedExecutionState (NameError)
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/activesupport-7.0.1/lib/active_support/xml_mini.rb:103:in `backend='
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/activesupport-7.0.1/lib/active_support/xml_mini.rb:201:in `<module:ActiveSupport>'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/activesupport-7.0.1/lib/active_support/xml_mini.rb:11:in `<top (required)>'
        from <internal:/home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
        from <internal:/home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/activesupport-7.0.1/lib/active_support/core_ext/array/conversions.rb:3:in `<top (required)>'
        from <internal:/home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
        from <internal:/home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/weneedfeed-0.9.2/lib/weneedfeed/faraday_response_middleware.rb:3:in `<top (required)>'
        from <internal:/home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
        from <internal:/home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/weneedfeed-0.9.2/lib/weneedfeed/scraping.rb:12:in `block in faraday_connection'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/faraday-1.10.0/lib/faraday/connection.rb:91:in `initialize'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/faraday-1.10.0/lib/faraday.rb:120:in `new'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/faraday-1.10.0/lib/faraday.rb:120:in `new'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/weneedfeed-0.9.2/lib/weneedfeed/scraping.rb:11:in `faraday_connection'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/weneedfeed-0.9.2/lib/weneedfeed/scraping.rb:77:in `response'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/weneedfeed-0.9.2/lib/weneedfeed/scraping.rb:68:in `parsed_body'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/weneedfeed-0.9.2/lib/weneedfeed/scraping.rb:52:in `call'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/weneedfeed-0.9.2/lib/weneedfeed/controllers/show_feed.rb:24:in `call'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/hibana-0.2.0/lib/hibana/controller.rb:13:in `call'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/hanami-router-2.0.0.alpha6/lib/hanami/router.rb:105:in `call'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/hibana-0.2.0/lib/hibana/application.rb:42:in `call'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/weneedfeed-0.9.2/lib/weneedfeed/application.rb:21:in `call'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/rack-capture-0.4.0/lib/rack/capture.rb:56:in `get_response'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/rack-capture-0.4.0/lib/rack/capture.rb:32:in `call'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/rack-capture-0.4.0/lib/rack/capture.rb:11:in `call'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/weneedfeed-0.9.2/lib/weneedfeed/capture.rb:34:in `block in call'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/weneedfeed-0.9.2/lib/weneedfeed/capture.rb:33:in `each'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/weneedfeed-0.9.2/lib/weneedfeed/capture.rb:33:in `call'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/weneedfeed-0.9.2/lib/weneedfeed/capture.rb:18:in `call'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/weneedfeed-0.9.2/lib/weneedfeed/command.rb:39:in `build'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/thor-1.2.1/lib/thor/command.rb:27:in `run'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/thor-1.2.1/lib/thor/invocation.rb:127:in `invoke_command'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/thor-1.2.1/lib/thor.rb:392:in `dispatch'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/thor-1.2.1/lib/thor/base.rb:485:in `start'
        from /home/r7kamura/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/weneedfeed-0.9.2/exe/weneedfeed:6:in `<top (required)>'
        from /home/r7kamura/.rbenv/versions/3.0.3/bin/weneedfeed:25:in `load'
        from /home/r7kamura/.rbenv/versions/3.0.3/bin/weneedfeed:25:in `<main>'

I tried to run CI on Ruby 3.0 at this PR:

https://github.com/r7kamura/weneedfeed/pull/21

but unfortunately this problem was in untested area, so I could not detect it by CI...

Reproduced at Ruby 2.7.2, so this is not related to Ruby version, but probably Rails version (due to Rails 7?)
$ weneedfeed build --base-url=http://example.com
Traceback (most recent call last):
        39: from /home/r7kamura/.rbenv/versions/2.7.2/bin/weneedfeed:23:in `<main>'
        38: from /home/r7kamura/.rbenv/versions/2.7.2/bin/weneedfeed:23:in `load'
        37: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/weneedfeed-0.9.2/exe/weneedfeed:6:in `<top (required)>'
        36: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/thor-1.2.1/lib/thor/base.rb:485:in `start'
        35: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/thor-1.2.1/lib/thor.rb:392:in `dispatch'
        34: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/thor-1.2.1/lib/thor/invocation.rb:127:in `invoke_command'
        33: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/thor-1.2.1/lib/thor/command.rb:27:in `run'
        32: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/weneedfeed-0.9.2/lib/weneedfeed/command.rb:39:in `build'
        31: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/weneedfeed-0.9.2/lib/weneedfeed/capture.rb:18:in `call'
        30: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/weneedfeed-0.9.2/lib/weneedfeed/capture.rb:33:in `call'
        29: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/weneedfeed-0.9.2/lib/weneedfeed/capture.rb:33:in `each'
        28: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/weneedfeed-0.9.2/lib/weneedfeed/capture.rb:34:in `block in call'
        27: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/rack-capture-0.4.0/lib/rack/capture.rb:11:in `call'
        26: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/rack-capture-0.4.0/lib/rack/capture.rb:32:in `call'
        25: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/rack-capture-0.4.0/lib/rack/capture.rb:56:in `get_response'
        24: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/weneedfeed-0.9.2/lib/weneedfeed/application.rb:21:in `call'
        23: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/hibana-0.2.0/lib/hibana/application.rb:42:in `call'
        22: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/hanami-router-2.0.0.alpha3/lib/hanami/router.rb:92:in `call'
        21: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/hibana-0.2.0/lib/hibana/controller.rb:13:in `call'
        20: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/weneedfeed-0.9.2/lib/weneedfeed/controllers/show_feed.rb:24:in `call'
        19: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/weneedfeed-0.9.2/lib/weneedfeed/scraping.rb:52:in `call'
        18: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/weneedfeed-0.9.2/lib/weneedfeed/scraping.rb:68:in `parsed_body'
        17: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/weneedfeed-0.9.2/lib/weneedfeed/scraping.rb:77:in `response'
        16: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/weneedfeed-0.9.2/lib/weneedfeed/scraping.rb:11:in `faraday_connection'
        15: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/faraday-1.9.3/lib/faraday.rb:118:in `new'
        14: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/faraday-1.9.3/lib/faraday.rb:118:in `new'
        13: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/faraday-1.9.3/lib/faraday/connection.rb:91:in `initialize'
        12: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/weneedfeed-0.9.2/lib/weneedfeed/scraping.rb:12:in `block in faraday_connection'
        11: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:72:in `require'
        10: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:72:in `require'
         9: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/weneedfeed-0.9.2/lib/weneedfeed/faraday_response_middleware.rb:3:in `<top (required)>'
         8: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:72:in `require'
         7: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:72:in `require'
         6: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/core_ext/array/conversions.rb:3:in `<top (required)>'
         5: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:72:in `require'
         4: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:72:in `require'
         3: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/xml_mini.rb:11:in `<top (required)>'
         2: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/xml_mini.rb:201:in `<module:ActiveSupport>'
         1: from /home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/xml_mini.rb:103:in `backend='
/home/r7kamura/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/xml_mini.rb:184:in `current_thread_backend': uninitialized constant ActiveSupport::XmlMini::IsolatedExecutionState (NameError)

Fixed at https://github.com/r7kamura/weneedfeed/pull/22 and released v0.10.0 🎉


Localization of the program.

Hello.
If you plan to localize the program into other languages, please make *.ts files for translation.

Hello! Yes, I should do that. At first I tried to be disciplined and pass all the UI text through tr(), but I probably dropped that habit at some point. I'll look into it.


Hide red Area on marker cluster zoom

Hello,
I'm submitting a ...  (check one with "x")
[X] question
[ ] any problem or bug report
[ ] feature request
The plugin version:  (check one with "x")
[ ] 2.0-beta3 (github)
[X] 2.0 (npm)
I am looking for a solution to hide the red area which shows the focus area when clicking on a cluster marker, shown in your demo (https://github.com/mapsplugin/cordova-plugin-googlemaps-doc/blob/master/v2.0.0/class/MarkerCluster/README.md), and by the love of all that is good and holy i can not figure out where that area marking is coming from and how i can hide it.
Optionally question, can i change the area so it is about 20px bigger than currently calculated? (it sometimes cuts some of my custom marker icons in half (on the edge of the map)
Can you please help me out?
Thanks in advance.
Tim

As you can see in the documentation:
And other optional parameters are:
boundsDraw: draw bounds when you tap on a clustered marker (default: true)

so to answer your question, you need to change boundsDraw parameter to false.
Regarding your second question, I am not sure exactly what you are referring to. Can you provide an example?

Thank you, @mihaicolceriu
@TimothyFehr
For the second question, there is no option at this time.

How could i miss that.
Sad to hear that my second question is not doable but it was kind of a nice to have anyway
Thanks a lot @mihaicolceriu & @wf9a5m75


load/link assets to handles defined in scene files.

What problem does this solve or what need does it fill?
When a scene is loaded from a file, any asset handle components attached to its entities are spawned as weak references. There is no mechanism to trigger asset loads from scene files or otherwise link handles with loaded assets. This inability to define entire scenes complete with meshes, materials, etc. is a significant roadblock to developing scene editors and other such external tooling.
What solution would you like?
I see two potential ways to do this.

The "proxy" approach: Define a new "proxy" handle type which contains an asset path and loads the corresponding asset when the DynamicScene is spawned, attaching the resulting Handle component in its place. This would probably necessitate a special case in DynamicScene::write_to_world that checks if each "component" (which now would not necessarily be a component) has a special "proxy component" data type registration thing.
The "link" approach: Somehow make FromType::<Handle<T>> for ReflectComponent a special case so that it provides apply_component and add_component methods that attempt to obtain strong references from the asset server instead of just deserializing Handle as a weak reference. The scene file format would have to be extended to provide a way to declare asset dependencies, since the handles don't provide a full path to load assets with.

What alternative(s) have you considered?

The GLTF loader already produces strong Handles for its meshes, materials, etc., so there are workarounds involving injecting components into the entities that it loads in. I think this is roughly what @nicopap 's bevy scene hook does. This approach could potentially be aided by defining some sort of structured metadata that we look for in the GLTF file's various "extras" fields (see #2153).
@sdfgeoff 's blender bevy toolkit does something sort of like (1) the "proxy" approach above, except the "proxies" are actually components that get loaded as normal, and are queried and resolved/replaced with a handles by special systems. The benefit of this approach is that it doesn't require modifying bevy's internals at all, but since the proxy "resolution" happens after the dynamic scene is spawned, it requires a system to be loaded at runtime for each type of asset.

Additional context

I have a working implementation for (1). It's a bit rough, but I could easily clean it up if we are interested in going in that direction. I made a discussion post with more details a few days ago: #4334.
There has been some discussion surrounding reworking how scene files and assets work. See #3972 (assets), and #92, #4153 (scenes). It will be worth considering how this feature relates to future work in these areas.

It's worth mentioning this discussion: https://github.com/bevyengine/bevy/discussions/3940 which means it is possible for a single asset to load/reference/link to other assets. However, as you say, the current scene format doesn't seem to support it in any way.


OAuth2 authentication method unavailable

I am unable to schedule the refresh of data as the gateway is only listing the options "Anonymous", "Basic", and "Windows" as the available authentication types. Is there anything that needs to be modified on the gateway, in the report, or in the queries, so that OAuth2 is an option?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: daf84287-d3e6-38f3-e67d-41b7aaf350ce
Version Independent ID: b03d56d0-1fba-bea4-6f02-97fbc5832651
Content: Import Azure Log Analytics data into Power BI
Content Source: articles/azure-monitor/platform/powerbi.md
Service: log-analytics
GitHub Login: @bwren
Microsoft Alias: bwren

@edlang Thanks for the comment. We are actively investigating and will get back to you shortly with an update.

@edlang From the information provided , i could infer that you are using on premise gateway for scheduling the refresh. As it's more related to Power Bi, i would recommend you to raise the issue using either of these methods

https://community.powerbi.com/
If you have Pro license , you can raise support ticket
https://github.com/MicrosoftDocs/powerbi-docs/issues

We will now close this issue for now. If there are further questions regarding this matter, please reply and we will gladly continue the discussion.


Avoid running removeDiffSigns on every table

Fixes #765
I manually ran the tests described in https://github.com/sindresorhus/refined-github/pull/613
Bug example:
https://github.com/sindresorhus/refined-github/blob/bacb4bcc7aaa7a0052b0b623d1b2fa794b03e339/.gitignore#L1

Screenshot

Edit: life would be easier if we had ode_modules instead of node_modules

Great work. Let's hope this is the last of the diff sign churn :)


Did xgb.save and xgb.load change?

We have been using a fork of the xgboost package that we recently caught up to the latest master. However, older models whose binary was saved using xgb.save is no longer being correctly deserialized using xgb.load; instead, we see:
Error in xgb.Booster(modelfile = modelfile) :
  BoostLearner: wrong model format

Is there any hope to salvage these binaries, or should we xgb.load from an older version of the package to load them? Did the serialization format change in a systematic way?

I do not think this was due to format change, but this could due to the new support for using R's save function. @hetong007 should be able to look into this and what was going on

Hi, @robertzk can you please provide more information? For example what is the process and where did this error appear. It would be great if you can provide a minimum reproducible example.

Any updates on the issue? If we can have a reproducible example and hashtag of a version where if we save the model, the change breaks. @hetong007 or I can take a look at it. There is no intention break of backward compatibility since 3.0

This appears to be my fault of tiny change of model structure that cause backward incompatibility. I have pushed a hack to fix the problem, so the old model can still be loaded


Format the Function statement

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

VBA/Language-Reference-VBA/articles/function-statement.md
:white_check_mark:Succeeded

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

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

VBA/Language-Reference-VBA/articles/function-statement.md
:white_check_mark:Succeeded

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

All content in this repository has been migrated to a new repository (https://github.com/MicrosoftDocs/VBA-Docs). The changes in this PR have been applied in the new repository, so this PR is being closed. The changes will be published to the live docs soon. Thank you for your contribution!


Update main/master README

This is an issue as the project now has grown beyond a quick README. It does need a structure and some good write up.

#46 is good enough for now


improve docs for simple-icons usage

Messages

:book:
:sparkles: Thanks for your contribution to Shields, @chris48s!

:book:

Thanks for contributing to our documentation. We :heart: our documentarians!

  Generated by :no_entry_sign: dangerJS against 70b02986dfcb2c0cde74c5c3e04fcc93c4f24160

Could we pick one of these to officially support, maybe the dasherized version, and leave the others as undocumented / not guaranteed to work?

If we have to pick only one, I'd be inclined to pick only the urlencoded format: The way the icons are indexed in the actual simple-icons library is with the spaces, so that's more likely to be intuitive to someone who already knows the library. If you copy names from the simple icons website, its going to have spaces.
A dash is a bit more readable than %20 in plain text, but its something we've invented, if you see what I mean.

Yea, all makes sense. Agree that the one we invented is a bit nicer.
I guess a couple ideas before we settle this:

Did we invent the dasherized slug, or is it already buried within what simpleicons ships? If it is part of what they ship, could we change their website so it shows the slug. Maybe it could even use a copyable button. I feel like other applications using simpleicons would benefit from using and surfacing the standard slug.
Would having a searchable picker with all the icons on our badge modal solve the problem? Might be even friendlier than sending people to the simple-icons site.

The version with dashes is nothing to do with the simple-icons library - its added here: https://github.com/badges/shields/blob/6e36e520847b3ca3de3dc299427dab08e17f0f51/lib/load-simple-icons.js#L8
In general, it would be a nice enhancement if "named logo" in the modal was a searchable drop-down. That's a good stretch goal. Adding a sentence to clarify the docs is a useful interim improvement.

Are you open to guiding people to the dasherized version (replace spaces with dashes), with a callout that the picker in the UI is a stretch goal?


Update azure-stack-manage-permissions.md #28968

Duplicated sections Resource hierarchy and inheritance and Assigning roles are removed.
Created an issue here #28968

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: el-sai sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

@el-sai : Thanks for your contribution! The author, @PatAltimore, has been notified to review your proposed change.

@el-sai  The change looks good.  Thanks for submitting the PR.
#sign-off
Pat


Performance: Slow completion with vue-language-server

Saw on twitter that there was a report of slow completion with vue-language-server. Likely would impact other language servers too, if that's the case!

Ah turns out this wasn't Oni - still need to test vue-language-server / document in #1119 . Will track remaining issues there for now.


Fix Link styles in About us Page

Fix spacing issue for links in about us page.
Current:
https://main--fonterra-fernleaf--hlxsites.hlx.page/en/about-us

Expected:
https://www.fernleaf.com.my/en/about-us.html

Will be resolved as part of the PR #216.


Simple test to do clang/asan builds on gz-utils

Inspired by robotlocomotion/drake's approach

I actually think there is a better way to handle this.  Closing.


[Flink 29627][streaming] Fix duplicate key exception during recovery more than 1 committable.

What is the purpose of the change
Unchanged backport of https://github.com/apache/flink/pull/21101
Fixing FLINK-29627 where recovery more than one Committable causesed IllegalStateException and prevents cluster to start.
Implemented fix is based on merging committables from same subtaskId during recovery for Sink V2 architecture.
Brief change log

Enhance CheckpointSimpleVersionedSerializer::deserialize by calling SubtaskCommittableManager::merge for committables for same subtaskId.

Verifying this change

Add new test Committablecollectorserializertest::testCommittablesForSameSubtaskIdV2SerDe to verify deserialization of multiple committables for the same subtaskId.
Enhanced CommitterOperatorTest::testStateRestore to include committables for same subtaskId.

Does this pull request potentially affect one of the following parts:

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

Documentation

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

@flinkbot run azure


Rebuild for Python 3.11

Bot got stuck (at least) due to the hard pin on setproctitle, see https://github.com/ray-project/ray/issues/37727

The parallel test for python3.10 finds pyarrow: 12.0.1-py38h39356d1_6_cpu conda-forge
I wonder why the resolver is looking for a GPU package

Yeah, I also don't yet know where this goes off the rails. I guess we can force the cpu version here and try to get closer to the underlying failure...

Ah, it seems that tensorboardX forces a very new protobuf, which is incompatible with our grpcio pin on ray-core. I guess the other python versions are able to pull in an older tensorboardX.
We also really need to unvendor grpc & protobuf (#90), but it's just such a pain to do that with bazel 😑

I am not sure the grpcio problem resides entirely with bazel. See #98, where using this feedstock and pip install grpcio==1.51.1 succeeds but conda install <equivalent of grpcio 1.51.1> fails.

I don't know whether this PR to remove the python grpcio dependency in favor of statically-linking to the grpc c++ library will help or hurt?

That's sounds like it would be great in principle (we'd have to adapt it to statically link to our libgrpc, but that's not a big operation)!

Lack of Python 3.11 support is starting to become a problem for us. Any updates on this?

Lack of Python 3.11 support is starting to become a problem for us. Any updates on this?

The same for us.

hope https://github.com/ray-project/ray/pull/40289 will help

Closing, completed in #117


Failed to load optimized model

Just pointing out that this issue has been fixed, and wondering if anything needs to be updated within this plugin.
https://code.google.com/p/gmaps-api-issues/issues/detail?id=8459

Update is out! Grab 1.3.4