Toggle special workspace has stopped working

Hyprland Version
Hyprland, built from branch main at commit b21644b61143de0835fef9c3fa69fbdd2553cdfa dirty
Bug or Regression?
Bug
Description
Hi. I'm using hyprland-nvidia-git on Arch and its been a few days since suddenly togglespecialworkspace has just stopped working. I can move windows to special workspace, but the keybinding for toggling to see the windows stopped working. I tried changing the keybindings, or run hyprctl dispatch togglespecialworkspace, but nothing seem to work.
I even tried with a fresh configuration (auto generated, with only adding keybinding for special workspace). Still nothing.
How to reproduce
use the keybinding to move window to special workspace:
bind = $Mod, space, movetoworkspace, specialworkspace
the window disappears. (goes to special workspace?)
then use keybinding to toggle it:
bind = ALT, Space, togglespecialworkspace
But nothing happens.
try:
hyprctl dispatch togglespecialworkspace
says ok, but still nothing happens
Crash reports, logs, images, videos
No response

special not specialworkspace

^


feat(breadcrumb): add breadcrumb component

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

[x] The commit message follows our
guidelines: https://github.com/goetzrobin/spartan/blob/main/CONTRIBUTING.md#-commit-message-guidelines
[x] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

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

Which package are you modifying?

[ ] accordion
[ ] alert
[ ] alert-dialog
[ ] aspect-ratio
[ ] avatar
[ ] badge
[ ] button
[x] breadcrumb
[ ] calendar
[ ] card
[ ] checkbox
[ ] collapsible
[ ] combobox
[ ] command
[ ] context-menu
[ ] data-table
[ ] date-picker
[ ] dialog
[ ] dropdown-menu
[ ] hover-card
[ ] icon
[ ] input
[ ] label
[ ] menubar
[ ] navigation-menu
[ ] pagination
[ ] popover
[ ] progress
[ ] radio-group
[ ] scroll-area
[ ] select
[ ] separator
[ ] sheet
[ ] skeleton
[ ] slider
[ ] sonner
[ ] spinner
[ ] switch
[ ] table
[ ] tabs
[ ] textarea
[ ] toast
[ ] toggle
[ ] tooltip
[ ] typography

What is the current behavior?

Closes #
What is the new behavior?
Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

https://github.com/spartan-ng/spartan/issues/459

I noticed one more difference between HlmBreadcrumbSeparatorComponent and BreadcrumbSeparator from shadcn/ui
The list item receives additional role and aria-hidden.
https://github.com/shadcn-ui/ui/blob/805ed4120a6a8ae6f6e9714cbd776e18eeba92c7/apps/www/registry/default/ui/breadcrumb.tsx#L75-L89

Maybe the HlmBreadcrumbSeparatorComponent renders the li with the additional properties and the markup would look like

			Home

-

-			<hlm-breadcrumb-separator />
-

+              <hlm-breadcrumb-separator />

			<hlm-breadcrumb-ellipsis />

Alternative would be to follow the HlmBreadcrumbEllipsisComponent pattern and use a span to apply role and aria-hidden. What do you think @dongphuong0905?

@marcjulian  your suggestion is my first solution for separator component, because I want to keep it same as Shadcn. But I decided to wrap hlm-breadcrumb-separator because ol should contain li tag only. Do you think is it fine if we have span as a child of ol?

I think you are correct, its best to always have a li contained in the ol.
I have another idea to adjust HlmBreadcrumbItemDirective and we can keep the current template markup.

@marcjulian It look nice. I think this is the only way to keep the template markup style and result after render same as Shadcn.
I will update my code

@marcjulian an idea popped into my head as i updated my code.
I will change the selector of HlmBreadcrumbSeparator like this:
import { Component, computed, input } from '@angular/core';
import { lucideChevronRight } from '@ng-icons/lucide';
import { hlm } from '@spartan-ng/ui-core';
import { HlmIconComponent, provideIcons } from '@spartan-ng/ui-icon-helm';
import { ClassValue } from 'clsx';

@Component({
        // Change the selector
	selector: '[hlmBreadcrumbSeparator]',
	standalone: true,
	imports: [HlmIconComponent],
	providers: [provideIcons({ lucideChevronRight })],
	host: {
		role: 'presentation',
		'[class]': '_computedClass()',
		'[attr.aria-hidden]': 'true',
	},
	template: `
      	<ng-content>
			<hlm-icon name="lucideChevronRight" class="h-3.5 w-3.5" />
		</ng-content>
  	`,
})
export class HlmBreadcrumbSeparatorComponent {
	public readonly userClass = input<ClassValue>('', { alias: 'class' });

	protected readonly _computedClass = computed(() => hlm('h-3.5', this.userClass()));
}

And the template markup will be like:

For case custom separator:

    <hlm-icon name="lucideSlash" class="h-4 w-4" />

How do you think about this approach?

Thats an even better solution. Just a question is h-3.5 needed on the li element?
Perhaps protected readonly _computedClass = computed(() => hlm(this.userClass())); is enough for HlmBreadcrumbSeparatorComponent

@marcjulian
I set h-3.5 because default of hlm-icon is inline-flex, so the separator won't be vertical centered

But now I found a solution to fix it, I will set the hlm-icon is flex, and also add [&>hlm-icon]:w-3.5 [&>hlm-icon]:h-3.5 instead of h-3.5 to make separator same as Shadcn.
Now the separator will like this:
import { Component, computed, input } from '@angular/core';
import { lucideChevronRight } from '@ng-icons/lucide';
import { hlm } from '@spartan-ng/ui-core';
import { HlmIconComponent, provideIcons } from '@spartan-ng/ui-icon-helm';
import { ClassValue } from 'clsx';

@Component({
	selector: '[hlmBreadcrumbSeparator]',
	standalone: true,
	imports: [HlmIconComponent],
	providers: [provideIcons({ lucideChevronRight })],
	host: {
		role: 'presentation',
		'[class]': '_computedClass()',
		'[attr.aria-hidden]': 'true',
	},
	template: `
      	        <ng-content>
			<hlm-icon name="lucideChevronRight" />
		</ng-content>
  	`,
})
export class HlmBreadcrumbSeparatorComponent {
	public readonly userClass = input<ClassValue>('', { alias: 'class' });

	protected readonly _computedClass = computed(() =>
		hlm('[&>hlm-icon]:w-3.5 [&>hlm-icon]:h-3.5 [&>hlm-icon]:flex', this.userClass()),
	);
}

And DOM will like this:

Result:

That looks good too me!

The breadcrumb component looks clean! @goetzrobin this looks good and uses a similar approach as the pagination component. Might be a breaking change because of the updated ng-icon package.

@marcjulian  @goetzrobin  I saw @ng-icon was updated to v 0.29.10 in latest main, so this PR will not contain any breaking change.

@dongphuong0905 there's a couple issues with linting that need to be addressed and for the commit message it just needs to start with lowercase. Let me know if you need help with this!

I can take care of it while merging!
But just in case you are curious you can use the following command: git rebase -i HEAD~3 where 3 is the number of commits you want to go back and then change the message in Vim

@goetzrobin  Thanks a lot 😄

Hey @dongphuong0905 I checked the code, I have one recommendation. For the seperator you are always providing the chevronIconRight. Maybe it make sense to create a brain component which is handling that dynamicly like
`import {
AfterContentInit,
contentChildren,
Directive,
ElementRef,
inject,
Injector,
ViewContainerRef,
} from '@angular/core';
import { provideIcons } from '@ng-icons/core';
import { lucideChevronRight } from '@ng-icons/lucide';
import { HlmIconComponent } from '@spartan-ng/ui-icon-helm';
@Directive({
selector: '[brnBreadcrumbSeparator]',
standalone: true,
host: {
role: 'presentation',
'[attr.aria-hidden]': 'true',
},
})
export class BrnBreadcrumbSeparatorDirective implements AfterContentInit {
private readonly _viewContainerRef = inject(ViewContainerRef);
private readonly _elementRef = inject(ElementRef);
protected _icon = contentChildren(HlmIconComponent);
ngAfterContentInit(): void {
	if (this._icon().length === 0) {
		const injector = Injector.create({
			providers: [provideIcons({ lucideChevronRight })],
		});
		const componentRef = this._viewContainerRef.createComponent(HlmIconComponent, {
			injector,
		});
		componentRef.setInput('name', 'lucideChevronRight');

		const dynamicElement = componentRef.location.nativeElement;
		this._elementRef.nativeElement.appendChild(dynamicElement);
	}
}

}
`
After that angular don't have to provide every time the icon and the hlm-icon in case that someone want to have custom seperator

Hi @MerlinMoos,
In separator, I used the lucideChevronRight as a fallback of <ng-content>. It means if we add a custom icon for separator, Angular won't render the lucideChevronRight.
This is the new feature of Angular v18 https://blog.angular.dev/angular-v18-is-now-available-e79d5ac0affe#2a2b
IMHO, I think code will be more simple and maintainable with this approach.
This is the screenshot of DOM when I use custom separator, It only have slash icon 😄

Hi @goetzrobin,
I created a new PR to replace this one to fix the commit lint: #499
You can merge the new PR and close this one. I think It can save your time 😄

PR #499 was merged. So I will close this PR


Minor doc update of installation using conda

I made a very minor update of documentation of installation using conda.  The conda package of compilers makes the installation step universal between macOS and linux. In addition, the MKL package is explicitly written in the list of installed packages, because it seems MKL lapack is most reliable at this moment for the dense solver. mkl-include may not be necessary but maybe useful to list it.

