--target-dir results in failed to create directory /target/release

Cross is running docker with --user, and when you use --target-dir it adds a volume mount from the directory to /target, like so:
docker run <...> -v mytargetdir:/target:Z <...>

The /target directory will be owned by root, and cross will fail to create anything there.

This shouldn't happen due to https://github.com/rust-embedded/cross/blob/a1ca96d787c7bbe1c2f4971de34de24a6974572a/src/docker.rs#L77-L79 which has been a thing since the first release.
What version of cross are you using?

I'm on:
❯ cross --version
cross 0.2.1
cargo 1.54.0 (5ae8d74b3 2021-06-22)

I was able to reproduce the problem with --verbose. This is what I get when I run cross build --target x86_64-unknown-linux-musl --target-dir zcross --verbose:
+ "rustc" "--print" "sysroot"
+ "rustup" "toolchain" "list"
+ "rustup" "toolchain" "add" "nightly-x86_64-unknown-linux-gnu"
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'

  nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.56.0-nightly (5a19ffe1c 2021-08-13)

info: checking for self-updates
+ "rustup" "target" "list" "--toolchain" "nightly-x86_64-unknown-linux-gnu"
+ "rustup" "component" "list" "--toolchain" "nightly-x86_64-unknown-linux-gnu"
+ "/usr/bin/docker" "run" "--userns" "host" "-e" "PKG_CONFIG_ALLOW_CROSS=1" "--rm" "--user" "1000:1000" "-e" "XARGO_HOME=/xargo" "-e" "CARGO_HOME=/cargo" "-e" "CARGO_TARGET_DIR=/target" "-e" "USER=user" "-e" "CROSS_RUNNER=" "-v" "/home/user/.xargo:/xargo:Z" "-v" "/home/user/.cargo:/cargo:Z" "-v" "/cargo/bin" "-v" "/home/user/p/examples/minirust:/project:Z" "-v" "/home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu:/rust:Z,ro" "-v" "zcross:/target:Z" "-w" "/project" "-i" "-t" "rustembedded/cross:x86_64-unknown-linux-musl-0.2.1" "sh" "-c" "PATH=$PATH:/rust/bin cargo build --target x86_64-unknown-linux-musl --target-dir /target --verbose"
error: failed to create directory `/target/debug`

Caused by:
  Permission denied (os error 13)

From there, I ran the docker command, but swapped cargo build with bash:
$ "/usr/bin/docker" "run" "--userns" "host" "-e" "PKG_CONFIG_ALLOW_CROSS=1" "--rm" "--user" "1000:1000" "-e" "XARGO_HOME=/xargo" "-e" "CARGO_HOME=/cargo" "-e" "CARGO_TARGET_DIR=/target" "-e" "USER=user" "-e" "CROSS_RUNNER=" "-v" "/home/user/.xargo:/xargo:Z" "-v" "/home/user/.cargo:/cargo:Z" "-v" "/cargo/bin" "-v" "/home/user/p/examples/minirust:/project:Z" "-v" "/home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu:/rust:Z,ro" "-v" "zcross:/target:Z" "-w" "/project" "-i" "-t" "rustembedded/cross:x86_64-unknown-linux-musl-0.2.1" bash
groups: cannot find name for group ID 1000
I have no name!@e5848d8f1be0:/project$ ls -la /target/
total 8
drwxr-xr-x 2 root root 4096 Aug 14 01:04 .
drwxr-xr-x 1 root root 4096 Aug 14 01:07 ..

As you can see, /target is owned by root.
The zcross directory (the target dir) was created at the cwd as expected, and is owned by my user.
What seems to be happening is that the command is trying to use a relative value for the volume host directory, but that is not allowed, you need to use an absolute path, otherwise the name is interpreted as a name, and a volume is created. I checked and there is now a volume named zcross in docker. See from Docker docs:

The host-src can either be an absolute path or a name value. If you supply an absolute path for the host-src, Docker bind-mounts to the path you specify. If you supply a name, Docker creates a named volume by that name.

And as I wrote this I found a workaround, if I specify the full path it works:
cross build --target x86_64-unknown-linux-musl --target-dir `pwd`/zcross

I believe this should be handled automatically by cross, to mimic the behavior from cargo build.


consider removing the font-feature-settings CSS?

Hiya, great theme!
I have been using this theme with Hyper 1.4.7 and the Fira Mono font family, and everything works wonderfully!
I just tried out Hyper 2.x canary to see what it was like, and I noticed that font ligatures were enabled which wasn't especially desirable for me
I tried adding a custom termCSS to turn it off, but I think the !important in this theme made it very difficult to disable
I'd suggest that this setting is very likely to be paired with the specific font that a user has set, so it might make more sense to drop it from the theme and allow the user to specify this together with their font? What do you think?

@jokeyrhyme Yup, it makes sense. Thanks for bringing this up. I'll update the theme soon.

@ghosh awesome! Would you like me to raise a PR?

Sure, that would be great. Thank you.

Thank you. I published the changes.


No package.json on Windows

Not a super big issue but when following the installation steps of the readme, no package.json gets generated.
The easy fix was to copy and paste the one from the example_project/assets and correcting the paths.
{
"devDependencies": {
"@types/lodash": "^4.14.192",
"dynamic-marquee": "^2.6.2",
"esbuild": "^0.16.17",
"esbuild-plugin-import-glob": "^0.1.1",
"esbuild-svelte": "^0.7.4",
"lodash": "^4.17.21",
"stylus": "^0.55.0",
"svelte": "^4.1.2",
"svelte-preprocess": "^5.0.4",
"typescript": "^4.9.5"
},
"dependencies": {
"live_json": "file:../deps/live_json",
"live_svelte": "file:../deps/live_svelte",
"phoenix": "file:../deps/phoenix",
"phoenix_html": "file:../deps/phoenix_html",
"phoenix_live_view": "file:../deps/phoenix_live_view",
"svelvet": "^8.1.0"
}
}
Thought that some other "'weirdos" working on Windows like me might find it useful.

Thanks for reporting, I haven't tested on Windows so this is useful.
If anyone on Windows experiences the same issue please leave a comment, would be good to know this is a general issue that's happening on Windows.

package.json was missing for me on Windows.

We might need to add a minimal package.json if one doesn't exist. I think the packages might be getting installed globally when npm doesn't find a package.json. npm init --yes adds a little too much, so maybe just copying in our own would work?

I had similar issue with the package.json not showing up on Mac. I made PR #96  that I think will fix the issue. Not sure if it's the same issue for Windows.

Another Windows machine not having package.json show up.

Should be solved in the latest version


Cannot get oath token

Describe Your Problem:
The plugin is not able to get the oath token and is therefore not seeing my doors.  I had to recreate my homebridge docker container, and since rebuilding, it has not been working
Logs:

[11/25/2024, 10:40:36 AM] [Garage Door] [API] An error occurred getting operator oauth token; timeout of 5000ms exceeded
[11/25/2024, 10:40:36 AM] [Garage Door] [API] An error occurred getting devices from account; timeout of 5000ms exceeded
[11/25/2024, 10:40:36 AM] [Garage Door] Failed to load doors from account; retrying in 5 minutes
[11/25/2024, 10:45:41 AM] [Garage Door] Initializing GenieAladdinConnect platform...
[11/25/2024, 10:45:41 AM] Loading 2 accessories...
[11/25/2024, 10:46:01 AM] [Garage Door] [API] An error occurred getting operator oauth token; timeout of 5000ms exceeded
[11/25/2024, 10:46:01 AM] [Garage Door] [API] An error occurred getting devices from account; timeout of 5000ms exceeded
[11/25/2024, 10:46:01 AM] [Garage Door] Failed to load doors from account; retrying in 5 minutes

Plugin Config:
{
    "bridge": {
        "name": "Homebridge F758",
        "username": "0E:24:1A:97:9E:EA",
        "port": 51826,
        "pin": "418-99-968",
        "bind": [
            "bond0"
        ],
        "advertiser": "avahi"
    },
    "accessories": [
        {
            "name": "Kelly's Garage Switch",
            "stateful": false,
            "dimmer": false,
            "reverse": false,
            "time": 1000,
            "random": false,
            "resettable": false,
            "brightness": 0,
            "disableLogging": false,
            "accessory": "DummySwitch"
        },
        {
            "accessory": "DummySwitch",
            "name": "Front Door dummy Switch"
        }
    ],
    "platforms": [
        {
            "name": "Config",
            "port": 8581,
            "auth": "none",
            "theme": "dark-mode-purple",
            "tempUnits": "f",
            "lang": "auto",
            "platform": "config"
        },
        {
            "name": "Govee",
            "username": "",
            "password": "",
            "bleDisable": false,
            "lanDisable": false,
            "lightDevices": [
                {
                    "label": "Livingroom backlight",
                    "deviceId": "23:55:C4:36:39:34:46:53",
                    "showAs": "default"
                },
                {
                    "label": "Basement backlight",
                    "deviceId": "C6:7C:D2:36:36:37:30:64"
                }
            ],
            "platform": "Govee"
        },
        {
            "name": "TplinkSmarthome",
            "addCustomCharacteristics": true,
            "discoveryPort": 32555,
            "broadcast": "<IP_ADDRESS>",
            "deviceTypes": [
                "plug",
                "bulb"
            ],
            "devicesUseDiscoveryPort": false,
            "platform": "TplinkSmarthome"
        },
        {
            "user": "",
            "password": "",
            "registeredApp": "MideaAir",
            "interval": 30,
            "devices": [
                {
                    "deviceId": "Office ac",
                    "supportedSwingMode": "Vertical",
                    "temperatureSteps": 1,
                    "minTemp": 17,
                    "maxTemp": 30,
                    "fanOnlyMode": true,
                    "OutdoorTemperature": true,
                    "useFahrenheit": true,
                    "audibleFeedback": true
                }
            ],
            "platform": "midea-air"
        },
        {
            "name": "Tapo Smart Platform",
            "username": "",
            "password": "",
            "devices": [
                {
                    "name": "arcade plug",
                    "host": "<IP_ADDRESS>",
                    "type": "Plug",
                    "updateInterval": 30,
                    "timeout": 2
                },
                {
                    "name": "Printer Plug",
                    "host": "<IP_ADDRESS>",
                    "type": "Plug",
                    "updateInterval": 30,
                    "timeout": 2
                }
            ],
            "platform": "TapoP100"
        },
        {
            "name": "Garage Door",
            "username": "",
            "password": "",
            "batteryLowLevel": 15,
            "doorStatusStationaryCacheTtl": 15,
            "doorStatusTransitioningCacheTtl": 5,
            "doorStatusPollInterval": 15000,
            "logApiResponses": true,
            "showShared": true,
            "platform": "GenieAladdinConnect"
        }
    ],
    "disabledPlugins": []
}

Screenshots:

Environment:

Plugin Version:v4.1.0
Homebridge Version: 1.8.5
Node.js Version:  v20.18.0
NPM Version: 10.8.2
Operating System: docker

I'm able to curl google from the container.

The container is able to see all devices on my network, and also log into give and other platforms.  It seems to only be timing out with Aladdin.

Yes this is also using the main account, I did try to use either account with the "shared doors" option, but it doesn't seem able to get the auth token on either.  But both work on my iPhone app.


Problems with rapidyaml requirement

There are two problems with rapidyaml:

While installing this package with pip install git+https://github.com/symbiflow/python-fpga-interchange.git, there is an error that rapidyaml can't be found which is true since it's in the setup.py in install_requires but it's not a PIP package.
I'd simply solve it by adding git+https://github.com/litghost/rapidyaml.git@fixup_python_packaging#egg=rapidyaml&subdirectory=api/python before this package in https://github.com/SymbiFlow/fpga-tool-perf/blob/0888f31ca8855141a7648189167cacc2a6749755/conf/nextpnr/requirements.txt#L4 which should solve the problem of the unavailable rapidyaml package, BUT there's an error during its installation. It requires swig to be installed in the environment and adding swig to the Conda's environment.yml doesn't work. I guess it'd be needed to add it in the host OS or which doesn't seem to be the optimal solution.

For now I'll propose to simply lock revision in fpga-tool-perf's nextpnr/requirements.txt and symbiflow/requirements.txt to the last revision prior to using rapidyaml, i.e. https://github.com/SymbiFlow/python-fpga-interchange/commit/e632a5e3e51eea653ff1c73919b2553e5626bb36
BTW. @litghost I'd add the second point as an issue in https://github.com/litghost/rapidyaml/ but there's no Issues tab enabled.

2. It requires swig to be installed in the environment and adding swig to the Conda's environment.yml doesn't work. I guess it'd be needed to add it in the host OS or which doesn't seem to be the optimal solution.

Adding swig to conda is what was done here, and it appears to have worked:  https://github.com/SymbiFlow/symbiflow-arch-defs/pull/2012

Oh you're right. I've just checked locally that it works. I must've been trying to add swig before I found out that also rapidyaml should be added separately to requirements.txt.
Thanks!


add platform_price and service_price to application

We need to have 2 more columns to application tables:
application_price
service price
both string since we could have just the price description that coudl be an amount per month etc.
The user will be able to choose it checking a box and nothing else.
All java and DBs to be chenged.
Linked to #174 since add columns to same table

@genismauri please validate this issue and than assign to @cpopsa

application_price > YES
service_price > YES
BUT this should be for the 4 segments/sizes considered in the Business Plan:

application_price_small
application_price_medium
application_price_large
application_price_extra_large
service_price_small
service_price_medium
service_price_large
service_price_extra_large

NO!!
As already said many times there no implementation in the catalogue to managing sizing in that way.
Each service will have its own 2 prices and sizing becomes a replica of the same service with a different title, this is the maximum possible at the moment.
So:
Clearò - small city
Clearò - big City
Clearò - world
Reasons for needing different instances: the topology could/should be different (price change because more resources are used)
Also not all service could require all different sizing.
At the moment that is what we can do.
Aggregation of same services under a second entity is something that will have its own issue and go for sure on late milestones

OK with the aggregation of same services under a second entity, not so fancy but no problem.
But this conflicts with the Business Plan. Already considered for the financial calculations:
Clearò - small city
Clearò - medium city
Clearò - big city
Clearò - super big city
What does "world" mean?

@gioppoluca @xeviscc Just to clarify, if this was moved to 3.0.0, how this issue is solved in the current 2.0.0?

Each service can define its cost:

I think you can close the issue if you like the solution.

Looks ok!


Revert "Dont crash on API errors"