Thank you!


Default Ctrl-R command does not work when HISTFILE is unset

Category

[ ] Key bindings

OS (only sure about Linux)

[x] Linux
[ ] Mac OS X
[ ] Windows
[ ] Windows Subsystem for Linux
[ ] Etc.

Shell

[x] bash
[ ] zsh (works fine in zsh!)
[ ] fish

Hello,
Before anything, I'd like to thank all the maintainers for making such a cool project. It's useful and really fast!
On some of my machines, I like to call unset HISTFILE in either .bashrc or .zshrc. The default __fzf_history__ command doesn't seem to find any of my history and shows a disappointing 0/0 results. Everything works once I change the bind instruction in /usr/share/fzf/key-bindings.bash to
bind '"\C-r": "\C-ahistory | $(__fzfcmd)\C-j"'

The default Ctrl-R keybinding works just fine in zsh even when HISTFILE is unset.

Maybe it's because the default implementation runs history using command substitution on a subshell? Check if history and foo=$(history); echo "$foo" gives the same result.
Having said that, it works fine for me with or without HISTFILE.


Add option to use hostNetwork in K8s worker pod

This addresses https://github.com/Alluxio/alluxio/issues/11271
This change removes ALLUXIO_WORKER_CONTAINER_HOSTNAME when using hostNetwork. Under this setup the client side will talk to the worker via the node's network adapter, which is faster than resolving worker virtual IP.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/9114/
Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/9121/
Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/9124/
Test FAILed.

alluxio-bot, test this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/9133/
Test PASSed.


HIP 49: LoRaWAN Sub-region Max EIRP Limit

This proposal suggests adopting a LoRaWAN subregion config for max EIRP limit which will allow individual countries within an RF region i.e. AS923 to define max EIRP limit based on each country’s local regulation instead of a single max EIRP limit across the entire AS923 as a result of PoCv11.
Hope to hear everyone's feedback! Thank you! :)

Thanks for putting this together!
@lthiery @vihu @gradoj maybe you want to collaborate on this?