Reverts grpc/grpc#9541
This change introduced a bug (which is fixed in #9544).
One of these should be merged asap.

Going for the #9544 fix.

#9544 is in. Closing this.


Update deps

Should we update the pyproject.toml bounds then?

@hinthornw I thought about it but that can create some annoying issues for folks


@rx-angular/state - [Proposal] Tap method

Motivation
Do not use subscribe method with select in some trivial but frequent case.
We already use this approach in our code. He allows us not to think about unsubscribing.
Usage
When you need emit @Output
@Component({
  ...
  providers: [RxStateService]
})
export class TaskInfoComponent {
  @Output() loading = new EventEmitter<boolean>()

constructor(public rxStateService: RxStateService) {
  this.rxStateService.tap('loading', loading => this.loading.emit(loading))
  // or
  this.rxStateService.tap(state => this.loading.emit(state.loading))
}

Alternative for
this.rxStateService.select('loading').subscribe(loading => this.loading.emit(loading))
Implementation
It uses the hold method inside and can get select only to the top-level key
tap<K extends keyof T>(key: K, sideEffectFn?: (arg: T[K]) => void): void
tap(sideEffectFn: (arg: T) => void): void
tap<K extends keyof T>(keyOrFn: K | ((arg: T) => void), sideEffectFnOrNot?: undefined | ((arg: T[K]) => void)): void {
  if (isKeyOf<T>(keyOrFn)) {
    this.hold(this.select(keyOrFn), sideEffectFnOrNot)
    return
 } else {
    this.hold<T>(this.select(), keyOrFn)
    return
  }
}

What about a built-in flag that is active in dev mode?
And configurable on the instance too?

What should configure this flag?

Maybe better way it's to mix tap with hold.
this.rxStateService.hold(loadingListSideEffect$, value => this.loading.emit(value))
this.rxStateService.hold('loading', loading => this.loading.emit(loading))
this.rxStateService.hold(state => this.loading.emit(state.loading))

Implementation
Yes, more complex, but cleaner.
  hold<S>(obsOrObsWithSideEffect: Observable<S>, sideEffectFn?: (arg: S) => void): void
  hold<K extends keyof T>(key: K, sideEffectFn?: (arg: T[K]) => void): void
  hold(sideEffectFn: (arg: T) => void): void
  hold<K extends keyof T>(
    keyOrFnOrObs: K | ((arg: T) => void),
    sideEffectFnOrNot?: undefined | ((arg: T[K]) => void)
  ): void {
    if (isObservable(keyOrFnOrObs)) {
      if (sideEffectFnOrNot) {
        this.effectObservable.nextEffectObservable(obsOrObsWithSideEffect.pipe(tap(sideEffectFnOrNot)))
        return
      }
      this.effectObservable.nextEffectObservable(obsOrObsWithSideEffect)
    } else if (isKeyOf<T>(keyOrFnOrObs) && sideEffectFnOrNot) {
      this.effectObservable.nextEffectObservable(this.select(keyOrFnOrObs).pipe(tap(sideEffectFnOrNot)))
      return
    } else {
      this.effectObservable.nextEffectObservable(this.select().pipe(tap(keyOrFnOrObs)))
      return
    }
  }```

Hi @allfayn,
So as far as I understand you suggest another overload for hold that retrieves the state.
As hold is just here for side effects, and side effects by definition do not change state I would rather think of a separate solution.
I'll close this. Please feel free to reopen if there are things unclear.


I have submitted my portfolio

Please review my PR under Hacktoberfest 2022.

@RITEKROUNAK kindly review my pr under Hacktoberfest 2022.

Good work. I am merging your PR.
Do give us a star by hitting the star button of this repo!


drivers: misc: Add support for WIZ550io module

WIZ550io is a W5500 breakout board with an extra PIC12F519 MCU.
The PIC12F519 MCU initialises the W5500 with a unique MAC address after a GPIO reset.
The PIC12F519 requires a 150ms delay after GPIO reset to configure the W5500.
There is an optional "ready" GPIO signal that can be used to reduce that delay.

LGTM, please rebase. To add, does it makes sense to add the overlay based on WIZ550IO?

I have added a WIZ550io shield, similar to the arceli_eth_w5500 shield

@gramsay0 I'm a bit confused because I looked for this W5500io module on the internet and found these docs: https://docs.wiznet.io/Product/ioModule/W5500-io#pin-description but they don't say anything about a ready pin as far as I can tell, can you clarify the discrepancy?

nevermind, I just realized there is a w5500io and a w550io.... that's a bit confusing itself

@gramsay0
I noticed the RST pin on the w550io board is actually not the same signal as the RST going to the w5500 controller itself. It actually is a signal that goes to the PIC12F519, and a different pin from the PIC12F519 is connected to the w5500. And this signal is even documented differently, having different timing requirements.
I think this breakout board should have a different compatible, adding a ready signal to the w5500 compatible is incorrect. The DT could look something like this
&arduino_spi {
 	status = "okay";

	eth_w5500: eth_w5500@0 {
		compatible = "wiznet,w5500";
                ....
               /* do not put the reset gpio property here */
               no-reset;
	};
}

w550io {
		compatible = "wiznet,w550io";
		reset-gpios = <&arduino_header 14 GPIO_ACTIVE_LOW>;  /* D8 */
		ready-gpios = <&arduino_header 13 GPIO_ACTIVE_HIGH>; /* D7 */
                wiznet,w5500 = <&eth_w5500>
}

The issue of having board specific code in the file is actually not a huge problem, but I don't like how it's done right now which is just putting the code within some #if and checking if that property is present, which it shouldn't be since it shouldn't be part of that binding. Also, in my opinion, since these reset signals are not the same as each other, and the whole reset sequence really is different, code should reflect that, right now it's a weird hack looking code that can be misleading to future readers and potentially annoying to maintain.
To handle the different reset sequence, I would put a boolean DT property in the w5500 binding called "no-reset". I have done some research to confirm that properties like this are common in linux DT bindings to clarify that a device may be reset by another mechanism which is the case here, as the mechanism doing the reset will be the PIC12F519 rather than the host zephyr mcu. If this property is set, don't do the reset sequence in the w5500 init. Instead, you can have a SYS_INIT function in the same file that runs for every w550 node with higher priority than the w5500 init (ie runs before) that will do the appropriate reset sequence for this w550 module involving the longer wait after RST asserted and checking the RDY pin etc. You can also put in this function the spi read to read the mac address and I think you should have no problem setting the data in the w5500_runtime struct from here for the corresponding w5500 device in the phandle.
This way the code for the w550io is separate from the code for the w5500 and the DT bindings are accurate.

@decsny I agree and really like the approach you have proposed.
I'll have a look into implementing these changes, thanks

@decsny I have made the modifications you suggested.
Although I'm not certain the WIZ550io code is in the correct location, as it's not really an Ethernet controller. This could be moved elsewhere (drivers/misc?) if you prefer.
Rather than adding a "no-reset" property to W5500 I put a static assert in the WIZ550io driver to ensure the "reset-gpios" property is not set in the W5500 device

won't the init sequence in the eth_w5500 have some problems now?

won't the init sequence in the eth_w5500 have some problems now?

@decsny can you be more specific, I'm not sure what you are referring to?

approving because I'm assuming it works but what I meant is, doesn't the w5500 driver init still happen and will it conflict with what the w550io init is doing

Both the wiz550io and w5500 init occur. wiz550io has two asserts to prevent conflicts:

wiz550io init occurs first
w5500 device does not have GPIO reset enabled (SW reset is ok)

If neither "zephyr,random-mac-address" or "local-mac-address" are configured, w5500 leaves the mac address untouched, which in this case will use the wiz550io embedded MAC address

@parthitce @decsny are you both available to join the dev-review meeting tomorrow to discuss?

@parthitce @decsny @gramsay0 are you available to join the dev-review meeting tomorrow to discuss?

@MaureenHelm Yes, please share the time and method to join.

@parthitce @decsny @gramsay0 are you available to join the dev-review meeting tomorrow to discuss?

@MaureenHelm Yes, please share the time and method to join.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Groups#zephyr-dev-meeting

@parthitce @decsny @gramsay0 are you available to join the dev-review meeting tomorrow to discuss?

@MaureenHelm Yes, please share the time and method to join.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Groups#zephyr-dev-meeting

I was occupied with another meeting and couldn't come in time. If you have already discussed, happy to sync with the status or otherwise in next call. Thanks

@parthitce @decsny @gramsay0 are you available to join the dev-review meeting tomorrow to discuss?

@MaureenHelm Yes, please share the time and method to join.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Groups#zephyr-dev-meeting

I was occupied with another meeting and couldn't come in time. If you have already discussed, happy to sync with the status or otherwise in next call. Thanks

We discussed about putting the code in the shield board folder instead of drivers/misc which is fine by me but not sure if there is actually infrastructure in place to pull in c code for a shield.... since I didn't find any other shield with c code and didn't see any infrastructure for it. If it is possible then I definitely prefer it over drivers/misc because it is more obviously associated with the board rather than being somewhere else

We discussed about putting the code in the shield board folder instead of drivers/misc which is fine by me but not sure if there is actually infrastructure in place to pull in c code for a shield.... since I didn't find any other shield with c code and didn't see any infrastructure for it. If it is possible then I definitely prefer it over drivers/misc because it is more obviously associated with the board rather than being somewhere else

Following up here: I think you're right. There appears to be no infrastructure for this at the moment.

We discussed about putting the code in the shield board folder instead of drivers/misc which is fine by me but not sure if there is actually infrastructure in place to pull in c code for a shield.... since I didn't find any other shield with c code and didn't see any infrastructure for it. If it is possible then I definitely prefer it over drivers/misc because it is more obviously associated with the board rather than being somewhere else

Following up here: I think you're right. There appears to be no infrastructure for this at the moment. I initially thought it would work the same way as with boards.

okay, then maybe drivers/misc appears still the most appropriate place we have thought of for it that doesn't require effort outside the scope of the PR

The dev-review meeting timezone does not work well for me. I agree with the idea that was discussed.
I created a PR to allow adding source code for shields: https://github.com/zephyrproject-rtos/zephyr/pull/75310

@parthitce Are you okay with this new approach now? It has gone to extensive review in the dev review meeting and architecture working group, so hopefully this PR can be close to merging after a long time now

So the random-mac address (if added in the dts) will be used even if unique MAC is available?

@parthitce yes, although setting "local-mac-address" from the device tree was not working.
I have updated with a fix

How does the application find the CMakeLists.txt?

@gramsay0 I can imagine this PR has been frustrating, but do you plan to return to it?

@gramsay0 I can imagine this PR has been frustrating, but do you plan to return to it?

@decsny yes, this PR has been a bit frustrating.

So my suggestion is this... I think you could basically keep the idea of the C code the same but just add a boards/ folder within the shield directory (see other shields for examples) to allow board specific overlays to add the GPIOs, which could be specified as GPIO hogs (which are children nodes of the gpio controller node, see the gpio controller bindings for details). The gpio hog nodes could be aliased to a standard alias name in the main shield overlay so that the C code can reference it. This way, you dont need a binding for the shield. Similar approach for the reference to the ethernet controller, you could do this with an alias instead of a DT property for a new binding.

This seems like a bit of a hack, a "DT compatible" seems much cleaner and follows the DT/driver pattern used elsewhere.
How would you write a multi-instance driver like this?

the spi could be figured out from the DT in this file instead of looking at the ethernet mac config

instead of using the driver runtime from the ethernet controller, I believe that there is an API that can be called to set the mac address

I agree with these points

This seems like a bit of a hack, a "DT compatible" seems much cleaner and follows the DT/driver pattern used elsewhere.
How would you write a multi-instance driver like this?

Okay, I didn't think of it as a hack (and actually thought it was pretty clean) because I was not considering the shield  .c file to be a "driver".... I guess is it expected for a user to use multiple instances of this same shield ? If it is, then yeah maybe we need to refine the idea or have a different one... or maybe for now it would be easier to have this shield be single instance and hopefully get past the blocks on this PR and get this finally merged in?

@decsny I had a go at making your suggested changes, please take another look

@gmarull @parthitce please re-review.

should be a driver quirk

I disagree, the logic is only needed for the shield, so keep it as close to the shield as possible. Image if there'd exist many different variants of the shield, each with there own quirk. That would be unmaintainable in the driver.
This on the other hand, shows a clear separation of concerns, and is the cleanest solution IMO.

should be a driver quirk

I disagree, the logic is only needed for the shield, so keep it as close to the shield as possible. Image if there'd exist many different variants of the shield, each with there own quirk. That would be unmaintainable in the driver.
This on the other hand, shows a clear separation of concerns, and is the cleanest solution IMO.

If they have made a piece of HW that behaves differently that off-the-shelf W5500, they should in a first place describe it in DT as vnd,wiz550io. Then a driver that re-uses WIZ5500 code can be created, just with an init call that does any necessary extra work to make the module work as expected. Any board/shield level code is a hack. Just see: eth_w5500 doesn't even work without the gpio-hogs being run, and the dependency is not captured everywhere. So my -1 stands.

should be a driver quirk

I disagree, the logic is only needed for the shield, so keep it as close to the shield as possible. Image if there'd exist many different variants of the shield, each with there own quirk. That would be unmaintainable in the driver.
This on the other hand, shows a clear separation of concerns, and is the cleanest solution IMO.

If they have made a piece of HW that behaves differently that off-the-shelf W5500, they should in a first place describe it in DT as vnd,wiz550io. Then a driver that re-uses WIZ5500 code can be created, just with an init call that does any necessary extra work to make the module work as expected. Any board/shield level code is a hack. Just see: eth_w5500 doesn't even work without the gpio-hogs being run, and the dependency is not captured everywhere. So my -1 stands.

You are showing that you don't even understand the PR, this is not a piece of hardware that "behaves differently than the off the shelf W5500", this is a BREAKOUT BOARD with the main purpose of having a W5500 on it. There's no hack, we discussed multiple times that putting board specific gpio signalling in an ethernet mac driver would be the hack. And ARCH WG and dev review discussed this PR each multiple times and discussed and approved the shield level code idea more broadly, so this should not be a blocker for this PR from one person who doesn't agree, we already moved forward as a project with the idea many months ago.

should be a driver quirk

I disagree, the logic is only needed for the shield, so keep it as close to the shield as possible. Image if there'd exist many different variants of the shield, each with there own quirk. That would be unmaintainable in the driver.
This on the other hand, shows a clear separation of concerns, and is the cleanest solution IMO.

If they have made a piece of HW that behaves differently that off-the-shelf W5500, they should in a first place describe it in DT as vnd,wiz550io. Then a driver that re-uses WIZ5500 code can be created, just with an init call that does any necessary extra work to make the module work as expected. Any board/shield level code is a hack. Just see: eth_w5500 doesn't even work without the gpio-hogs being run, and the dependency is not captured everywhere. So my -1 stands.

You are showing that you don't even understand the PR, this is not a piece of hardware that "behaves differently than the off the shelf W5500", this is a BREAKOUT BOARD with the main purpose of having a W5500 on it. There's no hack, we discussed multiple times that putting board specific gpio signalling in an ethernet mac driver would be the hack. And ARCH WG and dev review discussed this PR each multiple times and discussed and approved the shield level code idea more broadly, so this should not be a blocker for this PR from one person who doesn't agree, we already moved forward as a project with the idea many months ago.

Can you then respond to this simple question: does DT capture dependencies properly? Spoiler: no.

should be a driver quirk

I disagree, the logic is only needed for the shield, so keep it as close to the shield as possible. Image if there'd exist many different variants of the shield, each with there own quirk. That would be unmaintainable in the driver.
This on the other hand, shows a clear separation of concerns, and is the cleanest solution IMO.

If they have made a piece of HW that behaves differently that off-the-shelf W5500, they should in a first place describe it in DT as vnd,wiz550io. Then a driver that re-uses WIZ5500 code can be created, just with an init call that does any necessary extra work to make the module work as expected. Any board/shield level code is a hack. Just see: eth_w5500 doesn't even work without the gpio-hogs being run, and the dependency is not captured everywhere. So my -1 stands.

You are showing that you don't even understand the PR, this is not a piece of hardware that "behaves differently than the off the shelf W5500", this is a BREAKOUT BOARD with the main purpose of having a W5500 on it. There's no hack, we discussed multiple times that putting board specific gpio signalling in an ethernet mac driver would be the hack. And ARCH WG and dev review discussed this PR each multiple times and discussed and approved the shield level code idea more broadly, so this should not be a blocker for this PR from one person who doesn't agree, we already moved forward as a project with the idea many months ago.

Can you then respond to this simple question: does DT capture dependencies properly? Spoiler: no.

Which dependencies are you talking about? I think the PR as it stands right now clearly shows the DT capturing the situation. There is a w5500 ethernet mac and some gpios that need to be toggled. It's not that complicated.

, they should in a first place describe it in DT as vnd,wiz550io.

Also, the author had this originally, and in the most recent revision they removed it because of your block.

should be a driver quirk

I disagree, the logic is only needed for the shield, so keep it as close to the shield as possible. Image if there'd exist many different variants of the shield, each with there own quirk. That would be unmaintainable in the driver.
This on the other hand, shows a clear separation of concerns, and is the cleanest solution IMO.

If they have made a piece of HW that behaves differently that off-the-shelf W5500, they should in a first place describe it in DT as vnd,wiz550io. Then a driver that re-uses WIZ5500 code can be created, just with an init call that does any necessary extra work to make the module work as expected. Any board/shield level code is a hack. Just see: eth_w5500 doesn't even work without the gpio-hogs being run, and the dependency is not captured everywhere. So my -1 stands.

You are showing that you don't even understand the PR, this is not a piece of hardware that "behaves differently than the off the shelf W5500", this is a BREAKOUT BOARD with the main purpose of having a W5500 on it. There's no hack, we discussed multiple times that putting board specific gpio signalling in an ethernet mac driver would be the hack. And ARCH WG and dev review discussed this PR each multiple times and discussed and approved the shield level code idea more broadly, so this should not be a blocker for this PR from one person who doesn't agree, we already moved forward as a project with the idea many months ago.

Can you then respond to this simple question: does DT capture dependencies properly? Spoiler: no.

Which dependencies are you talking about? I think the PR as it stands right now clearly shows the DT capturing the situation. There is a w5500 ethernet mac and some gpios that need to be toggled. It's not that complicated.

	wiz550io_reset: wiz550io-reset {
		gpio-hog;
		gpios = <12 GPIO_ACTIVE_LOW>; /* D8 */
		output-high;
	};

	wiz550io_ready: wiz550io-ready {
		gpio-hog;
		gpios = <13 GPIO_ACTIVE_HIGH>; /* D7 */
		input;
	};

^ There's nothing that indicates these are needed by WIZ5500 to operate correctly. Just C code with SYS_INIT hackery. This simply needs a better solution, and my firm -1 stands.

should be a driver quirk

I disagree, the logic is only needed for the shield, so keep it as close to the shield as possible. Image if there'd exist many different variants of the shield, each with there own quirk. That would be unmaintainable in the driver.
This on the other hand, shows a clear separation of concerns, and is the cleanest solution IMO.

If they have made a piece of HW that behaves differently that off-the-shelf W5500, they should in a first place describe it in DT as vnd,wiz550io. Then a driver that re-uses WIZ5500 code can be created, just with an init call that does any necessary extra work to make the module work as expected. Any board/shield level code is a hack. Just see: eth_w5500 doesn't even work without the gpio-hogs being run, and the dependency is not captured everywhere. So my -1 stands.

You are showing that you don't even understand the PR, this is not a piece of hardware that "behaves differently than the off the shelf W5500", this is a BREAKOUT BOARD with the main purpose of having a W5500 on it. There's no hack, we discussed multiple times that putting board specific gpio signalling in an ethernet mac driver would be the hack. And ARCH WG and dev review discussed this PR each multiple times and discussed and approved the shield level code idea more broadly, so this should not be a blocker for this PR from one person who doesn't agree, we already moved forward as a project with the idea many months ago.

Can you then respond to this simple question: does DT capture dependencies properly? Spoiler: no.

Which dependencies are you talking about? I think the PR as it stands right now clearly shows the DT capturing the situation. There is a w5500 ethernet mac and some gpios that need to be toggled. It's not that complicated.

	wiz550io_reset: wiz550io-reset {
		gpio-hog;
		gpios = <12 GPIO_ACTIVE_LOW>; /* D8 */
		output-high;
	};

	wiz550io_ready: wiz550io-ready {
		gpio-hog;
		gpios = <13 GPIO_ACTIVE_HIGH>; /* D7 */
		input;
	};

^ There's nothing that indicates these are needed by WIZ5500 to operate correctly. Just C code with SYS_INIT hackery. This simply needs a better solution, and my firm -1 stands.

You're absolutely right, they are not needed specifically by the W5500 mac, which is why we don't want to put it in the driver for the W5500.

should be a driver quirk

I disagree, the logic is only needed for the shield, so keep it as close to the shield as possible. Image if there'd exist many different variants of the shield, each with there own quirk. That would be unmaintainable in the driver.
This on the other hand, shows a clear separation of concerns, and is the cleanest solution IMO.

If they have made a piece of HW that behaves differently that off-the-shelf W5500, they should in a first place describe it in DT as vnd,wiz550io. Then a driver that re-uses WIZ5500 code can be created, just with an init call that does any necessary extra work to make the module work as expected. Any board/shield level code is a hack. Just see: eth_w5500 doesn't even work without the gpio-hogs being run, and the dependency is not captured everywhere. So my -1 stands.

You are showing that you don't even understand the PR, this is not a piece of hardware that "behaves differently than the off the shelf W5500", this is a BREAKOUT BOARD with the main purpose of having a W5500 on it. There's no hack, we discussed multiple times that putting board specific gpio signalling in an ethernet mac driver would be the hack. And ARCH WG and dev review discussed this PR each multiple times and discussed and approved the shield level code idea more broadly, so this should not be a blocker for this PR from one person who doesn't agree, we already moved forward as a project with the idea many months ago.

Can you then respond to this simple question: does DT capture dependencies properly? Spoiler: no.

Which dependencies are you talking about? I think the PR as it stands right now clearly shows the DT capturing the situation. There is a w5500 ethernet mac and some gpios that need to be toggled. It's not that complicated.

	wiz550io_reset: wiz550io-reset {
		gpio-hog;
		gpios = <12 GPIO_ACTIVE_LOW>; /* D8 */
		output-high;
	};

	wiz550io_ready: wiz550io-ready {
		gpio-hog;
		gpios = <13 GPIO_ACTIVE_HIGH>; /* D7 */
		input;
	};

^ There's nothing that indicates these are needed by WIZ5500 to operate correctly. Just C code with SYS_INIT hackery. This simply needs a better solution, and my firm -1 stands.

You're absolutely right, they are not needed specifically by the W5500 mac, which is why we don't want to put it in the driver for the W5500.

Then please, describe this properly in DT at the very least. Then request a re-review so I can provide feedback.

should be a driver quirk

I disagree, the logic is only needed for the shield, so keep it as close to the shield as possible. Image if there'd exist many different variants of the shield, each with there own quirk. That would be unmaintainable in the driver.
This on the other hand, shows a clear separation of concerns, and is the cleanest solution IMO.

If they have made a piece of HW that behaves differently that off-the-shelf W5500, they should in a first place describe it in DT as vnd,wiz550io. Then a driver that re-uses WIZ5500 code can be created, just with an init call that does any necessary extra work to make the module work as expected. Any board/shield level code is a hack. Just see: eth_w5500 doesn't even work without the gpio-hogs being run, and the dependency is not captured everywhere. So my -1 stands.

You are showing that you don't even understand the PR, this is not a piece of hardware that "behaves differently than the off the shelf W5500", this is a BREAKOUT BOARD with the main purpose of having a W5500 on it. There's no hack, we discussed multiple times that putting board specific gpio signalling in an ethernet mac driver would be the hack. And ARCH WG and dev review discussed this PR each multiple times and discussed and approved the shield level code idea more broadly, so this should not be a blocker for this PR from one person who doesn't agree, we already moved forward as a project with the idea many months ago.

Can you then respond to this simple question: does DT capture dependencies properly? Spoiler: no.

Which dependencies are you talking about? I think the PR as it stands right now clearly shows the DT capturing the situation. There is a w5500 ethernet mac and some gpios that need to be toggled. It's not that complicated.

	wiz550io_reset: wiz550io-reset {
		gpio-hog;
		gpios = <12 GPIO_ACTIVE_LOW>; /* D8 */
		output-high;
	};

	wiz550io_ready: wiz550io-ready {
		gpio-hog;
		gpios = <13 GPIO_ACTIVE_HIGH>; /* D7 */
		input;
	};

^ There's nothing that indicates these are needed by WIZ5500 to operate correctly. Just C code with SYS_INIT hackery. This simply needs a better solution, and my firm -1 stands.

You're absolutely right, they are not needed specifically by the W5500 mac, which is why we don't want to put it in the driver for the W5500.

Then please, describe this properly in DT at the very least. Then request a re-review so I can provide feedback.

What would make it "more proper" in your opinion

please follow the escalation process described here: https://docs.zephyrproject.org/latest/contribute/contributor_expectations.html#pr-technical-escalation

please follow the escalation process described here: https://docs.zephyrproject.org/latest/contribute/contributor_expectations.html#pr-technical-escalation

We have, this PR has been discussed in the Arch WG and dev review meeting multiple times, and the stated change request is in opposition to the conclusions agreed in those meetings

should be a driver quirk

I disagree, the logic is only needed for the shield, so keep it as close to the shield as possible. Image if there'd exist many different variants of the shield, each with there own quirk. That would be unmaintainable in the driver.
This on the other hand, shows a clear separation of concerns, and is the cleanest solution IMO.

If they have made a piece of HW that behaves differently that off-the-shelf W5500, they should in a first place describe it in DT as vnd,wiz550io. Then a driver that re-uses WIZ5500 code can be created, just with an init call that does any necessary extra work to make the module work as expected. Any board/shield level code is a hack. Just see: eth_w5500 doesn't even work without the gpio-hogs being run, and the dependency is not captured everywhere. So my -1 stands.

You are showing that you don't even understand the PR, this is not a piece of hardware that "behaves differently than the off the shelf W5500", this is a BREAKOUT BOARD with the main purpose of having a W5500 on it. There's no hack, we discussed multiple times that putting board specific gpio signalling in an ethernet mac driver would be the hack. And ARCH WG and dev review discussed this PR each multiple times and discussed and approved the shield level code idea more broadly, so this should not be a blocker for this PR from one person who doesn't agree, we already moved forward as a project with the idea many months ago.

Can you then respond to this simple question: does DT capture dependencies properly? Spoiler: no.

Which dependencies are you talking about? I think the PR as it stands right now clearly shows the DT capturing the situation. There is a w5500 ethernet mac and some gpios that need to be toggled. It's not that complicated.

	wiz550io_reset: wiz550io-reset {
		gpio-hog;
		gpios = <12 GPIO_ACTIVE_LOW>; /* D8 */
		output-high;
	};

	wiz550io_ready: wiz550io-ready {
		gpio-hog;
		gpios = <13 GPIO_ACTIVE_HIGH>; /* D7 */
		input;
	};

^ There's nothing that indicates these are needed by WIZ5500 to operate correctly. Just C code with SYS_INIT hackery. This simply needs a better solution, and my firm -1 stands.

You're absolutely right, they are not needed specifically by the W5500 mac, which is why we don't want to put it in the driver for the W5500.

Then please, describe this properly in DT at the very least. Then request a re-review so I can provide feedback.

What would make it "more proper" in your opinion

Any solution that represents dependencies in DT correctly, ie, WIZ550io GPIO ports ordinal < WIZ5500 in all cases. Also, it looks like this solution is accessing internals:
		const struct ethernet_api *w5500_api = w5500_dev->api;
		struct ethernet_config config = {.mac_address = wiz550io_mac_addr};

		ret = w5500_api->set_config(w5500_dev, ETHERNET_CONFIG_TYPE_MAC_ADDRESS, &config);

Overall, this PR is a dirty hack.

please follow the escalation process described here: https://docs.zephyrproject.org/latest/contribute/contributor_expectations.html#pr-technical-escalation

We have, this PR has been discussed in the Arch WG and dev review meeting multiple times, and the stated change request is in opposition to the conclusions agreed in those meetings

Meetings to not replace reviews, have I missed something?


cargo-vendor: fix build

Motivation for this change
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

@GrahamcOfBorg build cargo-vendor

Success on x86_64-linux (full log)
Attempted: cargo-vendor
Partial log (click to expand)

installing
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/alb7j9m3cpmfkr6dp45s24l5bcipq43x-rust_cargo-vendor-0.1.13
shrinking /nix/store/alb7j9m3cpmfkr6dp45s24l5bcipq43x-rust_cargo-vendor-0.1.13/bin/cargo-vendor
strip is /nix/store/j75dgadrff2d1fyc4fczmcgqkid2imdx-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/alb7j9m3cpmfkr6dp45s24l5bcipq43x-rust_cargo-vendor-0.1.13/lib  /nix/store/alb7j9m3cpmfkr6dp45s24l5bcipq43x-rust_cargo-vendor-0.1.13/bin
patching script interpreter paths in /nix/store/alb7j9m3cpmfkr6dp45s24l5bcipq43x-rust_cargo-vendor-0.1.13
checking for references to /build in /nix/store/alb7j9m3cpmfkr6dp45s24l5bcipq43x-rust_cargo-vendor-0.1.13...
/nix/store/alb7j9m3cpmfkr6dp45s24l5bcipq43x-rust_cargo-vendor-0.1.13

Success on x86_64-darwin (full log)
Attempted: cargo-vendor
Partial log (click to expand)
warning: redundant linker flag specified for library `ssl`

warning: redundant linker flag specified for library `z`

installing
post-installation fixup
strip is /nix/store/kdff2gim6417493yha769kh00n63lnrw-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/74f9c2j0h9j65fsa1qgf0z3nv0i87dp2-rust_cargo-vendor-0.1.13/lib  /nix/store/74f9c2j0h9j65fsa1qgf0z3nv0i87dp2-rust_cargo-vendor-0.1.13/bin
patching script interpreter paths in /nix/store/74f9c2j0h9j65fsa1qgf0z3nv0i87dp2-rust_cargo-vendor-0.1.13
/nix/store/74f9c2j0h9j65fsa1qgf0z3nv0i87dp2-rust_cargo-vendor-0.1.13

Success on aarch64-linux (full log)
Attempted: cargo-vendor
Partial log (click to expand)

installing
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/5ws1fjbz186vvi5rqif5c6q73m95nls4-rust_cargo-vendor-0.1.13
shrinking /nix/store/5ws1fjbz186vvi5rqif5c6q73m95nls4-rust_cargo-vendor-0.1.13/bin/cargo-vendor
strip is /nix/store/jk6j4lh9v5mvjdbdc35sj0zffhhf6s56-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/5ws1fjbz186vvi5rqif5c6q73m95nls4-rust_cargo-vendor-0.1.13/lib  /nix/store/5ws1fjbz186vvi5rqif5c6q73m95nls4-rust_cargo-vendor-0.1.13/bin
patching script interpreter paths in /nix/store/5ws1fjbz186vvi5rqif5c6q73m95nls4-rust_cargo-vendor-0.1.13
checking for references to /build in /nix/store/5ws1fjbz186vvi5rqif5c6q73m95nls4-rust_cargo-vendor-0.1.13...
/nix/store/5ws1fjbz186vvi5rqif5c6q73m95nls4-rust_cargo-vendor-0.1.13

Unfortunately a new nixos-unstable landed 11 hours ago without this fix, as a result at least the build of alacritty and ripgrep is broken there.

At least nixos-unstable-small includes this patch again.


[Feature Request] Packaging chrome extensions

A really great feature would be an option to package chrome extensions. For example, pointing the script to CRX files or even to the chrome webstore URLs.
This would open up a bunch of new possibilities. I'm personally thinking about a YouTube Music client with integrated adblock and an extension that automatically confirms the "yes, i'm still listening" popup.

Agreed. Please add support for Firefox extensions too if this gets implemented

Agreed. Please add support for Firefox extensions too if this gets implemented

As this is running chromium (which, as the name suggests, is basically chrome) under the hood, firefox extensions would not be possible.

Ah, of course it is running Chromium

An ad block integrated in appimage

As this is basically an extension of Nativefier, please check out this issue on their page.  It points to a solution (I can't figure out how to use it, but others have) for AdBlocking and also discusses using Chrome/Chromium extensions in the apps.


Improve README.md

Now sitemaps are generated at runtime. There is no more generate command and storage.

The README is about the version you find in master and the v2 beta versions. v1 generates them at runtime.

Ah sorry @stefandoorn. Didn't noticed that.


CAD-1208: Prometheus JSON output.

description
Previously Prometheus' output was ini-like formatted, for example:
...
rts_gc_gc_wall_ms 38
cardano_node_metrics_Mem_resident_int 17748
rts_gc_mutator_cpu_ms 316
rts_gc_peak_megabytes_allocated 50
...

Now the output is in JSON-format which is easier to parse. An example:
[
  {
    "metrics": [
      {
        "value": 0,
        "name": "par_max_bytes_copied",
        "type": "int"
      },
      {
        "value": 0,
        "name": "par_avg_bytes_copied",
        "type": "int"
      },
      {
        "value": 1,
        "name": "init_cpu_ms",
        "type": "int"
      },
      {
        "value": 7308376,
        "name": "bytes_allocated",
        "type": "int"
      },
      {
        "value": 6,
        "name": "num_bytes_usage_samples",
        "type": "int"
      },
      {
        "value": 105264,
        "name": "current_bytes_slop",
        "type": "int"
      },
      {
        "value": 105264,
        "name": "max_bytes_slop",
        "type": "int"
      },
      {
        "value": 0,
        "name": "par_tot_bytes_copied",
        "type": "int"
      },
      {
        "value": 3068968,
        "name": "cumulative_bytes_used",
        "type": "int"
      },
      {
        "value": 13,
        "name": "gc_wall_ms",
        "type": "int"
      },
      {
        "value": 34,
        "name": "cpu_ms",
        "type": "int"
      }
    ],
    "namespace": "rts.gc"
  }
  ...
]

Please note that only rts.gc-metrics are grouped in one group "rts.gc". All other metrics can have different names and we can not make any assumptions about the format of these names. So all other metrics are grouped in "common" group. An example:
{
    "metrics": [
      {
        "value": 0.1,
        "name": "iohk-monitoring version",
        "type": "real"
      },
      {
        "value": 26.30240838783037,
        "name": "complex.random.rr",
        "type": "real"
      },
      {
        "value":<PHONE_NUMBER>685,
        "name": "ekg.server_timestamp_ms",
        "type": "int"
      },
      {
        "value": 37.711116781794196,
        "name": "complex.#aggregation.complex.random.ewma.rr.rr.avg",
        "type": "real"
      }
    ],
    "namespace": "common"
  }

Please note that it's possible to choose a format using this option:
CM.setTextOption c "prometheusOutput" "json"  -- Prometheus' output in JSON-format

If this option is not specified in the configuration - an old format will be used.
checklist

[x] compiles (cabal v2-build or stack build)
[x] tests run successfully (cabal v2-test or stack test)
[ ] documentation added
[x] link to an issue
[ ] add milestone (the current sprint)

bors r+


Set websocket=True for Rule, fixes #81

This fixes the WebsocketMismatch which appears with Werkzeug 2.0.0.
The cause is a websocket request hits a rule which Werkzeug doesn't think is a websocket endpoint.

Unfortunately, Werkzeug pre 2.0.0 doesn't always label websocket requests correctly, so with this PR, you can end up with the opposite mismatch.
Here's the change to Werkzeug where more websocket requests get labelled correctly: https://github.com/pallets/werkzeug/pull/2053/files#diff-9b2e55f893697ae8ac344aebf17bebee83546fc2bf4d8e1b138cf7c63e92080fR1637-R1641

Hi @tomviner,
I ended up with a similar change to make things work on my side, but in addition to your commit I also had to add the following change:
@@ -27,7 +27,7 @@ class SocketMiddleware(object):
     def __call__(self, environ, start_response):
         adapter = self.ws.url_map.bind_to_environ(environ)
         try:
-            handler, values = adapter.match()
+            handler, values = adapter.match(websocket=True)
             environment = environ['wsgi.websocket']
             cookie = None
             if 'HTTP_COOKIE' in environ:

In my tests this makes WebsocketMismatch disappear for a web page socket and a socket opened in Android with Kotlin Ktor API. Not sure if this is universally helpful though...

@tomviner thanks for this fix. It looks like it fixes most of my problems with the Flask upgrade.

Unfortunately, Werkzeug pre 2.0.0 doesn't always label websocket requests correctly, so with this PR, you can end up with the opposite mismatch.
Here's the change to Werkzeug where more websocket requests get labelled correctly: https://github.com/pallets/werkzeug/pull/2053/files#diff-9b2e55f893697ae8ac344aebf17bebee83546fc2bf4d8e1b138cf7c63e92080fR1637-R1641

Maybe also add the constraint Flask>=2.0 in setup.py then.

If there's an issue with misrecognizing sockets, maybe the solution would be to use the options kwargs instead?
self.url_map.add(Rule(rule, endpoint=f, **options))

And then you'd use it thus:
@sockets.route("/countdown_ctrl", websocket=True)
def control_socket(ws):

Older versions of flask_sockets would ignore that, so an app that sets this flag would be compatible with both.


Presence of flow.js at the root of app

Hi,
Am I doing a bad manipulation when doing ember install ember-pop-over, because I end up having the file flow.js at the root of my application (app/flow.js). This is quite unusual for an addon to add files like that, is it the desired behavior?
Thanks!

Yes, it's desired behavior. It's done to match how liquid-fire works

:+1:


chore: jsonfmt machinelearningservices

Ran jsonfmt -w "specification/machinelearningservices/**/*.json"

Automation for azure-sdk-for-ruby

Automation for azure-sdk-for-python

Can one of the admins verify this patch?

Automation for azure-sdk-for-js

Automation for azure-sdk-for-java

Automation for azure-sdk-for-go


WebVR documentation

This is an initial version!

IMPRESSIVE work...Thank you so much!

Thanks my friend! You can merge at will


Chaining sorts (multi column sort) does not seem to work after deletion of an item

Goals
We are trying to use a result set to drive Rx code and that result set would have a primary and secondary sort (e.g. sort by a name and within that name group sort by a date).
Expected Results
We ran into an issue where after deleting an item from the result set that items within the secondary sort (the date) were reordered.  It behaves as though the result set was only honoring the last sort criteria used and doing so in a "destructive sort" way.
Actual Results
We would see a grouping initially like so (sorted by Name and then by Date)

Item
Name
Date

Item1
Abc123
May 29

Item3
Abc123
Jun 2

Item2
Pdq567
May 30

Item4
Pdq567
June 3

Item5
Pdq567
June 4

Item6
Pdq567
June 5

Then after deleting Item4 we'd see Item6 change position:

Item
Name
Date

Item1
Abc123
May 29

Item3
Abc123
Jun 2

Item6
Pdq567
June 5

Item2
Pdq567
May 30

Item5
Pdq567
June 4

We also tried using the sorting() overload that accepts SortDescriptors but that didn't seem to work either.
Steps to Reproduce

Create a result set using 2 sorts as explained in the previous section.
Remove one item in the result set from the realm
Observe the result set in step1 after the change and the order of the items in the set has changed

Code Sample
We are accessing the the realm objects like this and sorting twice to accomplish the 2 column sort.
let queueItems = realm.objects(UploadQueueItemDbEntity.self).sorted(byProperty: "dateAddedToQueue").sorted(byProperty: "projectName")
return Observable.changesetArrayFrom(queueItems)

Version of Realm and Tooling
Realm version: ?
2.1.2
Xcode version: ?
8.2
iOS/OSX version: ?
OSX 10.11.6/iOS 10.2
Dependency manager + version: ?
Cocoapods/1.1.1

Hi @SlashDevSlashGnoll. Thanks for reaching out for support. I will have someone review what you've submitted and respond with a solution or follow-up questions as soon as possible. We appreciate your patience.

Results.sorted(byProperty:) replaces any existing sort criteria. If you'd like to sort by multiple properties, you can use Results.sorted(by:) and pass multiple SortDescriptors.

Hi bdash, we had tried that as well (mentioned that briefly above) but it didn't seem to work.

Hmm. In that case I think we'll need to be able to reproduce this to understand what's going on. Can you provide some code that demonstrates the problem?

Just bringing attention back to this. @SlashDevSlashGnoll: Would you be able to provide some code that demonstrates the problem? If you need to (for confidentiality), you can email us the project to<EMAIL_ADDRESS>Thanks!

Apologies, things have been busy.  I will try to put together something that exhibits the behavior

So after some digging I think we've determined that it's working fine and we had a misunderstanding.  I think this does point to an issue with the documentation so perhaps that's all it needs.  A few points that could be addressed in the docs:

The docs say that sorting can be done "based on a single or multiple properties or key paths" and the example uses the byKeyPath method.  This does not support multiple properties and it lead us to believe you can chain sorts in a fluent way like the other operations (the very next section talks about chaining).  Perhaps the docs should be clearer that sorting on multiple fields requires the SortDescriptors method
The Results.sorted(by:) method should document the order in which the sort descriptors are applied, e.g. which one is the "outermost" sort

Thanks for the attention and sorry for the false alarm!

Thanks for the suggestions to improve our docs @SlashDevSlashGnoll! Maybe @chipotle would be interested in making these clarifications?
By the way, I hope you don't mind I modified this ticket to track making these docs improvements rather than creating a new issue in order to preserve the conversation.

Okay, I'll take a stab at it. Someone who actually knows Swift/Objective-C will need to review my pull request to make sure what I'm saying isn't a complete lie. :)

Fixed in the commit referenced above (and now live on the web site)


Time Range with relative and absolute selection options.

Summary
Hi Team,
I am from TRIRIGA Building Insights development team, we have requirement for a new time range component. More details on the expected functionality and visualization of this component is in the below invision link.
https://ibm.invisionapp.com/share/UBNZD4FX2JE#/screens/319292931
Specific timeline issues / requests
This new component is required for upcoming early Jan 2020 release.
You will consider this component complete when...

[ ] It's available as an export of this library
[ ] Additional criteria you may have [e.g. Fully responsive, Accessible to WCAG 2.0, etc.]

Hi @kalyanixraut 👋thanks for surfacing this request.
This would be a welcome contribution from your team if the design is documented and agreed-upon first by the PAL design team. Please work with your designers to propose this in an issue on the internal pal-tracking repository.

The Date and Time range picker for Building Insights for next release
Additional context
Add any other context about the component here [e.g. screenshots, code, InVision prototype, Box notes containing details necessary for implementation]
Invision prototype screen
Should be able to :

Select a date and time from the calendar widget.
or
Select a start time period from the choice of last 24 hours, 7 days, 30 days, 3 months, 6 months or 12 months.


scheduled CI gets eventually disabled

I realized the doc website wasn't being updated and found this on this repo:

It seems that we can't really rely on this to keep docs up to date. I know the correct solution is to get a token for the repo and trigger the build from the main site, however infra didn't move on this despite our repeated requests. I'm not sure how to solve this.

I will re-enable this now but it is a matter of time to have to same problem again later.

There was a bunch of discussion around this topic a few months back on the builds infra mailing list. I can try to circle back to it.


Add bank icons to the PaymentMethodsList

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Actual behavior:
Currently, bank accounts in the payment methods list only have the generic icon for banks/cards. Here's a screenshot for reference:

Expected behavior:
We want the banks/cards to have their actual brand/logo icons, like this:

Please consider the following when building the Expected behavior:

Add the bank icons to the Expensicons file
Modify paymentMethodList.js to attempt to match the right icon with each account

For bank accounts the bank name should be in bankAccount.additionalData.bankName
For credit cards, the bank name should be in card.bank
If the field is blank, or does not match an existing bank icon, default to the generic bank icon
drive-download-20210723T192557Z-001.zip

These are the lists of all bank/card names. Given that there are a lot of different names for things like American Express, I think the best way to do it will be something like this rather than trying to match each one directly. If you have a better idea feel free to pitch it to me!
if (bankAccount.additionalData.bankName.toLowerCase().contains('americanexpress')) {
    // american express icon
}

banklist.csv
bankaccountlist.csv
Platform:

Web ✅
Desktop ✅
Android ✅
iOS ✅

Expensify/Expensify Issue URL: https://github.com/Expensify/Expensify/issues/169740
Upwork job link: https://www.upwork.com/jobs/~01ab696311bb024cbd

Triggered auto assignment to @marcaaron (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

Triggered auto assignment to @arielgreen (External), see https://stackoverflow.com/c/expensify/questions/8582 for more details.

@michaelhaxhiu  ZIP is not downloadable

@Santhosh-Sellavel can you try once more? I think it was an issue of copy/pasting that zip file from another GH respository.

If we know possiblebankName we can use the same name for assets and retrieve assest it's a one time job. No checks would be needed further

@Santhosh-Sellavel can you try once more? I think it was an issue of copy/pasting that zip file from another GH respository.

It's working now check other attachments also.

Proposal

I'll add all bank icons to ExpensiIcons
or src/components/Icon/BankIcons.js can be created
in this.props.bankAccountsList or this.props.cardList loop, detect the icon, using:

const bankIcons = [{
    name: 'Citizens Bank',
    icon: CitizensBank
}]

const getIcon = (bankOrCardName) => {
    const icon = bankIcons.find((item) => item.name === bankOrCardName)
    return icon || defaultBankIcon
}

combinedPaymentMethods.push({
    type: MENU_ITEM,
    title: bankAccount.addressName,
    // eslint-disable-next-line
    description: formattedBankAccountNumber,
    icon: getIcon(card.cardName),
    onPress: e => this.props.onPress(e, bankAccount.bankAccountID),
    key: `bankAccount-${bankAccount.bankAccountID}`,
});

in the renderItem function add iconHeight and iconWidth props to make it bigger.

And here's the result:

I add the all bank icon with bank name  and we check condition
bank name compare all icon if this icon name equal to bank name or credit card bank name
this icon is set in createPaymentMethodList() in "/src/pages/settings/Payments/PaymentMethodList.js"
if does not match we use default bank icon or credit card icon

Hi everyone, as we mentioned in the description, there are lots of bank names in the list like americanexpress.com.uk and americanexpress.com.australia which should both map to the American Express Icon. Those can't be changed in the DB so we need to match in a different way than just straight ===, meaning that none of the proposed solutions will work.

@stitesExpensify cannot access banknames list
banklist.csv
bankaccountlist.csv

bankaccountlist (2).csv
banklist (3).csv
What about these?

Working @stitesExpensify

We can map bankNames and icon for icons we have.  We can create a separate file for this. Using the method getBankIcon we can retrieve the icon.

Proposal
@michaelhaxhiu we can do a implementation like shown below

More or else we need to map bankName to a respective resource, we can easily retrieve the same.

But the best way to handle this image should be available in API itself, URI pointing to a resource over like we have our profile pic in personalDetails.
From where do we get  bankAccount.additionalData. Is it a third-party integration?
addtionalData should have a logoURI, like it has bankName.
While we fetch bank account details, logoURI can be added in response in backEnd
And lazy load image here in client-side using logoURI.
@stitesExpensify

From where do we get bankAccount.additionalData. Is it a third-party integration?
addtionalData should have a logoURI, like it has bankName.

We get that data from a lot of different places both internal and external. A lot of it is legacy data too which makes it hard to go back and change. IMO we don't want to do a database change for this issue.

We can map bankNames and icon for icons we have. We can create a separate file for this.

Is there a reason you prefer this over the solution in the description? If we write a function to map all of these, then we could just write a function to map them on the fly right? This has the additional benefit that we are covered for all future bank account names that are not in our current list.

  Is there a reason you prefer this over the solution in the description?

We don't need the assets to be bundled with apps, because more than 90% of assets are useless for any normal user. It increases app size.

@stitesExpensify

We don't need the assets to be bundled with apps, because more than 90% of assets are useless for any normal user. It increases app size.

That makes sense, but there are 2 downsides to that IMO.

We would have to do a massive database migration to add an icon link to each bank account
The icons would not work if we are offline

Yes, we can do this.

Great, let's do it that way then.

@michaelhaxhiu can you create an upwork job and hire @Santhosh-Sellavel please? Thanks!

@stitesExpensify Are there any test accounts with test bank accounts or card details?

@stitesExpensify The Upwork job was posted 2 days ago, and is already linked in the GH body.
@Santhosh-Sellavel Can you please make a proposal on the Upwork job post, so I can hire you there? That's a required step on your part as a Contributor (more information in the Contributor Guidelines - also linked in the GH body).

Ah thanks Hax, my bad.

No problemo :)
On Fri, Aug 6, 2021 at 12:49 PM Brandon Stites @.***>
wrote:

Ah thanks Hax, my bad.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Expensify/App/issues/4398#issuecomment-894385172, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ADEYK4GEHKBSUJLOYCCSLR3T3QG7XANCNFSM5BPWZL6Q
.
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&utm_campaign=notification-email
.

--
Michael Haxhiu

@Santhosh-Sellavel is now hired on Upwork, we have takeoff 🚀

Got hired @stitesExpensify

@stitesExpensify I wrote a function to map bank names to assets-name.
There are two files here in the zip attached -> bankNames_assetMap.zip

uniqueBankNamewithasset

{
    'com.americanexpress': {bankName: 'com.americanexpress' , assetName: 'americanExpress' },
    'americanexpress.co.uk': {bankName: 'americanexpress.co.uk' , assetName: 'americanExpress'},
    .....
}

BankNamesGroupedByAssetName

{
   'americanexpress':  [
   'com.americanexpress': {bankName: 'com.americanexpress' , assetName: 'americanExpress' },
    'americanexpress.co.uk': {bankName: 'americanexpress.co.uk' , assetName: 'americanExpress'},
    ...]
    .....
}

Can I get some help with bank name validation? For few bank names, it looks more similar I find it hard whether both belong to the same parent organization. Example:Fidelity & Citizens Bank so need help with validating this mapping.

Hi Santhosh, What does your map function look like? I think that would help me decide what to do with the other banks.

@stitesExpensify

You can find the processcsv.js file inside the CSV_File.zip, which contains the function to map.
Extract and run npm install inside the folder.
node processcsv.js

Note, existing map function covers most of the cases. Common abstract names in banks cause problems.

@stitesExpensify  Did you get any chance to look into it?

Hi @Santhosh-Sellavel I just took a look. I'm not sure what you meant when you said Example:Fidelity & Citizens Bank so need help with validating this mapping. it looks like your mappings make sense to me?
Also, like we talked about we can just put the function getAssetName(bankName)  function direction into our codebase rather than creating mappings right? That makes more sense to me from a future-proof standpoint

@stitesExpensify
What's the help is?  The names look similar I don't whether they all come under the same parent bank or a different one.
I am confused because we might show the wrong icon.

Hi @stitesExpensify,
As discussed,

assets are added,
map function added,
And wired up function to pick up icon in paymentMethodList.js

Is this good so far?
Need to improve map functions for these two banks alone,

Fidelity
Citizens Bank

Thanks for that @Santhosh-Sellavel. I have some other internal priorities I need to focus on at the moment but I'll be back to help you out and review next week.

Okay, @stitesExpensify thanks for the FYI!

@stitesExpensify, @Santhosh-Sellavel Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

Reviewed

Moving this to weekly

@stitesExpensify we both missed something, Do we need to change the icon for Paypal?
If so please send me the icon. I'll update it

The paypal icon should be fine for now.

Adding a new var sounds good to me. I like iconExtraLarge.

Here's the new discover icon, much smaller!
Discover 4.svg.zip

Checking in on this one - how's it coming along so far @Santhosh-Sellavel?

@michaelhaxhiu PR is ready @stitesExpensify is busy with some internal priorities. You can check here https://github.com/Expensify/App/pull/4653

Considering the amount of time I spent on this issue, Requesting a reevaluation on compensation. Thanks!
@stitesExpensify @michaelhaxhiu

Hey y'all, just dropping in to note that https://github.com/Expensify/App/issues/5104 demonstrates that the PR for this issue did not work as expected. While it's not technically a regression, we should stay any payment for this issue until after https://github.com/Expensify/App/issues/5104 has been resolved.

Considering the amount of time I spent on this issue, Requesting a reevaluation on compensation. Thanks!

@Santhosh-Sellavel may I ask what amount you would consider fair for the time invested thus far?
Thanks for the update @roryabraham.

I disagree that this did not work as expected. The problem is how we are saving bank accounts. If the bankName is actually in the saved bank account data we show the icon, otherwise we show the default.
In the case Rory linked there is no bank account name saved, so the default bank icon is expected.

@michaelhaxhiu Thanks for considering the request! At least $100 more seems fair to me. If you feel otherwise, I am happy to settle with the agreed price itself.

We are reviewing the request internally, and I'll do my best to follow up today.

Thanks for being patient! I'll add a bonus of $100 as we agree with you, and appreciate your help in the repository as a contributor 😃.

Paid 🎬 .


Added support for version >= 8.0.0

The issue with using version 8 was that elasticsearch-certutil no longer generated a CA automatically. It is now a separate step in the setup. The GenerateCertificatesTask now generates a certificate authority when version 8 detected.
In addition version 8 also produces a slightly different warning message when JAVA_HOME is missing. The ClusterComposeTask ExecuteBinary now also ignores warning lines containing "using ES_JAVA_HOME".

Wow this is great and completely flew under my radar, apologies for getting to it so late.


orverflow of rotated img

I have a rotated image element , which wrapped by orverflow: hidden　div.
In brouser , the image will be rotated before cutting orverflowed part.
but html2canvas cut overflowed part before rotate obj.

jsfiddle example please?

I had the same error. Corrected as follows:
Line 1960:
var clip = (container.css ('overflow') === "hidden")? [container.borders.clip]: [];
Replace with
var clip = [];
I do not know what other problems it will cause, but my project works.


Set variables directly, don't use my_vars

Cleans up a few more instances where this pattern was being used.

LGTM other than question above


PLOTTING: add affine transform widget

We should consider adding this new widget from PyVista https://github.com/pyvista/pyvista/pull/4803

Just FYI, this was added in pyvista==0.42, we still have the 0.41 version due to the documentation.

Okay, no problem :) Once it's available we will bump it. We will also have to bump the minimum PyVista requirement to 0.42 in that case

Overview of this feature
What we want
We were looking for an affine transform that applies the transformations to all of the scene. We were looking to substitute the axis widgets that we already have in the corner for an interactable one to move all of the objects of the scene around.
What PyVista currently have
PyVista currently offers an affine transform widget, that is meant to be attached to a *particular actor. This allows to apply the affine transformations to this object in particular. Currently, you can not perform affine transformations to a list of actors, which is what we were looking for.
Conclusions
Since we cannot easily implement what we want with the current PyVista features, I think we should wait until this feature is implemented in PyVista to continue the development here.

Please open an issue on PyVista to see if they could implement an option to apply this widget to the entire scene. Thanks @AlejandroFernandezLuces!


As a user, I can email multiple students with one command.

Rationale
A user might want to email multiple students with the same email, thus this will make it more convenient.

Closing as minor feature is to be changed.


Document Overlay Width and Height set attribute

Additionally, new readable attributes to retrieve original graphics width and height without the size change.

Done (the meaning of these properties have changed since).


Solution for server side scheduled tasks

Tasks like:

push token cleanup
sending future-publish-time feed posts as push notifications

And fancy shit:

automatic feed posts and/or push notifications relative to certain events (ex, "tweet the players" reminder on match day eve, Prideraiser plug at scheduled kickoff time+45min during June)

Push token cleanup can be handled immediately as a callback, but we'll definitely need this for the other stuff.
We'll need to store any scheduling information in the database so that it can survive a dyno reset. You can use setTimeout() to run a timer at a set interval- maybe every five minutes. (Gate this behind a config flag so that beta servers aren't keeping their dynos spinning at all hours.) When the callback runs, it checks if there's any jobs that have elapsed, runs the ones that have, cleans them up, and moves on.
We really need to completely set up our beta infrastructure before getting too crazy with this one. I don't want to do user-facing things like push notifications on a five minute timer job only to discover that the cleanup logic is broken.

This was done as part of the news feed push and testing seems to have gone well. Any specific integration points or bug fixes will be filed as separate issues.


runtime: Darwin slow when using signals + int->float instructions

Split off from #37121
package bench1

import (
	"math"
	"testing"
)

const N = 64

func BenchmarkFast(b *testing.B) {
	var x, y, z [N]float32

	for i := 0; i < b.N; i++ {
		mulFast(&x, &y, &z)
	}
}

func mulFast(x, y, z *[N]float32) {
	for i := 0; i < N; i++ {
		z[i] = x[i] * y[i]
	}
}

func BenchmarkSlow(b *testing.B) {
	var z [N]float32
	var x, y [N]uint32

	for i := 0; i < b.N; i++ {
		mulSlow(&x, &y, &z)
	}
}

func mulSlow(x, y *[N]uint32, z *[N]float32) {
	for i := 0; i < N; i++ {
		z[i] = math.Float32frombits(x[i]) * math.Float32frombits(y[i])
	}
}

% ~/go1.12.9/bin/go test bench1_test.go -test.bench .\* -test.benchtime=10000000x
goos: darwin
goarch: amd64
BenchmarkFast-16    	10000000	        55.9 ns/op
BenchmarkSlow-16    	10000000	        61.1 ns/op
PASS
% ~/go1.12.9/bin/go test bench1_test.go -test.bench .\* -test.benchtime=10000000x -test.cpuprofile=cpu.prof
goos: darwin
goarch: amd64
BenchmarkFast-16    	10000000	        89.7 ns/op
BenchmarkSlow-16    	10000000	       223 ns/op
PASS

For some strange reason, code that includes int->float instructions runs a lot slower when profiling is on.
This bug is reproducible from at least 1.11.

@jyknight suggests lack of a vzeroupper, perhaps in the Darwin signal handler.

@cherrymui reports that gratuitously inserting the VZEROUPPER before the conversion instruction also works.  Wheeee!

@randall77 I tried also commenting out the "raise" line and leaving "vzeroupper" uncommented and the performance was somewhere in between "vzeroupper" being used and not (with raise still in there), which doesn't really make much sense to me. Might be a useful data point.

On our 1.11 builders, my C repro is ~14% slower with the VZEROUPPER commented out.
On 1.12, ~13% slower.
On 1.14, ~11% faster.
On 1.15, ~11% faster.
So for some reason this bug doesn't appear on the builders like it does on my desktop. I could imagine that some virtualization layer hides the bug, and the VZEROUPPER instruction has a cost.

I reported a bug to apple here.
We'll see if we get any traction on that.

@randall77, unfortunately your bug report to Apple seems to return a 404.

The link works fine for me. It is behind a login, though. Not sure if that would give you a 404 or not.

I did login and tried again but in vain

Anyways it is not a problem, was just checking up on this issue as I was re-triaging bugs that are in the Go1.15 milestone. Sorry for the noise :)

Do we think that there is anything to fix in Go here?

No, I think there's nothing left on our end.
The bug I linked to above now says:
Recent Similar Reports:Less than 10
Resolution:Potential fix identified - For a future OS update

Pretty vague, but at least something is happening.
Maybe when something is released, we can circle back and check the fix works, and then maybe remove our workaround (CL 219131) when the buggy versions of OSX become unsupported.
No need to keep the issue open, though.

Apple claims this was fixed in 10.15.6. Anyone want to verify? I'm still on 10.15.2.
(Just build and run the C code and see what happens.)

Apple claims this was fixed in 10.15.6. Anyone want to verify? I'm still on 10.15.2.
(Just build and run the C code and see what happens.)

Nothing happens:
$ time ./a.out
=====
JOB ./a.out
99%    cpu
1.97s real
1.96s user
0.00s sys

Try it with and without the VZEROUPPER in asm.s commented out. If it's fixed, there shouldn't be any performance difference between the two.

Try it with and without the VZEROUPPER in add.s commented out. If it's fixed, there shouldn't be any performance difference between the two.

Here's with VZEROUPPER commented out:
=====
JOB ./a.out
99%    cpu
1.88s real
1.88s user
0.00s sys

So it's still slightly faster than with VZEROUPPER commented (I posted above).

Ok, sounds fixed.
So once we stop supporting releases <10.15.6, we can get rid of the VZEROUPPER patch.
We need a way to ask googlebot to reopen issues triggered on a minimum supported OS level.

We need a way to ask googlebot to reopen issues triggered on a minimum supported OS level.

We don't have the ability to track minimum OS support yet, so the best alternative I can suggest for now is to open a new tracking issue.

@HenkPoley thinks this might have regressed in 10.15.7. See his comment in #41152.

Just for the record, I have no system to test this on, I don't run Go. Just gave a headsup that the issue in macOS that they forget VZEROUPPER themselves, seems to have re-appeared. I don't think Go need to do anything, except shift that 'remove VZEROUPPER patch once Darwin <10.15.6 is not supported #41152' to =<10.15.7

Right, sorry, it's not that there's any fix to do for this bug. We just need to re-evaluate the point at which the currently checked-in fix will be superfluous.

@randall77 Does this issue still need to be open, or is it enough that #41152 is open?
It's currently milestoned for Go 1.15, so if it stays open, that needs to update to a milestone that isn't in the past. If there's something different to do, it might be more clear to open a new issue and reference this one.

Yes, #41152 is all we need now.


Illegal characters inside response will cause fatal error in XmlObjectSerializer.php

When fetching a payments via API the response has illegal characters:
<creditcardpayment>
	<creditchargeinfo>
		<number>xxxxxxxxxxxx8005</number>
		<nameonacct>Lets Panic</nameonacct>
		<ccexpirymonth>12</ccexpirymonth>
		<ccexpiryyear>2017</ccexpiryyear>
		<postalcode>9999</postalcode>
	</creditchargeinfo>
</creditcardpayment>

Notice the weird symbol in nameonacct. This is illegal characer and results in an fatal error thrown by simplexml_load_string in XmlObjectSerializer. I know this is because legacy data, as I wasn't able to reproduce this with new entries in QB, but it needs to be fixed, because we are dealing with importing older datasets with this SDK.
Solution: implement XML sanitization. An example code snippet can be found from here: https://www.ryadel.com/en/php-skip-invalid-characters-utf-8-xml-file-string/

@siimtalts Please send in a PR if you are interested to fix it, I will have it reviewed and merged.

Opening up SDK for hacktoberfest contributions.

is the issue open?


Updated link to validation document

Updated link to validation document

@JohanFreelancer9 - kindly do the copy editor review for this PR. Thanks

@anwara-ms

looks good to me.

is it ready to be published today?

@anwara-ms - please commit my changes.

I just did. All looking good to publish?

Hi, this is still not published. Reminder- @KCCross


♿❗Breaking Issue - RTL Support❗🚑

This text

Most look like this:

Looks correct without that English word:

/duplicate #11770

@TylerLeonhardt
Come on. Such a big issue doesn't deserve to get closed. I understand that when a problem doesn't affect us, we just don't care about it. But here I'm asking you guys to help to solve this major problem. Please reopen the issue.
I'm available on Telegram https://t.me/babakfp to help you guys on this topic. Ask me your questions.
@alexdima (have a look at my explanation)
@HamzaAbdullahMoh
@chadidi
@danyeh (😑)
@Kalmuraee
@janbaltus (dude👍)
@Aminadav
@saibimajdi
@ahamidou
@mahrousfci
@eyalalonn
@elkebirmed
@kazemihabib
@atlanteh
@iddan
@kookma
@Parsoa
@athamzaabdullah (read the explanation in this comment, that's why this problem isn't a priority)
@urielha
@omidgolparvar (این مشکل هنوز حل نشده ولی تو احتمالا الان پدر شدی😂😂)
@akosyakov
@Javanmardi
@tomerm
@adir01
@amirbrans
@amer1616
@jb6
@nathangibson
@MSKhodadady (Telegram also have problems with RTL, but it's better than vsCode)
@KL13NT
@Kagetsuki
@VehpuS
@NotWearingPants
@rafidka
@lior5654 (2022 😂)
@TheEhsanSarshar (feel free to contact me on Telegram https://t.me/babakfp)
@AhmedElTabarani
@marktani
@ebraminio (۲۰۲۲ انگار نه انگار)
@michael-james
@sarmadka
@lwcvl
@drewpotter
@fireheart2008
@RaiKoHoff
@hpwamr
@zspitz
@avipars
@sixtyfive
@RexNext
@chromer030
@amiria703

@babakfp Why do you feel this issue isn't covered by #11770 ?

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues. See also our issue reporting guidelines.
Happy Coding!

But aren't you just adding it to the (not-to-do list)? Isn't it best to take time and work on it to fix it forever? It's obviously not great for you guys too to deal with the same issue again and again and again. Do JetBrains's products support RTL correctly? If it doesn't, it's a big win for vsCode. What about other editors? I'm on Telegram https://t.me/babakfp, I'll answer all of your questions, contact me anytime and I'll stay in contact as much as it takes to solve this problem.
@vscode-triage-bot

@babakfp Why do you feel this issue isn't covered by #11770 ?

As you can see, it's a big confusion:

@babakfp That confusion is cleared up in later comments.

Also, it's not all about the text being on the right side / starting from right to left

No, it's not. I would say that isn't even the main issue. There are actually a number of issues around this, e.g.:

RTL1 LTR RTL2 needs to reverse direction and read RTL2 LTR RTL1
Parentheses (and other pair characters) need to be visually reversed if they're surrounding RTL text
Sets of numbers should not reverse direction within RTL text

And what makes this all worse, is that VS Code has a lot of custom positioning around cursor/selection placement that has to handle all of this.
All of this is covered in various comments in that thread, and in linked issues.

And what makes this all worse, is that VS Code has a lot of custom positioning around cursor/selection placement that has to handle all of this.

That doesn't sound correct. Let's walk through with an example because if I read this tomorrow, I probably going to get confused😂. This is the text in Farsi/Persian:

If I understand it correctly, you are saying that if the second letter was in English, it should be placed at the cursor's first position. So it's going to be like this:

This isn't right because nothing about the input should change!. This is the correct example:

Same as how it works on the web. If I copy a mixed lang text like (سلام babakfp خوبی؟) from the vsCode and paste it somewhere on the web, it should look the same (and vice versa).

The biggest and breaking issue here is this:

This text

Most look like this:

(Not talking about the text being on the right side).

Parentheses (and other pair characters) need to be visually reversed if they're surrounding RTL text
Sets of numbers should not reverse direction within RTL text

Any visual examples?

@babakfp Why do you feel this issue isn't covered by #11770 ?

The #11770 issue It has become a basket that any problems related to RTL languages are putted into it
There may be various different problems but on the same topic.
Have you recorded the closed problems that may have different aspects of the problem?

The https://github.com/microsoft/vscode/issues/11770 issue It has become a basket that any problems related to RTL languages are putted into it

Yep. that's exactly what is happening.

@kieferrm
Can after 'Iteration Plan for January 2022 #139607' end, add #11770 in February's plan and try to solve some RTL problems?
It's not only about the display, there are side problems in the terminal or in the editor, but it was closed under the idea of that it is a duplicate

Maybe something like this for each line:
https://svelte.dev/repl/edf7fdef9634479b9d08064b4fad9b26?version=3.46.4
🤷♂
The same happens on Telegram:
https://user-images.githubusercontent.com/44144724/152657185-e90ae47b-de30-403e-b4de-7538734fc1e4.mp4

😐

@babakfp Thank you for looping me in. I agree that #11770 has a confusing history. As I understand it, the issue you're describing has to do with VS Code either detecting the base line direction automatically (per Unicode BiDi algorithm) or being able to set the direction.
#11770 does have some discussion of this, but the issues #65648, #65855, and #4994 are more concise and targeted. Those are all still open. Perhaps you'd want to continue the discussion there?
I am with you that I hope these issues get put into the pipeline and resolved soon!

@zspitz I appreciate the clarity you've brought to this over at #11770!

This issue is a disaster,
We should have separate issues for each problem and track each one on its own issue rather than mixing them in just one #11770

@TylerLeonhardt ?

Hi there @alexr00
Anyone bored to help fix this bug?
DM me in Telegram https://t.me/babakfp if you needed help

Hi there @alexr00 Anyone bored to help fix this bug? DM me in Telegram https://t.me/babakfp if you needed help

I'm sorry, you did a great job but can't you be a little more formal and talk about it professionally
I respect what you did, and you alerted us about it
But you have become completely random and always know about communicating with you on Telegram in a strange way. Why is this?

Hi @AhmedElTabarani
Thank you so much. Yes, I'm trying to let them know that this is a big problem with vsCode and it must get fixed as soon as possible. Unfortunately, no one cares about our problems. It's not even like a small problem for a small group of people, it's a big problem for probably millions of people.
I'm not the kind of person to talk about this kind of stuff in a professional way. As a user what I see is that they don't care about this problem and not caring about your users problems isn't professional.
Telegram is a global way of communicating with other people but I guess it may sound weird when I say it over and over again. My only intention is for this problem to get fixed, nothing more or else.
I gonna try to talk with YouTuber to make a video about this and then vsCode may decide to fix it🤷♂.
Thanks🌸🌸

@babakfp Thanks for pushing hard for this. I would like to report on it for the online magazine www.digitalorientalist.com. May I use the images you have posted here? Maybe you can contact me off GitHub - I can't immediately track you down but I think you should have no problem contacting me.

Thank you, everyone🌼🌼
@ForrestKnight
@developedbyed
@jamesqquick
@clementmihailescu
@benawad
Frying Pan ??
@hswolff
@shiffman Choo choo!

@TylerLeonhardt
Which team's responsibility this is?  It's not been fixed since 2016! HELLOOOOO?


ZeroShotGPTClassifier Error

I am running the example code:
from skllm.config import SKLLMConfig
import os

SKLLMConfig.set_openai_key(os.getenv("OPENAI_API_KEY"))
SKLLMConfig.set_openai_org(os.getenv("OpenAI-org"))

from skllm import ZeroShotGPTClassifier
from skllm.datasets import get_classification_dataset

X, _ = get_classification_dataset()

clf = ZeroShotGPTClassifier()
clf.fit(None, ["positive", "negative", "neutral"])
labels = clf.predict(X)

I get the following error:
  3%|▎         | 1/30 [00:09<04:21,  9.00s/it]Could not obtain the completion after 3 retries: `AttributeError :: module 'openai' has no attribute 'ChatCompletion'`
None
Could not extract the label from the completion: 'NoneType' object is not subscriptable
  3%|▎         | 1/30 [00:15<07:15, 15.00s/it]

It seems like OpenAI changed the api of the Python package. For now a quick solution would be to downgrade the OpenAI version to <=1.0.