Country: Singapore (AS923-1)
Allowed Frequency band: 920-923 MHz
EIRP: 500mW/27dBm
Reference: IMDA TS SRD document ( https://www.imda.gov.sg/-/media/Imda/Files/Regulation-Licensing-and-Consultations/ICT-Standards/Telecommunication-Standards/Radio-Comms/IMDATSSRD.pdf )
Page: 15, Row 30b

Country: Malaysia (AS923-1)
Allowed Frequency Range: 919-924MHz ( Note: it is limited up to 924MHz)
EIRP: 500mW/27dBm
Reference: Technical Code (SHORT RANGE DEVICES - SPECIFICATIONS) Malaysian Communications & Multimedia Commission (MCMC)
Attcahced Document  ( page 36, Row 10 and 37)
Short-Range-Devices-Specification.pdf

Country: Taiwan (AS923-2)
Allowed Frequency band: 920-925 MHz
EIRP: 1W/30dBm (Indoor)
500mW/27dBm (Outdoor)
Reference: Low-power Radio-frequency Devices
Technical Regulations ( https://www.ncc.gov.tw/english/files/20081/LP0002 Low-power Radio-frequency Devices Technical Regulations.pdf )
Section <IP_ADDRESS> Page 34

Country; Thailand (AS923-1)
Allowed Frequency band: 920-925 MHz
EIRP: 500mW ( 27dBm)
Reference: NBTC certification doc ( attached screenshot of the spectrum allocation. did not attach the full document as it is in Thai Language)

_Country: Indonesia (AS923-2)
Allowed Frequency Range: 920-923 [Note the mandatory frequency of 923.2 and 923.4 are NOT allowed in Indonesia.]
Default mandatory Channels: 921.4 and 921.6 MHz  [Not 923.2 and 923.4]
Reference: https://lora-alliance.org/wp-content/uploads/2021/05/RP002-1.0.3-FINAL-1.pdf Page 21
EIRP: 400mW/26dBm
Source: Kementerian Komunikasi Dan Informatika republic Indonesia ( attached document)
Refer to Page 6 and 7 ( the original document in Indonesian Language )
PERDIRJEN SDPPI NO 3 TAHUN 2019 LPWA.pdf

Country: Vietnam ( AS923-2)
Allowed Frequency Range: 920-922.5MHz [Please note the range] [Refer to the attached document: Sorry its in Vietnamese language)
Default Frequency:  921.4 and 921.6MHz ( Reference: https://lora-alliance.org/wp-content/uploads/2021/05/RP002-1.0.3-FINAL-1.pdf Page 21)
EIRP:  500mW/27dBm Page 23 ( section <IP_ADDRESS>)
MIC.pdf

Country: Philippines: AS923-3
Allowed Frequency: 915 – 918 MHz (Page 16)
Default Freq: 916.6 and 916.8 MHz (page 21)
Reference:
https://lora-alliance.org/wp-content/uploads/2021/05/RP002-1.0.3-FINAL-1.pdf

This seems like an improvement to the network to me. Is there a difference between new regions and sub-regions? I assume sub-regions have the same channel plan but with a different EIRP limit. If it is decided to do this maybe they just be treated as whole new regions instead of adding a sub-region concept? Here is a summary of places that have been mentioned. Feel free to add to the list
https://docs.google.com/spreadsheets/d/17Ta-k97ciFYQ9oYfUYp7wJCQKNXjcEhte6gE6gunIjU/edit?usp=sharing

@gradoj thanks for the summary. I will try to update more soon. I think your subregion grouping is just fine. Will try to add other countries to fill up the table
Btw. Malaysia should be in sub AS923-1-27  band? Their cut off frequency is 924mhz. Not 925.

Malaysia should be in sub AS923-1-27 band?

latest regional parameters from semtech has Malaysia at AS923-1

anyone know why Semtech has the 16dBm EIRP in the regional parameters? it would be nice to know their reasoning on that. i'd guess to combine countries and minimize the number of regions but maybe there are other factors. For example, if sensors cannot transmit above that power limit legally it may not make sense for the gateways to be much stronger. In that case, even if it could be done legally, it may not make sense for us to increase these limits for poc. I'm starting to think this should be part of hip-45.

Malaysia should be in sub AS923-1-27 band?

latest regional parameters from semtech has Malaysia at AS923-1

Well tbh each country in Asia follows their own set of allocated Freq. Not necessarily they have to follow semtech or alliance. It is other way around. Else the local authorities might act on non compliance and revoke the type approval certificate.

anyone know why Semtech has the 16dBm EIRP in the regional parameters? it would be nice to know their reasoning on that. i'd guess to combine countries and minimize the number of regions but maybe there are other factors. For example, if sensors cannot transmit above that power limit legally it may not make sense for the gateways to be much stronger. In that case, even if it could be done legally, it may not make sense for us to increase these limits for poc. I'm starting to think this should be part of hip-45.

If I'm not mistaken, it says the word "default" as 16dbm. My interpretation is not an enforcement. Cause ultimately enforcement authorities are local govt.

Not sure where you are on the "should PoC represent real-world coverage" discussion, but in case you lean towards yes (I'm not saying you need to), the following table of existing LoRa device chips might be useful:

Chip
Max output power
Current at max power

LR1110
22 dBm
118 mA

SX1276/77/78/79
20 dBm
120 mA

SX1261/2
22 dBm
118 mA

Country: Vietnam ( AS923-2) Allowed Frequency Range: 920-922.5MHz [Please note the range] [Refer to the attached document: Sorry its in Vietnamese language) Default Frequency: 921.4 and 921.6MHz ( Reference: https://lora-alliance.org/wp-content/uploads/2021/05/RP002-1.0.3-FINAL-1.pdf Page 21) EIRP: 500mW/27dBm Page 23 ( section <IP_ADDRESS>) MIC.pdf

Hi, judging from your document, this is still a drafting document. The last that I check with some legal documents, if your device has EIRP higher than 25mW (for the AS923 frequency bands), you will need to ask for a certificate from the government to operate.
There is also translated summary/documents by legal companies in VN as shown in this link
I recalled they said there is some new legal documents in effect from 12/2021 from frequency regulators in VN. Will double check this again.

Country: Vietnam ( AS923-2) Allowed Frequency Range: 920-922.5MHz [Please note the range] [Refer to the attached document: Sorry its in Vietnamese language) Default Frequency: 921.4 and 921.6MHz ( Reference: https://lora-alliance.org/wp-content/uploads/2021/05/RP002-1.0.3-FINAL-1.pdf Page 21) EIRP: 500mW/27dBm Page 23 ( section <IP_ADDRESS>) MIC.pdf

Hi, judging from your document, this is still a drafting document. The last that I check with some legal documents, if your device has EIRP higher than 25mW (for the AS923 frequency bands), you will need to ask for a certificate from the government to operate.
There is also translated summary/documents by legal companies in VN as shown in this link
I recalled they said there is some new legal documents in effect from 12/2021 from frequency regulators in VN. Will double check this again.

Below is the last updated published regulation :
https://mic.gov.vn/Upload_Moi/VanBan/38TT.PDF

Country: Vietnam ( AS923-2) Allowed Frequency Range: 920-922.5MHz [Please note the range] [Refer to the attached document: Sorry its in Vietnamese language) Default Frequency: 921.4 and 921.6MHz ( Reference: https://lora-alliance.org/wp-content/uploads/2021/05/RP002-1.0.3-FINAL-1.pdf Page 21) EIRP: 500mW/27dBm Page 23 ( section <IP_ADDRESS>) MIC.pdf

Hi, judging from your document, this is still a drafting document. The last that I check with some legal documents, if your device has EIRP higher than 25mW (for the AS923 frequency bands), you will need to ask for a certificate from the government to operate.
There is also translated summary/documents by legal companies in VN as shown in this link
I recalled they said there is some new legal documents in effect from 12/2021 from frequency regulators in VN. Will double check this again.

Below is the last updated published regulation : https://mic.gov.vn/Upload_Moi/VanBan/38TT.PDF

Hi thanks, I will have a read on this. This might just be about national standard on LPWAN but they don't mention operating regulations
I was referring to this document. You can check page 48, Phụ Lục 19 (annex 19). This annex said that they will waive the need for you to seek operating certificate if your LPWAN device with 920-923Mhz has <25mW ERP.

Well tbh each country in Asia follows their own set of allocated Freq. Not necessarily they have to follow semtech or alliance. They follow the AS923 as a standard but define their own set of Freq So, It is other way around. Else the local authorities might act on non compliance and revoke the type approval certificate.

Technically, every product SKU needs a type approval. This is simplified by using a certified module (e.g. from Semtech or others) rather than the chip (from Semtech only). BUT, use of a certified module does not officially alleviate the need for final testing and approval, though some products do skip this step when using a certified module.
This is further complicated or explained even, because various countries may use radar, defense, or civilian utility radio systems from differing sources that impose into the ISS band normally used for that specific region - making a sub channel limitation required - or worse, some areas don't have an auto ISS allowance and all operation must be ok'd by government (yeah, forget that for the the casual user).
This HIP then is more useful for manufacturers who want to provide specific SKUs for otherwise not addressed jurisdictions.

Country: Vietnam ( AS923-2) Allowed Frequency Range: 920-922.5MHz [Please note the range] [Refer to the attached document: Sorry its in Vietnamese language) Default Frequency: 921.4 and 921.6MHz ( Reference: https://lora-alliance.org/wp-content/uploads/2021/05/RP002-1.0.3-FINAL-1.pdf Page 21) EIRP: 500mW/27dBm Page 23 ( section <IP_ADDRESS>) MIC.pdf

Hi, judging from your document, this is still a drafting document. The last that I check with some legal documents, if your device has EIRP higher than 25mW (for the AS923 frequency bands), you will need to ask for a certificate from the government to operate.
There is also translated summary/documents by legal companies in VN as shown in this link
I recalled they said there is some new legal documents in effect from 12/2021 from frequency regulators in VN. Will double check this again.

Below is the last updated published regulation : https://mic.gov.vn/Upload_Moi/VanBan/38TT.PDF

Hi thanks, I will have a read on this. This might just be about national standard on LPWAN devices (for manufacturers who want to sell products in Vietnam, which will need to go through testing and approval by the govt agency) but they don't mention operating regulations
I was referring to this document. You can check page 48, Phụ Lục 19 (annex 19). This annex said that they will waive the need for end users' operating license if your LPWAN device with 920-923Mhz has <25mW ERP. This document is recently issued and currently in effect
English version (translated by a third-party legal company) is also here for ease of discussion. Apologise for the mess in our regulatory system

Seems in line. The "end users' operating license" is the person buying and setting up the Helium hotspot. So, a manufacturer selling there would still need testing to prove that their device meets the EIRP as well as other RF envelope requirements.

Seems in line. The "end users' operating license" is the person buying and setting up the Helium hotspot. So, a manufacturer selling there would still need testing to prove that their device meets the EIRP as well as other RF envelope requirements.

Yes, I think we should look at the perspective of hotspot owner here to help expand our network further. Also getting a user license in certain country, like my one is really a pain.

Country: Thailand
Freq: 920-925Mhz
Max EIRP  4 W  Allow to use but need Installation License from NBTC
50mW-500mW EIRP:  Free to use if it is passed Type Approval
Max 50mW: Free to use if it is passed SDOC.
Reference: https://bit.ly/3qizc0a

I've asked about this issues (both regarding differences in freq usage in as923 country and also the max eirp for as923), but it's been 2 months now i believe, and seems we're starting from scratch again.
Now after POCv11 is implemented, we have seen the beaconing/witnessing activity has been suffering a lot in AS923 countries. The distance of the beacon gets shorter. Tx power has been reduced to 16dbm seen from the JSON data from various brands of hotspots deployed in AS923 countries.
Now with this open issue (again), now we can see also that it turns out the freq being implemented by Helium for some AS923 countries are not conforming with the Govt regulation in Asia. How can this be?
Please speed up this process as we don't want the hotspots to be confiscated by the Authority for breaking the regulation on Frequency utilization.
So to summarize this issue with Helium in AS923:

Wrong Frequency usage vs Govt regulated freq for LORA
Under Performing hotspots/gateway due to the wrong reference data by Helium (supposedly referring to the reference document issued by each Government from the beginning)

I've asked about this issues (both regarding differences in freq usage in as923 country and also the max eirp for as923), but it's been 2 months now i believe, and seems we're starting from scratch again.
Now after POCv11 is implemented, we have seen the beaconing/witnessing activity has been suffering a lot in AS923 countries. The distance of the beacon gets shorter. Tx power has been reduced to 16dbm seen from the JSON data from various brands of hotspots deployed in AS923 countries.
Now with this open issue (again), now we can see also that it turns out the freq being implemented by Helium for some AS923 countries are not conforming with the Govt regulation in Asia. How can this be?
Please speed up this process as we don't want the hotspots to be confiscated by the Authority for breaking the regulation on Frequency utilization.
So to summarize this issue with Helium in AS923:

Wrong Frequency usage vs Govt regulated freq for LORA
Under Performing hotspots/gateway due to the wrong reference data by Helium (supposedly referring to the reference document issued by each Government from the beginning)

@ubiru I understand that you raise the issues way before, that's why I credited you as part of the author (was trying to contact you on discord). This HIP is directed to address the Tx power, you can read the commit if you have not.
Regarding the issue with Helium in AS923, the first point can be addressed with the help of HIP 45 and for 2nd point, we should address this in HIP 49.

I've asked about this issues (both regarding differences in freq usage in as923 country and also the max eirp for as923), but it's been 2 months now i believe, and seems we're starting from scratch again.
Now after POCv11 is implemented, we have seen the beaconing/witnessing activity has been suffering a lot in AS923 countries. The distance of the beacon gets shorter. Tx power has been reduced to 16dbm seen from the JSON data from various brands of hotspots deployed in AS923 countries.
Now with this open issue (again), now we can see also that it turns out the freq being implemented by Helium for some AS923 countries are not conforming with the Govt regulation in Asia. How can this be?
Please speed up this process as we don't want the hotspots to be confiscated by the Authority for breaking the regulation on Frequency utilization.
So to summarize this issue with Helium in AS923:

Wrong Frequency usage vs Govt regulated freq for LORA
Under Performing hotspots/gateway due to the wrong reference data by Helium (supposedly referring to the reference document issued by each Government from the beginning)

@ubiru I understand that you raise the issues way before, that's why I credited you as part of the author (was trying to contact you on discord). This HIP is directed to address the Tx power, you can read the commit if you have not.
Regarding the issue with Helium in AS923, the first point can be addressed with the help of HIP 45 and for 2nd point, we should address this in HIP 49.

i just wished that when helium decided to keep delaying the poc11 at that time, there was enough time for them to fix the issues with AS923. But they did nothing and now it's kinda we're talking from scratch again with them. sighhhhh
it's a known problem from the beginning if only they look at the govt regulation issued by each country instead of just looking at a piece of document from the lora-alliance. if only....

For very dense city states like Singapore and Taiwan (arguably overcrowded with hotspots already), might the reduced transmission power actually help level the playing field and even out rewards? Previously, those who had the benefit of high rise access (which confers natural line of sight advantage) were double dipping with high gain antennas to extend range.
Now that everyone is effectively limited to 3-4dbi antenna range there should be more opportunities for everyone including newcomers?
Getting the correct frequency (mentioned under HIP45), and tackling spoofers (which I thought was what PoCv11 was laying the foundation for) seem to be more pressing issues.

For very dense city states like Singapore and Taiwan (arguably overcrowded with hotspots already), might the reduced transmission power actually help level the playing field and even out rewards? Previously, those who had the benefit of high rise access (which confers natural line of sight advantage) were double dipping with high gain antennas to extend range. Now that everyone is effectively limited to 3-4dbi antenna range there should be more opportunities for everyone including newcomers? Getting the correct frequency (mentioned under HIP45), and tackling spoofers (which I thought was what PoCv11 was laying the foundation for) seem to be more pressing issues.

@MavJoe405 Im not sure whether you been checking around these areas but I do not think that the reduced transmission power level the playing field at all. Given the same antenna set-ups,

Miners who stay on higher floors are still earning more than the others, naturally because they have better LOS and fewer interferences. They can witness better and also see those on lower floors also
Miners staying on lower floors are visibly having fewer earnings, due to poorer LOS and more interferences. Their hope of being witnessed depends on people nearer to them and also miners on higher floors who can see them better.

And in fact, this HIP is to tackle countries been wrongly restricted

eg. been restricted to 16dBm max limit although the country's limit is at 27dBm.

Well tbh each country in Asia follows their own set of allocated Freq. Not necessarily they have to follow semtech or alliance. > They follow the AS923 as a standard but define their own set of Freq
So, It is other way around. Else the local authorities might act on non compliance and revoke the type approval certificate.

Yes, i understand each country follows their own regulations. Semtech has grouped the countries into a reasonable number of channel plans based on each countries regulations. In doing so there may have be some compromises like max eirp but the advantage is sensor manufacturers do not need to worry about each country they can comply with the LoRaWAN Standard and set the lorawan region and know the sensor is compliant with regulations. in my opinion POC is supposed to be an analog to sensor performance so i wouldn't approve this hip unless there was an official LoRaWAN region or subregion defined. If there is no official sub/region there will never be any sensors built that take advantage of the higher power. The regulations are complicated and as you can see from the chaotic discussion here i don't think it is the right place.  I vote to move this to hip45.

Well tbh each country in Asia follows their own set of allocated Freq. Not necessarily they have to follow semtech or alliance. > They follow the AS923 as a standard but define their own set of Freq
So, It is other way around. Else the local authorities might act on non compliance and revoke the type approval certificate.

Yes, i understand each country follows their own regulations. Semtech has grouped the countries into a reasonable number of channel plans based on each countries regulations. In doing so there may have be some compromises like max eirp but the advantage is sensor manufacturers do not need to worry about each country they can comply with the LoRaWAN Standard and set the lorawan region and know the sensor is compliant with regulations. in my opinion POC is supposed to be an analog to sensor performance so i wouldn't approve this hip unless there was an official LoRaWAN region or subregion defined. If there is no official sub/region there will never be any sensors built that take advantage of the higher power. The regulations are complicated and as you can see from the chaotic discussion here i don't think it is the right place. I vote to move this to hip45.

Hi..I thought we are talking about the EIRP of hotspots not sensors . Each country has a different regulation of EIRP of hotspot and sensors. Like in Singapore the max eirp allowed for a gateway is 500mw and for sensors it is 100mw. Not sure where is the sensor EIRP coming to the picture here.
Each hotspot vendor has to go through country specific test for compliance and same for sensor manufacturers. They are totally 2 different things.
Apologies if I got it wrong.

You got it right. There is a connection though: PoC. PoC can be a way to simulate device coverage, to incentivize growing a valuable network that (in time) will get revenue from device traffic.
However, there is not a clear community consensus whether PoC should reflect real-world coverage. I think it should, because that’s an efficient way to build a valuable network. But that’s my personal opinion.

If PoC can be a way to simulate device coverage, PoC can’t override the local regulation. That would be illegal for a country if PoC wants to increase the Tx power of a sensor beyond the allowed limit in the country.
In a nutshell, what we have asked for is :

Change the EIRP according to the country specification and I think we have provided enough documentation of EIRP on our support.
Correct the frequency range in countries like Indonesia, Malaysia, Vietnam and Philippines.  Unless we want the regulators to come down and seize all. This was the case in Thailand, when some one imported US 915 hardware and used in Thailand.

And for sensors there should be a separate similar discussion to follow according to the country specific regulation.
Semtech and Lora Alliance gives a guideline for spectrum allocation. But they are not the enforcing authority. We have seen in the past, the regional parameter was changed many times when a country has changed their frequency allocation. Best example is AS923-2: it was done when Indonesia and Vietnam changed their LPWAN allowed band.
So, my 2 cents, follow the respect local  regulation to be legal in the country. Otherwise, we might have a problem with the authorities.
From: Mikael Falkvidd @.>
Sent: Thursday, 23 December 2021 5:00 pm
To: helium/HIP @.>
Cc: Joyanta MAJUMDER @.>; Comment @.>
Subject: Re: [helium/HIP] HIP 49: LoRaWAN Sub-region Max EIRP Limit (PR #325)
You got it right. There is a connection though: PoC. PoC can be a way to simulate device coverage, to incentivize growing a valuable network that (in time) will get revenue from device traffic.
However, there is not a clear community consensus whether PoC should reflect real-world coverage. I think it should, because that’s an efficient way to build a valuable network. But that’s my personal opinion.
—
Reply to this email directly, view it on GitHubhttps://github.com/helium/HIP/pull/325#issuecomment-1000146607, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AXAQ56KPOFCPFOJ7KA2TOGLUSLQIVANCNFSM5KSXC3HA.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you commented.Message ID<EMAIL_ADDRESS>

If PoC can be a way to simulate device coverage, PoC can’t override the local regulation.

Yes, PoC needs to follow local regulation. But if PoC is meant to simulate device coverage, maybe PoC should never use more than 22dBm, even if local regulation allows gateways to use more. (22dBm since that's currently the highest output for a device LoRa chip provied by Semtech.)

Country: Philippines: AS923-3 Allowed Frequency: 915 – 918 MHz (Page 16) Default Freq: 916.6 and 916.8 MHz (page 21) Reference: https://lora-alliance.org/wp-content/uploads/2021/05/RP002-1.0.3-FINAL-1.pdf

EIRP: 250mW/24dBm
Reference: MC-09-09-2003.pdf Page 1 Section 2.2
Ammended MC_03-08-2013.pdf to include 915Mhz to 918Mhz band

If PoC can be a way to simulate device coverage, PoC can’t override the local regulation.

Yes, PoC needs to follow local regulation. But if PoC is meant to simulate device coverage, maybe PoC should never use more than 22dBm, even if local regulation allows gateways to use more. (22dBm since that's currently the highest output for a device LoRa chip provied by Semtech.)

You are referring to the max tx power by Semtech chip. Hardware specifications can change.
Are you suggesting to implement max EIRP based on that?
If so, try raising a new HIP for that to be implemented globally, it'd be interesting to see the feedback and reaction on that one.
Max EIRP takes into consideration of the antenna gain as well then reduce the tx power to ensure the max EIRP defined via the Helium blockchain is met.
The logical thing to do would be to ensure the max EIRP limits coincides with local regulation for optimal performance in different countries.

If PoC can be a way to simulate device coverage, PoC can’t override the local regulation.

Yes, PoC needs to follow local regulation. But if PoC is meant to simulate device coverage, maybe PoC should never use more than 22dBm, even if local regulation allows gateways to use more. (22dBm since that's currently the highest output for a device LoRa chip provied by Semtech.)

That's Max output power of the chip.. not the EIRP.. vendors can use PA and increase the TX power at the antenna port and upon adding the antenna higher EIRP can be achieved without any issue. not sure why we have to be in 22dBm. May be I am missing something?

If so, try raising a new HIP for that to be implemented globally, it'd be interesting to see the feedback and reaction on that one.

We did 6 months ago and the feedback was pretty negative. My (somewhat cynical) analysis is that anything that would have a negative effect on PoC earnings in the short term will be rejected by the community. People join Helium to earn money, not to build a network. That's why I'm saying that there is not a clear community consensus whether PoC should reflect real-world coverage.
If PoC is not intended to reflect real-world device coverage, there is no reason to limit PoC to 22dBm.

vendors can use PA and increase the TX power at the antenna port

Yes they could but I am not aware of any device on the market that does use an additional PA (the numbers I quoted already include the PA built into the Semtech chips).

and upon adding the antenna higher EIRP can be achieved without any issue.

For devices that are installed in a fixed location, with a fixed placement of gateways, yes it is possible. But hotspots move (especially with everyone moving their hotspots to fake locations to increase their transmit scale). A directional antenna is only useful when it is pointed towards a receiver. That's why (almost) all LoRaWAN devices on the market use omnidirectional antennas with low directivity.

@mfalkvidd sorry, I was talking about hotspots, not devices. So ya you are right about the PA part in end devices.

If so, try raising a new HIP for that to be implemented globally, it'd be interesting to see the feedback and reaction on that one.

We did 6 months ago and the feedback was pretty negative. My (somewhat cynical) analysis is that anything that would have a negative effect on PoC earnings in the short term will be rejected by the community. People join Helium to earn money, not to build a network. That's why I'm saying that there is not a clear community consensus whether PoC should reflect real-world coverage.
If PoC is not intended to reflect real-world device coverage, there is no reason to limit PoC to 22dBm.

vendors can use PA and increase the TX power at the antenna port

Yes they could but I am not aware of any device on the market that does use an additional PA (the numbers I quoted already include the PA built into the Semtech chips).

and upon adding the antenna higher EIRP can be achieved without any issue.

For devices that are installed in a fixed location, with a fixed placement of gateways, yes it is possible. But hotspots move (especially with everyone moving their hotspots to fake locations to increase their transmit scale). A directional antenna is only useful when it is pointed towards a receiver. That's why (almost) all LoRaWAN devices on the market use omnidirectional antennas with low directivity.

@mfalkvidd before we go on and discuss more. Let's do some clarification.
I believe that @joyanta-klk @resyncX @ubiru are talking about hotspots owner that affected by having reduced transmission power although their country allows higher limits. You can read the commit and check out the affected stallholders.

Sorry, press the wrong button just now.

@beaky98 sorry for being unclear.
What I mean is that if PoC is supposed to simulate real-world coverage for devices (to stimulate long-term growth), then the extra tx power allowed by hotspots in some regions is useless, because devices would not be able to use that extra tx power anyway. Using higher power would mean that PoC simulates something else than device coverage.
But if PoC is not supposed to simulate real-world coverage for devices, then we should probably use the maximum tx power allowed by law.

@beaky98 sorry for being unclear.
What I mean is that if PoC is supposed to simulate real-world coverage for devices (to stimulate long-term growth), then the extra tx power allowed by hotspots in some regions is useless, because devices would not be able to use that extra tx power anyway. Using higher power would mean that PoC simulates something else than device coverage.
But if PoC is not supposed to simulate real-world coverage for devices, then we should probably use the maximum tx power allowed by law.

in my understanding, LORA gateway is a passive device when working with sensors. It's only being active in POC activities.
I imagine if the lora gateway is set at the same tx power as the sensors, then would we need double the number of gateway (in helium case is called hotspot)? Cause then in order for POC activities to work (beacons getting witnessed), then the other gateway would need to be in the max distance as a sensor would be from the first gateway.
If the gateway's tx power is bigger than the sensors', then the sensors can be located in the edge (but crossing coverage) of the 2 gateways and it can still connect to either gateway.
And the idea of gateway tx power is bigger than sensor i believe due to the gateway quantities would be much less than the sensors and gateway is supposed to be located (or at least the antenna) in much higher ground compared to the sensors which may be so closed to us, so the radiation/interference from the gateway is limited.

We did 6 months ago and the feedback was pretty negative. My (somewhat cynical) analysis is that anything that would have a negative effect on PoC earnings in the short term will be rejected by the community. People join Helium to earn money, not to build a network. That's why I'm saying that there is not a clear community consensus whether PoC should reflect real-world coverage.

I guess then it's been answered 6 months ago.
So let's move back on to what we are trying to address here.

This seems like an improvement to the network to me. Is there a difference between new regions and sub-regions? I assume sub-regions have the same channel plan but with a different EIRP limit. If it is decided to do this maybe they just be treated as whole new regions instead of adding a sub-region concept? Here is a summary of places that have been mentioned. Feel free to add to the list
https://docs.google.com/spreadsheets/d/17Ta-k97ciFYQ9oYfUYp7wJCQKNXjcEhte6gE6gunIjU/edit?usp=sharing

We think this is the way to go and close it ..:)

Semtech and Lora Alliance gives a guideline for spectrum allocation. But they are not the enforcing authority. We have seen in the past, the regional parameter was changed many times when a country has changed their frequency allocation. Best example is AS923-2: it was done when Indonesia and Vietnam changed their LPWAN allowed band.

Helium follows the LoRaWAN standards. Semtech created the standard to follow the regulations in all countries. If a country changes their spectrum or rules the standard will change to adopt it. If any parameter is incorrect in the standard including the max EIRP it should be taken up with HIP45 to change the standard(as some limitations intentional to limit the number of channel plans). I actually think you are wrong saying all AS923 frequencies in Asia are incorrect.
I as well believe POC should roughly simulate sensor coverage. Yes, we are talking about fixed installed hotspots but if their sensors can only transmit at a lower power then i am not in favor on changing the max eirp.
Again: we are all talking about hotspots, Semtech created a Standard. That standard is designed to follow all country's regulatory rules. If you want to change the Standard to improve performance legally in a country then it should be brought up with HIP45

@abhay can you please help us out here? It seems like we are going about this all over again in loops..

I never said not to do it. I said you shouldn't just change it and ignore the standard because if new regions are not added sensors will never be able to take advantage of what you guys are advocating for. If sensors cannot take advantage of the change then there is no point - as Poc is an analog for sensor coverage

Semtech and Lora Alliance gives a guideline for spectrum allocation. But they are not the enforcing authority. We have seen in the past, the regional parameter was changed many times when a country has changed their frequency allocation. Best example is AS923-2: it was done when Indonesia and Vietnam changed their LPWAN allowed band.

Helium follows the LoRaWAN standards. Semtech created the standard to follow the regulations in all countries. If a country changes their spectrum or rules the standard will change to adopt it. If any parameter is incorrect in the standard including the max EIRP it should be taken up with HIP45 to change the standard(as some limitations intentional to limit the number of channel plans). I actually think you are wrong saying all AS923 frequencies in Asia are incorrect.
I as well believe POC should roughly simulate sensor coverage. Yes, we are talking about fixed installed hotspots but if their sensors can only transmit at a lower power then i am not in favor on changing the max eirp.
Again: we are all talking about hotspots, Semtech created a Standard. That standard is designed to follow all country's regulatory rules. If you want to change the Standard to improve performance legally in a country then it should be brought up with HIP45

If LoraWAN regional parameters are followed, in that case, why the default uplink frequencies in AS923-2 and 923-3 are not according to the lorawan regional parameters again my point is not only the EIRP.. we are risking the helium hotspot investors in legal issues with wrong frequencies.
Also, LoRaWAN regional parameter says default EIRP as 16dBm, not MAXIMUM. Maximum is regulated by country. So they are just leaving the EIRP as minimum default and let the countries to decide on maximum.

This is not supposed to be about what anyone's thinking. But it's about following what's been regulated. If for these past few months people incl. Helium team side been talking about POCv11 is made also for complying regulation, then why do we need to argue about this? We need the action, not the long discussion. Don't make this issue and also the HIP to cover this issue becoming something forgotten like last time and the just be closed after that long period of nothing.

It actually said 'default maximum' whatever that means.
Please be very specific: what channels are incorrect in 923 and in which country?

Semtech and Lora Alliance gives a guideline for spectrum allocation. But they are not the enforcing authority. We have seen in the past, the regional parameter was changed many times when a country has changed their frequency allocation. Best example is AS923-2: it was done when Indonesia and Vietnam changed their LPWAN allowed band.

Helium follows the LoRaWAN standards. Semtech created the standard to follow the regulations in all countries. If a country changes their spectrum or rules the standard will change to adopt it. If any parameter is incorrect in the standard including the max EIRP it should be taken up with HIP45 to change the standard(as some limitations intentional to limit the number of channel plans). I actually think you are wrong saying all AS923 frequencies in Asia are incorrect.
I as well believe POC should roughly simulate sensor coverage. Yes, we are talking about fixed installed hotspots but if their sensors can only transmit at a lower power then i am not in favor on changing the max eirp.
Again: we are all talking about hotspots, Semtech created a Standard. That standard is designed to follow all country's regulatory rules. If you want to change the Standard to improve performance legally in a country then it should be brought up with HIP45

If LoraWAN regional parameters are followed, in that case, why the default uplink frequencies in AS923-2 and 923-3 are not according to the lorawan regional parameters? again my point is not only the EIRP.. we are risking the helium hotspot investors in legal issues with wrong frequencies.
Also, LoRaWAN regional parameter says default EIRP as 16dBm, not MAXIMUM. Maximum is regulated by country. So they are just leaving the EIRP as minimum default and let the countries to decide on maximum.

Also, about the frequency, LoRAWAN regional parameter says AS923-1 is from 915-928 Mhz? so why didn't helium allow the entire range in AS923-1? there must have been a rationale behind this that helium did not allow to use the entire range.
about wrong frequency, what I was pointing is the uplink frequencies in AS923-2 are wrong in helium. in AS923-2 it is 921.4 and .6 NOT 923.2 and 923.6 .. which is clearly defined in regional parameters.

It actually said 'default maximum' whatever that means.
Please be very specific: what channels are incorrect in 923 and in which country?

i was very specific in the first post where I have mentioned the incorrect uplink frequencies.

about wrong frequency, what I was pointing is the uplink frequencies in AS923-2 are wrong in helium. in AS923-2 it is 921.4 and .6 NOT 923.2 and 923.6 .. which is clearly defined in regional parameters

If so, why not just create a ticket? I don't see how it is relevant to this discussion

that's fine to create a ticket. but going around the circle is risking the hotspot investors to be in legal issues in different countries... that's what I was trying to point. EIRP is not a legal issue.. but transmitting out of the allowed band is. that was all I was trying to say.

I never said not to do it. I said you shouldn't just change it and ignore the standard because if new regions are not added sensors will never be able to take advantage of what you guys are advocating for. If sensors cannot take advantage of the change then there is no point - as Poc is an analog for sensor coverage

if poc is analog for sensor coverage, then when you deploy it like a bts, then it would have so much blank spot on the network coverage. Pls read my comment above

When a hotspot owner got issues with the govt on the freq matter, his investment on the device will go down the toilet. Govt will seize the hotspot from the owner.
But owner has no control over the freq setup of the hotspot, so owner then may take a lawsuit or a class action suit to the manufacturers. Blaming the manufacturers for leading them into buying some devices with illegal impact.
But then again, manufacturers have no control over what freq being setup on the hotspot because it was helium who wrote the code inside that managing the freq being used in such country.
So hopefully, someone is now doing their homework, instead of just keep using a piece of doc from lora alliance as an excuse and say it's a standard, but ignoring the regulation from each govt. And doing it fast.
As i still remember that it was said as the people network, not the certain country people network.
Get BlueMail for Android
On Dec 23, 2021, 23:08, at 23:08, joyanta-klk @.***> wrote:

that's fine to create a ticket. but going around the circle is risking
the hotspot investors to be in legal issues in different countries...
that's what I was trying to point. EIRP is not a legal issue.. but
transmitting out of the allowed band is. that was all I was trying to
say.
--
Reply to this email directly or view it on GitHub:
https://github.com/helium/HIP/pull/325#issuecomment-1000398651
You are receiving this because you were mentioned.
Message ID: @.***>

Why do you guys keep talking about illegal frequencies being used? If you've found a mistake with channels being used create a ticket with helium and the lora alliance. This is not relevant to the max eirp hip discussion

Why do you guys keep talking about illegal frequencies being used? If you've found a mistake with channels being used create a ticket with helium and the lora alliance. This is not relevant to the max eirp hip discussion

This I agree.
Everyone, let's keep this discussion relevant to the HIP proposal.
If there's an issue with channels/frequency being incorrect, please raise a ticket with helium / lora alliance.

Firstly, thank you, everyone, for all the valuable feedback and opinions.
Now, let's try to clear things up a little so we can move forward.
One of the main reasons for PoCv11 is to be compliant with the regional regulations so that the hotspots would not be operating illegally in countries exceeding the max EIRP limits mandated by local regulations.
PoCv11 has however not taken into consideration that not all countries have the same regulatory max EIRP limits by implementing the blanket 16dBm max EIRP limit across the entire AS923 region & others affected.
IMO, this is a bit like a car manufacturer saying they will limit all their cars to a 30mph speed limit with engine cut off regardless of individual countries' regulatory speed limit because there is a standard that's being used for reference.
What this HIP seeks to address is to have the max EIRP limits for the affected countries corrected according to local regulatory limits as provided in the documents in this discussion.
We are not asking to implement something different but rather a fair request for impacted countries to have their max EIRP limit corrected for Helium hotspots based on local regulation which aligns with what PoCv11 is set out to achieve rather than being penalized. Right now, hotspot owners are being penalized with reduced transmission power although they could perform much more.

With regards to the discussion below, I feel that we need better clarification as this could be a separate discussion as it is something different.

@gradoj I never said not to do it. I said you shouldn't just change it and ignore the standard because if new regions are not added sensors will never be able to take advantage of what you guys are advocating for. If sensors cannot take advantage of the change then there is no point - as Poc is an analog for sensor coverage

I'm not sure if Semtech standards are being used/referenced for PoCv11, if so:
This is still an early stage of the project and Helium is in the adoption phase to further expand the network until data usage becomes a mainstream source of rewards in the future. Local Authorities Limit > Standards by others.
Hotspots owners are essentially one of the investors and participants of the project so yes, with rewards being primarily for witnessing between hotspots, it is important right now that this is remediated for the community in the region.
Current incorrect max EIRP translates to reduced coverage which has a great impact on earnings and it'd be unfair for the AS923 region & others affected to be nerfed unnecessarily beyond the local regulatory limits.

Coming back to the topic for this HIP
Quote by @gradoj:

This seems like an improvement to the network to me. Is there a difference between new regions and sub-regions? I assume sub-regions have the same channel plan but with a different EIRP limit. If it is decided to do this maybe they just be treated as whole new regions instead of adding a sub-region concept? Here is a summary of places that have been mentioned. Feel free to add to the list https://docs.google.com/spreadsheets/d/17Ta-k97ciFYQ9oYfUYp7wJCQKNXjcEhte6gE6gunIjU/edit?usp=sharing

@abhay @lthiery @vihu @gradoj  this is a nice summary and can you please advise how we can move forward with this?

Firstly, thank you everyone for all the valuable feedback and opinions.
Now, let's try to clear things up a little so we can move forward.
One of the main reason for PoCv11 is to be compliant with the regional regulations so that the hotspots would not be operating illeaglly in countries exceeding the max EIRP limits mandated by local regulations.
PoCv11 has however not taken into consideration that not all countries has the same regulatory max EIRP limits by implementing the blanket 16dBm max EIRP limit across the entire AS923 region. Most of the countries in AS923 has local regulatory max EIRP limits of 25-27dBm (up to 500mW) instead of the 16dBm (40mW) implemented via PoCv11.
IMO, this is abit like a car manufacturer saying they will limit all their cars to 30mph speedlimit with engine cut off regardless of individual countries regulatory speedlimit because there is a standard that's being used for reference.
What this HIP seeks to address is to have the max EIRP limits for the affected countries corrected according to local regulatory limits as provided in the documents in this discussion.
We are not asking to implement something different but rather a fair request for impacted countries to have their max EIRP limit corrected for Helium hotspots based on local regulation which aligns with what PoCv11 is set out to achieve rather than being penalized.
Right now, the community in AS923 region are being penalized with reduced transmission power although they could perform much more.
Quote by gradoj:
"I never said not to do it. I said you shouldn't just change it and ignore the standard because if new regions are not added sensors will never be able to take advantage of what you guys are advocating for. If sensors cannot take advantage of the change then there is no point - as Poc is an analog for sensor coverage"
With regards to this discussion, I feel that we need better clarification as this could be a separate discussion as it seems something different.
I'm not sure if Semtech standards are being used/referrenced for PoCv11, if so:
This is still early stage of the project and Helium is in adoption phase to further expand the network until data usage becomes mainstream source of rewards in the future.
Hotspots owners are essentially one of the investors and participants of the project so yes, with rewards being primarily for witnessing between hotspots, it is important right now that this is remediated for the community in the region.
Current incorrect max EIRP translates to reduced coverage which has a great impact to earnings and it'd be unfair for AS923 region to be nerfed unnecessarily beyond the local regulatory limits.
We can certainly explore the topic mentioned when we transit to a more real-world data usage driven phase with the Helium network.
Coming back to the topic for this HIP
Quote by gradoj:
"This seems like an improvement to the network to me. Is there a difference between new regions and sub-regions? I assume sub-regions have the same channel plan but with a different EIRP limit. If it is decided to do this maybe they just be treated as whole new regions instead of adding a sub-region concept? Here is a summary of places that have been mentioned. Feel free to add to the list
https://docs.google.com/spreadsheets/d/17Ta-k97ciFYQ9oYfUYp7wJCQKNXjcEhte6gE6gunIjU/edit?usp=sharing"
@abhay @lthiery @vihu @gradoj this is more or less the TLDR of what's discussed above, can you please advise how we can move forward with this?
Thank you

Firstly, thank you, everyone, for all the valuable feedback and opinions.  I apologize for how things have turned up into.
Now, let's try to clear things up a little so we can move forward.
One of the main reasons for PoCv11 is to be compliant with the regional regulations so that the hotspots would not be operating illegally in countries exceeding the max EIRP limits mandated by local regulations.
PoCv11 has however not taken into consideration that not all countries have the same regulatory max EIRP limits by implementing the blanket 16dBm max EIRP limit across the entire AS923 region & others affected. Most of the countries in AS923 has local regulatory max EIRP limits of 25-27dBm (up to 500mW) instead of the 16dBm (40mW) implemented via PoCv11.
IMO, this is a bit like a car manufacturer saying they will limit all their cars to a 30mph speed limit with engine cut off regardless of individual countries' regulatory speed limit because there is a standard that's being used for reference.
What this HIP seeks to address is to have the max EIRP limits for the affected countries corrected according to local regulatory limits as provided in the documents in this discussion.
We are not asking to implement something different but rather a fair request for impacted countries to have their max EIRP limit corrected for Helium hotspots based on local regulation which aligns with what PoCv11 is set out to achieve rather than being penalized.
Right now, hotspot owners are being penalized with reduced transmission power although they could perform much more.
With regards to the discussion below, I feel that we need better clarification as this could be a separate discussion as it is something different.
Quote by @gradoj

I never said not to do it. I said you shouldn't just change it and ignore the standard because if new regions are not added sensors will never be able to take advantage of what you guys are advocating for. If sensors cannot take advantage of the change then there is no point - as Poc is an analog for sensor coverage

I'm not sure if Semtech standards are being used/referenced for PoCv11, if so:
This is still an early stage of the project and Helium is in the adoption phase to further expand the network until data usage becomes a mainstream source of rewards in the future. Local Authorities Limit > Standards by others.
Hotspots owners are essentially one of the investors and participants of the project so yes, with rewards being primarily for witnessing between hotspots, it is important right now that this is remediated for the community in the region.
Current incorrect max EIRP translates to reduced coverage which has a great impact on earnings and it'd be unfair for the AS923 region & others affected to be nerfed unnecessarily beyond the local regulatory limits.
We can certainly explore the topic mentioned when we transit to a more real-world data usage-driven phase with the Helium network.
Coming back to the topic for this HIP
Quote by @gradoj :

This seems like an improvement to the network to me. Is there a difference between new regions and sub-regions? I assume sub-regions have the same channel plan but with a different EIRP limit. If it is decided to do this maybe they just be treated as whole new regions instead of adding a sub-region concept? Here is a summary of places that have been mentioned. Feel free to add to the list  https://docs.google.com/spreadsheets/d/17Ta-k97ciFYQ9oYfUYp7wJCQKNXjcEhte6gE6gunIjU/edit?usp=sharing

@abhay @lthiery @vihu @gradoj Whatever I have said is more or less the TLDR of what's discussed in this request. I would like to ask you to please advise how we can move forward with this?

Wio Lorawan Tester from Seeedstudio for helium tester is using STM32WLE5JC which using SX126X chip from SEMTECH.
This chip is designed to have max tx power (EIRP) until 22 dBm. And this 22dBm can be preconfigure on software basis. Same like when Helium changes the max EIRP on hotspots with the few lines of codes.
So that means even SEMTECH is designing chip with 22 dBm. Not 16 dBM. And this is being used in ASIA for AS923 frequency.

Wio Lorawan Tester from Seeedstudio for helium tester is using STM32WLE5JC which using SX126X chip from SEMTECH.
This chip is designed to have max tx power (EIRP) until 22 dBm. And this 22dBm can be preconfigure on software basis. Same like when Helium changes the max EIRP on hotspots with the few lines of codes.

So that means even SEMTECH is designing chip with 22 dBm. Not 16 dBM. And this is being used in ASIA for AS923 frequency.

Sticking with car analogy...my car has a top speed of 222km/h. Doesn't mean i can legally drive it at that speed.

Whatever I have said is more or less the TLDR of what's discussed in this request. I would like to ask you to please advise how we can move forward with this?

There are a couple of things stopping this imo. These might help move things forward:

No one knows exactly what was Semtech's reasoning for setting 16dbm eirp? especially in AS923. Someone email the alliance<EMAIL_ADDRESS>and figure out why it was put in the standard in the first place.

There is a community disagreement between whether hotspots should do POC at the same power level as sensors or whether they should do POC at maximum allowable power level of the fixed hotspots. Add a column to the spreadsheet with max tx power/max EIRP for mobile sensors (not fixed basestations) for each country. https://docs.google.com/spreadsheets/d/17Ta-k97ciFYQ9oYfUYp7wJCQKNXjcEhte6gE6gunIjU/edit?usp=sharing

@gradoj thank you for your comments. For now, We will work towards:

One of us will ask alliance and figure out why the standard was put there in the first place. So we understand the circumstances better. Looking at it, you don't seem to know as well.
Gather more discussion/sensing between the two issues. There seem to be divided views between these 2 issues. The community may have a misconception of what hotspot/POC is meant to be.

Anyways, thanks to everyone for their valuable feedbacks and points, and Merry Christmas! Let's take a break from the heavy discussion.

@beaky98 last minute but would you be interested in presenting this HIP at the community call today? noon ET https://dewi.org/community-call

@jamiew Sorry, not able to make it today. I will try to present it in a future session. Please keep me in the loop for any questions posted later, thank you.

This HIP draft has been numbered and merged for discussion as HIP 49. Please direct future questions & comments to the new tracking issue: #327
If you are one of the named authors, please include #327 in future pull requests to have them automatically merged.


Fix phoenix-em-eth w/o meter broken in PR 10247

In PR https://github.com/evcc-io/evcc/pull/10247 automatic detection of meter was implemented, however it broke the code for charge controllers without meter - it reports constant charging power of -10 W.
The problem is in the meter presence detection - the L1 voltage is tested, however it is improperly decoded as unsigned int and thus instead of -1 it reports 0xFFFF and detects presence of meter when the meter is not actually there.
The actual voltage/current reading on line 182 uses correct Int32LswFirst, only the detection of voltage used wrong Uint32LswFirst.

Oh, does it really return 0xffff?
On my controller its simply 0x0 without meter.
But anyway it's better to do the decoding the right way.

Yes, it does return -1 on at least 2 devices I know of.
It might be firmware dependent (mine is v2.1.5).
Anyway, thanks for the original code and also this quick merge.


Skip broken vendor symlink rather than returning an error.

What does this do / why do we need it?
Skip broken vendor symlink rather than returning an error
What should your reviewer look out for in this PR?
When one of 3rd party packages has a broken vendor symlink, it fails whole ensure process.
Current logic behaves:

remove a vendor symlink linked to a valid directory
leave a vendor symlink linked to a valid file
return error if a vendor symlink is broken (linked file doesn't exist)

I think this behavior is not intended and it seems to be that it's better to skip the check except the case it's linked to a valid directory as it's harmless rather than returning an error causing the whole process stop.
Expected/New behavior:

remove a vendor symlink linked to a valid directory
leave rest of the cases(linked to a file or broken) as they are not harmful rather than returning an error

Do you need help or clarification on anything?
No
Which issue(s) does this PR fix?
This is a new behavior introduced in v0.3.1 with its improved type checking
Since this is a breaking change, some users migrating from 0.3.0 could experience this issue.
The main problem is that when this happens on some 3rd party libraries that you don't have the control, you just have to downgrade and use v0.3.0
v0.3.1
$ dep ensure -v
(28/45) Failed to write<EMAIL_ADDRESS>grouped write of manifest, lock and vendor: error while writing out vendor tree: failed to write dep tree: failed to strip vendor from github.com/...(removed)...: stat /var/folders/7q/lqjydj5s3y72cxbtv4srgy4myyfy7s/T/dep540422238/vendor/github.com/...(removed).../vendor: no such file or directory
$ echo $?
1

v0.3.0
$ dep ensure
$ echo $?
0

(I'm still thinking about this change overall, but if we do go this direction, then we absolutely need this check.)

@sdboyer, what are your concerns on skipping broken vendor symlinks? I'd like to talk it out - this issue is blocking several teams' usage of dep at $EMPLOYER right now, so I feel invested as $EMPLOYER's resident dep champion :)


"No space left on device" on Windows portability tests

From the logs:
t:\src\github\grpc\workspace_c++_windows_dbg_native_x64_cmake_vs2017_buildonly\cmake\build\gens\src\proto\grpc\testing\xds\v3\config_dump.grpc.pb.cc(30): fatal error C1088: Cannot flush compiler intermediate file: 'T:\tmp\_CL_875d5946gl': No space left on device [T:\src\github\grpc\workspace_c++_windows_dbg_native_x64_cmake_vs2017_buildonly\cmake\build\xds_interop_server.vcxproj]

  csds.pb.cc

t:\src\github\grpc\workspace_c++_windows_dbg_native_x64_cmake_vs2017_buildonly\cmake\build\gens\src\proto\grpc\testing\xds\v3\csds.pb.cc(1930): fatal error C1088: Cannot flush compiler intermediate file: 'T:\tmp\_CL_0cb8e1abgl': No space left on device [T:\src\github\grpc\workspace_c++_windows_dbg_native_x64_cmake_vs2017_buildonly\cmake\build\xds_interop_server.vcxproj]

  csds.grpc.pb.cc

t:\src\github\grpc\workspace_c++_windows_dbg_native_x64_cmake_vs2017_buildonly\include\grpcpp\impl\codegen\interceptor_common.h(362): fatal error C1088: Cannot flush compiler intermediate file: 'T:\tmp\_CL_bffb840fex': No space left on device [T:\src\github\grpc\workspace_c++_windows_dbg_native_x64_cmake_vs2017_buildonly\cmake\build\xds_interop_server.vcxproj]

Full log https://source.cloud.google.com/results/invocations/433c5f6c-8571-4616-9207-b7cc67a51bb6/log
Seen in https://github.com/grpc/grpc/pull/28016

Looks like this is failing 100% builds on master:
(e.g. a recent one: https://source.cloud.google.com/results/invocations/9d06fd76-b74c-4f54-a5ec-1f753d226c36/targets/github%2Fgrpc%2Ftoplevel_run_tests_invocations%2Frun_tests_c%2B%2B_windows_dbg_native_x64_cmake_vs2017_buildonly/tests)
LINK : fatal error LNK1201: error writing to program database 'T:\src\github\grpc\workspace_c++_windows_dbg_native_x64_cmake_vs2017_buildonly\cmake\build\Debug\xds_credentials_test.pdb'; check for insufficient disk space, invalid path, or insufficient privilege [T:\src\github\grpc\workspace_c++_windows_dbg_native_x64_cmake_vs2017_buildonly\cmake\build\xds_credentials_test.vcxproj]

Yeah, I updated the windows image to use 250GB working space instead of 100GB. It's known that certain windows tests such as portability test can consume a lot of space mainly due to a lot of relatively large PDB file per a test.

Fixed now. Closing this.


Model table within a different model

Hey guys I wanted to know if anyone could point me in the right direction to include a table from one model into another. So if I make a model that has a relationship to a customer and it has many I would like to phrase the table out with the ones that compare to that user. I was able to get that information into it by `
$equipment = DB::table('equipment')->where('customer', '=',  $customer['id'])->get();

		@foreach( $equipment as $col )
		{{ $col->type }}
		@endforeach

		Actions

`
But this method seems to not work great. If the customer does not have a relation it will show blank rows in the table. The table also doesn't display the title of the rows of the table properly.

You can use the ORM relationships that's already built on Laravel: https://laravel.com/docs/5.3/eloquent-relationships
For your use case it will look something like:
@foreach( $customer->equipments as $e )
{{ $e->type }}
@endforeach

Hope it helps


Very slow performance

Type: Performance Issue
From initial startup everything is slow including hovering over files in the files list, typing, using menus etc.
VS Code version: Code 1.90.1 (611f9bfce64f25108829dd295f54a6894e87339d, 2024-06-11T21:02:43.666Z)
OS version: Linux x64 5.15.0-107-generic snap
Modes:

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-10875H CPU @ 2.30GHz (16 x 1596)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_graphite: disabled_offvideo_decode: enabledvideo_encode: disabled_softwarevulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: disabled_off

Load (avg)
8, 11, 9

Memory (System)
30.97GB (24.61GB free)

Process Argv
--force-user-env --no-sandbox --use-gl=angle --use-angle=swiftshader --crash-reporter-id c96eef59-1669-4bee-b15f-d14c4c84111c

Screen Reader
no

VM
0%

DESKTOP_SESSION
ubuntu

XDG_CURRENT_DESKTOP
Unity

XDG_SESSION_DESKTOP
ubuntu

XDG_SESSION_TYPE
x11

Process Info
CPU %	Mem MB	   PID	Process
    0	   159	 34142	code main
    0	    32	 34144	   zygote
    0	    32	 34145	   zygote
    0	   254	 34219	window [1] (.nvmrc - Untitled (Workspace) - Visual Studio Code)
    0	    95	 34925	window [2] (Issue Reporter)
    0	    32	 34179	   utility-network-service
    0	    95	 34470	shared-process
    0	     0	 34937	     /bin/sh -c /usr/bin/ps -ax -o pid=,ppid=,pcpu=,pmem=,command=
    0	     0	 34938	       /usr/bin/ps -ax -o pid=,ppid=,pcpu=,pmem=,command=
    0	    95	 34471	fileWatcher [1]
    0	   127	 34472	extensionHost [1]
    0	    63	 34874	     /snap/code/161/usr/share/code/code /snap/code/161/usr/share/code/resources/app/extensions/json-language-features/server/dist/node/jsonServerMain --node-ipc --clientProcessId=34472
    0	    63	 34519	ptyHost
    0	     0	 34537	     /usr/bin/bash --init-file /snap/code/161/usr/share/code/resources/app/out/vs/workbench/contrib/terminal/browser/media/shellIntegration-bash.sh

Workspace Info
|  Window (.nvmrc - Untitled (Workspace) - Visual Studio Code)
|    Folder (visualiser): 17640 files
|      File types: ts(3476) html(2793) tsx(2573) png(1007) js(833) xml(542)
|                  log(541) json(463) jpg(295) css(291)
|      Conf files: package.json(94) tsconfig.json(93) github-actions(13)
|                  dockerfile(3) launch.json(1)
|      Launch Configs: chrome node;

Extensions: none
A/B Experiments
vsliv368:30146709
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscoreces:30445986
vscod805cf:30301675
binariesv615:30325510
vsaa593cf:30376535
py29gd2263:31024239
vscaac:30438847
c4g48928:30535728
azure-dev_surveyone:30548225
2i9eh265:30646982
962ge761:30959799
pythongtdpath:30769146
welcomedialog:30910333
pythonidxpt:30866567
pythonnoceb:30805159
asynctok:30898717
pythontestfixt:30902429
pythonregdiag2:30936856
pythonmypyd1:30879173
2e7ec940:31000449
pythontbext0:30879054
accentitlementsc:30995553
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
cppperfnew:31000557
dsvsc020:30976470
pythonait:31006305
jchc7451:31067544
showvideoc:31016891
chatpanelt:31048053
dsvsc021:30996838
9c06g630:31013171
pythoncenvpt:31062603
a69g1124:31058053
dvdeprecation:31068756
pythonprt:31056678
dwnewjupyter:31046869
2f103344:31071589

Same here on Ubuntu 22.04. Even scrolling is very slow and CPU usage is very high. Reverted the snap to v1.90.

same here... i'm on Ubuntu 22.04.4 LTS and even scrolling in explorer/editor is super laggy in the latest update

@atheck what is the snap command to switch back to 1.90 ??

I downloaded the April 2024 snap from here and then command line to remove the old and install this one.  I had to manually remove some ~/snap/code subdirs but then it installed fine and performance was back to snappy.

I used these snap commands to revert and it made it performant again:

sudo snap revert code --revision 160

Please revert to v1.89 or use debian package till this issue is fixed.
https://github.com/microsoft/vscode/issues/212494#issuecomment-2166941209

Given the crashes on launch with the snap package for 1.90, it is recommended to revert to 1.89/snap revision 159 or to switch to debian until #212494 gets a proper fix. The comments there suggest that some multi-monitor setups might not have observed the crashes with 1.90.

Just update it vscode to 1.90.1 and has poor performance plus the laptop fan has ramp up. Gonna revert as suggested.
System Details Report

Report details

Date generated:                              2024-06-14 09:18:09

Hardware Information:

Hardware Model:                              ASUSTeK COMPUTER INC. GL553VD
Memory:                                      12,0 GiB
Processor:                                   Intel® Core™ i5-7300HQ × 4
Graphics:                                    Intel® HD Graphics 630 (KBL GT2)
Disk Capacity:                               1,0 TB

Software Information:

Firmware Version:                            GL553VD.308
OS Name:                                     Ubuntu 23.10
OS Build:                                    (null)
OS Type:                                     64-bit
GNOME Version:                               45.2
Windowing System:                            X11
Kernel Version:                              Linux 6.5.0-41-generic

I have tried disabling the unnecessary extensions, and the lage is still there.
System Info

Sorry for neofetch!
       _,met$$$$$gg.          gradf@beepboop
    ,g$$$$$$$$$$$$$$$P.       --------------
  ,g$$P"     """Y$$.".        OS: Debian GNU/Linux 12 (bookworm) x86_64
 ,$$P'              `$$$.     Host: 81W8 Lenovo IdeaPad S145-15IIL
',$$P       ,ggs.     `$$b:   Kernel: 6.1.0-21-amd64
`d$$'     ,$P"'   .    $$$    Uptime: 1 hour, 53 mins
 $$P      d$'     ,    $$P    Packages: 2200 (dpkg), 6 (flatpak), 13 (snap)
 $$:      $$.   -    ,d$$'    Shell: bash 5.2.15
 $$;      Y$b._   _,d$P'      Resolution: 1920x1080
 Y$$.    `.`"Y$$$$P"'         DE: GNOME 43.9
 `$$b      "-.__              WM: Mutter
  `Y$$                        WM Theme: Adwaita
   `Y$$.                      Theme: Adwaita [GTK2/3]
     `$$b.                    Icons: Adwaita [GTK2/3]
       `Y$$b.                 Terminal: alacritty
          `"Y$b._             CPU: Intel i7-1065G7 (8) @ 3.900GHz
              `"""            GPU: Intel Iris Plus Graphics G7
                              Memory: 7281MiB / 11756MiB

>>> lscpu                                                                                (base)
Architecture:             x86_64
  CPU op-mode(s):         32-bit, 64-bit
  Address sizes:          39 bits physical, 48 bits virtual
  Byte Order:             Little Endian
CPU(s):                   8
  On-line CPU(s) list:    0-7
Vendor ID:                GenuineIntel
  Model name:             Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz
    CPU family:           6
    Model:                126
    Thread(s) per core:   2
    Core(s) per socket:   4
    Socket(s):            1
    Stepping:             5
    CPU(s) scaling MHz:   72%
    CPU max MHz:          3900.0000
    CPU min MHz:          400.0000
    BogoMIPS:             2995.20
    Flags:                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdp
                          e1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqd
                          q dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave
                          avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriori
                          ty ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid avx512f avx512dq rdseed adx smap avx512ifma clflushopt intel_p
                          t avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves split_lock_detect dtherm ida arat pln pts hwp hwp_notify hwp_act_wi
                          ndow hwp_epp hwp_pkg_req avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid
                          fsrm md_clear flush_l1d arch_capabilities
Virtualization features:
  Virtualization:         VT-x
Caches (sum of all):
  L1d:                    192 KiB (4 instances)
  L1i:                    128 KiB (4 instances)
  L2:                     2 MiB (4 instances)
  L3:                     8 MiB (1 instance)
NUMA:
  NUMA node(s):           1
  NUMA node0 CPU(s):      0-7
Vulnerabilities:
  Gather data sampling:   Mitigation; Microcode
  Itlb multihit:          KVM: Mitigation: VMX disabled
  L1tf:                   Not affected
  Mds:                    Not affected
  Meltdown:               Not affected
  Mmio stale data:        Mitigation; Clear CPU buffers; SMT vulnerable
  Reg file data sampling: Not affected
  Retbleed:               Mitigation; Enhanced IBRS
  Spec rstack overflow:   Not affected
  Spec store bypass:      Mitigation; Speculative Store Bypass disabled via prctl
  Spectre v1:             Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:             Mitigation; Enhanced / Automatic IBRS; IBPB conditional; RSB filling; PBRSB-eIBRS SW sequence; BHI SW loop, KVM SW loop
  Srbds:                  Mitigation; Microcode
  Tsx async abort:        Not affected

Experiencing the same problem, Ubuntu 22.04.4.

got the same issue as well
can't snap revert to 1.90 as it just crashes on startup
how to go back to the old good 1.89 with snap ?

Merging to https://github.com/microsoft/vscode/issues/212494, please follow the issue for updates.


Raise a .illegalNull is the top level JSON is null.

This still allows it for the things that can custom support decoding from
null, but the test isn't completely clear on what should happen for those.
Fixes #869

Wow. That was even simpler than I expected.

Yea, I did a lot of searching the code to confirm what calls to that vs. message fields, and the only other thing than developer code that will hit that is decoding an Any, and that seems like it should also fail until something officially says otherwise.


[BEAM-8451] Fix interactive beam max recursion err

When a pipeline contains a PTransform which passes through its input PCollection during expand(), the PipelineInfo object may run into an infinite recursion error while constructing the derivation for said PCollection.
This PR prevents the infinite recursion by not marking a transform as a producer of PCollection if that PCollection is also an input to the transform.
I've added a test for this, but without the fix, the test does not fail 100% of the time--it's dependent on the ordering of transforms in the Pipeline proto. Any advice on how to test this better is appreciated.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Choose reviewer(s) and mention them in a comment (R: @username).
R: @aaltay
R: @robertwb
R: @charlesccychen
[x] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

Run PythonLint PreCommit

R: @KevinGG

R: @rohdesamuel
Hi Chuck! I'm also working on the Interactive Beam along side with @KevinGG. Hope you don't mind adding myself as a reviewer.
The fix looks good, can you please add a comment above the "transform_imputs = set(...)" saying this is to prevent recursion?

Thanks for the review Sam! I've added the comment, let me know if it's in line with what you were thinking.

Yep, perfect. Thanks for the contribution!

Hey @pabloem is this good to merge?

Thanks all!


IIS G. Marconi - Imperia/Sanremo

domain marconi.imperia.it
This is the link to the IT related course (in italian) is: https://www.istitutoistruzionesuperioremarconi.edu.it/informatica-e-telecomunicazioni-sede-di-sanremo/

@fromthestone Thank you for your patience while waiting for a review and processing your request. Pull request merged.