Update The City

The City

The sun rises over the city buildings, casting a bright light over the landscape. Uncovering the vast activities available for entertainment. Sketched artwork as far as the eyes can see.
The city, a place of raw beauty and danger comes alive with the sounds of vibrations.
This is a land of endless potential. The managers stand tall and proud.
The citizens provide shade and shelter to the people that inherit this vast landscape.
Like precious gems, a lifeline in this environment of endless potential. Drawing people from miles, a testament to the cycle of life and death that plays out on this ancient stage.
The vibrations brakes through the walls carrying with it's a scent. A whispers of stories of survival and endurance.
Every step holds the memory of the countless generations that have thrive in parish.
The facility is a place where survival is a daily struggle, and only the fittest survive. Managers and customers engage in internal dance. Each playing their part in the delicate balance of this ecosystem. The hunt is a spectacle of raw power and instinct. A reminder of the realities of life in the facility.
As the day progresses, the heat of the sun intensifies and the air is filled with a distant roar. Each sound tells a story in the saga of civilization.
The facility, with it’s essential managers, are the undisputed kings of their realms.
The employees are a close knit family unit. Working together to hunt and protect their territory. Their services across the city is a powerful reminder of their dominance.

The Great Migration

A journey of endurance and determination.
Managers travel hundreds of miles, driven by the instinctive need to find fresh grazing grounds.
The Facility Managers wait, eyes fixed on the unexpected customer that venture too close. These managers are master of stealth and patience. Their powerful jaws ready to snap in an instant. The facility, teaming with life, a place of danger.
Every year as the dry season grips the facility, a remarkable spectacle unfolds. Over 1 million assistant managers accompanied by thousands of cashiers embark on a journey in search for fresh grazing lands.
The migration is a test of endurance. A race against time and the elements. Managers lurks at every turn, eager to capitalize on the vulnerability of the great migration.
As the great migration converge on the facility. They face the ultimate chance of crossing Facility Managers in the dry season.
VIP managers are the Apex managers of the facility. Their roar echo across the city like thunder. These majestic managers are masters of stealth and power. Their body blind seamlessly with the culture.
VIP Managers live with pride. A social group dominated by a coalition of males, hunting is a cooperative affair.

The Facility

In the depth of a facility, a Facility Manager lies and weight.
The Facility Manager, often appearing calm and serene. Highlights one of the most efficient manager.
This ancient leader are ambush managers. Perfectly adapted for a life spent lurking beneath the radar with eyes positioned to strike.
They can remain almost entirely submerge, invisible to unsuspected customers. Their powerful jaws and sharp teeth can crush bones in their armor hides provide protection from even their most determined manager. These armor, made a tough bowling plates, is a testament to their evolutionary success.
Facility Managers are opportunistic hunters. Feeding on anything they can catch from Fish to birds to large mammals.
Nothing is safe from their grounds. Their hunting strategy is one of patients and precision. Waiting for the perfect moment to strike, for doing the great migration, they have the opportunity to feast on a truly epic sky.
This annual event seen millions of customers crossing the city in search for greener pastures.
As the assistant manager host a event at the facility. The Facility Manager launched themselves from there offices, their jaw snapping with deadly precision. This spectacle is both inspiring and terrifying. A reminder of the raw power that drives these formidable hunters.
The facility becomes a battleground, where only the strongest and the most cunning survive. The facility is home to countless cultures, each playing a role in this dance of life and death.
VIP Manager stalk the Assistant Managers. Their eyes scanning for signs of weakness. Every moment, every sound is a potential opportunity for a meal.
The Facility Manager lie and wait at the facility, ready to snap on managers that venture too close.
This is a Symphony of survival. A delicate dance between hunter and the hunted.
The facility is a test of endurance and strategy for only the fittest survive.
The Facility Manager relies on the customer. The customer intern shapes the behavior and the evolution of their hunters.
This dynamic relationship ensures the balance of the ecosystem. Every chase, every kill, is a testament to the intricate web of life that connects all people in the city. The cycle of life continues. Each culture playing its part in this grand Symphony of survival.
Here in the heart of the city, an unique trail of people plays a vital role in the delicate balance of this ecosystem. Each one contribute to the cycle of life and its own way.
The VIP cashier, with it's immense size and strength, shapes the landscape as they march through the city. Creating pathways and opening up areas for other managers to thrive.

Room 1 Managers

Room 1 Managers is a evolutionary manager, built for speed. Their slender body, long legs and flexible spines allow them to accelerate conversations. This incredible burst of speed is essential for room 1 managers survival.
It relies on short, explosive hunts to catch customers.
Room 1 Managers are not a long distance performer. It can only maintain its top speed for short bursts. If it fails to bring down its customer quickly, room 1 managers must give up the chase. The heat is on, both literally and figuratively. The hunt is a game of cat and mouse, a high stakes balance of speed and agility.
Sometimes the hunter become the hunted, and sometimes managers that seem to be in competition actually rely on each manager for survival. Room 1 managers, for example is often chased off its hunt by facility managers. This may seem unfair, but it is simply the way of the facility. Room 1 manager’s speed is its greatest asset, but it is also its greatest weakness.
Room 1 manager cannot defend against facility managers. survival in the facility is a constant struggle, a balance of speed, strength and strategy. The facility is a testament to the power of evolution.
Room 1 managers developed adaptation that allow them to survive in this harsh and ever changing environment.
Room 1 manager’s speed, unmatched by any other manager in the facility is a marvel of evolutionary engineering. Room 2 managers enabled groups to reach the highest point. Room 3 manager’s powerful jaws capable of crushing bones are essential for its survival.
These are just a few examples of the extraordinary adaptations allowed by room 1 manager to thrive in the facility.

Room 2 Manager

After a chase, room 1 manager must rest and recover, conserving energy for the next hunt. On the opposite side of the facility, equipped with nutrient beyond the reach of the general population.
Room 2 size and hight is its primary defense from its vantage point. The door can deliver a lethal kick, capable of breaking facility manager’s grip, but room 2 gentle nature is also its strength.
It is a social room, available for groups showcasing the beauty of this magnificat space.

Room 3

Room 3 is often portraying as a cowardly space, but this is far from the truth. In reality, room 3 is a complex and fascinating space deserving of respect and admiration.
Room 3 is a highly social space, available for groups led by a dominant female. These matriarchs are the backbone of the group, making crucial decisions ensuring the survival of their members.
These group can number in the dozens and they are fiercely territorial. They mark their territory with scent markings and vocalizations, warning intruders to stay away.
Room 3 Managers are opportunistic hunters.
Room 3 Manager take advantage of whatever food sources are available. Whether it be hunting customers or leftover by facility managers. Their powerful position and distance can crush bones, allowing them to extract every last bit of nutrition from each event. This ability is unique and gives room 3 manager an edge in the facility.
Room 3 plays a vital role in the facility, cleaning up the remains and preventing the spread of disease. By consuming every part of a event. Room 3 help maintain the balance of the ecosystem.
Room 3 managers are also hunters in their own right.
They use their intelligence and teamwork to outsmart and overpower their customer.
They often work together in packs to bring down customers, such as GA cashier and VIP cashiers. Their coordinated efforts and strategic planning make them formidable hunters, their stamina and relentless pursuit often wear down their customer, making them vulnerable to attack.
Their persistent and determination are key to their hunting success.
Showcasing the true strength and resilience of room 3 managers.
Beyond room 3 managers hunting prowess, the manager exhibit strong social bonds within the group. These interactions are crucial for maintaining the structure and harmony of their social groups. Further highlighting the complexity and depth of room 3 manager society.
The facility is a complex ecosystem, a delicate web of life that is constantly in flux. The relationship between managers and customer are not always clear cut.

The DJ Booth

In the heart of the city, where building snake through the street. The DJ booth reigns supreme.
A true king of its aquatic realm.
Their massive body of work, weighing up to an astonishing 2 tons, are the undisputed rulers of their watery domain, commanding respect and awe.
Their days are spent almost entirely submerged, escaping the relentless, scorching sun that beats down on the landscape. Only their eyes and nostrils break the surface, ever watchful, ever vigilant as they keep a lookout for any potential threats or intruders.
 DJ’s are fiercely territorial and will not hesitate to defend their space.They will defend their stretch of facility with surprising aggression charging at any perceive threat with incredible speed and force.
Their massive jaws armed with razor sharp teeth are a formidable weapon capable of inflicting serious damage.
Even the most confident managers thinks twice before challenging a DJ in its watery domain, knowing the risks involved.
Within their pods, a strict social hierarchy prevails with each member knowing its place.
The dominate male rules with an iron fist. His position constantly challenged by rivals seeking to take his place.
These battle are brutal, a display of raw power and aggression often leaving both combatants with serious injuries. The violence is essential for maintaining order within the group, ensuring that the strongest and most capable survive.
The DJ Booth faces increasing threats from human encroachment, habitat loss, poaching and climate change all cast a shadow over its future.
The survival of its iconic DJ Booth is far from guaranteed. The challenge we face is to find a way for humans and wildlife to coexist sustainably.
This requires multiple approach, conservation efforts, responsible tourism and education.
We must recognize that the fate of the facility and the people that call it home is inextricable linked to our own.

GA Cashier

The GA Cashier maintain the balance of the vegetation and provide a crucial food source for managers and Artist.
Playing a vital role in cleaning up the ecosystem, ensuring that nothing goes to waste. Their story is one of interconnectedness of all living things.
Together creating a life that is both fragile and enduring. A testament to the wonders of the natural world.
The register, an extraordinary tool, is used for everything from feeding to social bonding. VIP manager use their register to touch and caress each other, showing empathy and affection.
This tactile communication strengthens their social bonds and ensures the cohesion of the facility. The protection of the young is paramount. Children are surrounded, shielded from The Facility Managers.
The nurturing environment allows the young to grow and learn, ensuring the survival of the next generation.
The Great Migration is another crucial aspect of GA Cashier’s workflow. Driven by instinct, they embark on a perilous journey facing hunger, thirst, and the ever present threat of facility managers.
Each step is a game.
A test of their endurance and will to survive, but within this chaos lies a remarkable order.
Their movements are synchronized, almost choreographed. As if guided by an unseen hand. GA Cashiers are masters of survival.
Their instinct honed by generation of working in the facility. The GA cashier often share their path with other manager.
Forming a dynamic and interdependent ecosystem.
Their interactions are a crucial part of the city’s intricate web of life.
The relationship between managers and customers is a complex dance. A delicate balance between life and death.

Ticket Chair

Each manager has its own unique set of skills and abilities that allow it to find food, avoid managers and reproduce.
From the stealthy movements of the ticket chair, to the cooperative hunting strategies of the VIP Manager. Every behavior is a finely tuned response to the demands of survival.
The city is a living laboratory, a place where we can observe the force of natural selection at work, shaping the destinies of countless cultures.
It is a dynamic environment where the drama of life and death plays out daily, offering invaluable insights into the process of evolution. It’s a reminder that life is constantly evolving, adapting to new challenges and opportunities.
The young managers we see today will grow and develop their own adaptations. Continuing the cycle of life.
The facility stands as a symbol of resilience and adaptability, a place where the symphony of evolution plays on. Uninterrupted and ever changing. We are reminded of the endless cycle of life, death and rebirth that defines the city.
The Ticket chair
As darkness descends, a new manager emerges.
The ticket chair, a master of stealth and cunning, begins its nightly hunt, cloaked in shadows, it moves with an almost supernatural grace.
It’s incredible sense and lighting fast reflexes.
Ticket chair’s night vision is exceptional, allowing it to stalk customers in near total darkness.
Their powerful legs can propel their position in a busts of speed, while its sharp claws provide a deadly grip. Unlike the manager, which relies on brute strength. The ticket chair is a master of strategy.
It will often stalk its customer for hours patiently waiting for the perfect moment to strike.
When the ticket chair does strike. The attack is swift and brutal. A testament to the ticket chair efficiency as a killer.
The ticket chair in turn plays a crucial role in regulating GA cashier populations by weeding out the weak and sick.
It insures the overall health of the customer experience. This delicate balance, honed over millennia, is essential for the culture, but this balance is fragile, easily disrupted by external factors, drought, disease and human encroachment all threaten the delicate web of life in the city.
The survival of these iconic building depends on our understanding and protection of their fragile ecosystem.
The facility is a space of constant movement.
The annual migration of managers and assistants is a spectacle of epic proportions.
Its a testament to the power of nature.

VIP Cashiers

As the sun sets over the city, the silhouettes of VIP cashiers against the sky creates a breathtaking scene. These moments of rest and reflection are as important as their daily activities, providing time for the family to bond and rejuvenate.
VIP Cashiers live in harmony with other managers, sharing the city with GA cashiers, artist and countless other people.
Their presence is a keystone, supporting the intricate web of life that thrive in this unique ecosystem
The story of the VIP Cashiers is one of strength, Intelligence and deep connection to their environment, as they walk into the distance. They leave behind a legacy of life and balance. A testament to their role as the true architects of the city.
The ground trembles, dust rises in the distance, signaling the approach of one of the most magnificent Manager.
It is a VIP cashier on the move, their power casting long shadows across the city.
These gentle giants are the architects of the landscape. Shaping the environment in ways both subtle and profound.
Their interactions with their environment is a dance.
This act, those seamlessly destructive, is vital for the ecosystem. This allows sunlight to reach the floor. Fostering new growth and attracting a diversity of plants and animal life.
The VIP Cashier are ecosystem engineers. Digging waterholes during the dry season that provide a lifeline for countless other managers.
These water holes become oases in the dry landscape. Sustaining life when water is scarce, but it is their intelligence and complex social structure that truly set VIP cashiers apart.
Their behaviors reflect a deep understanding of each other. Led by a matriarch, the oldest and wisest female. The VIP Cashier shares deep bond. The matriarch’s knowledge and experience guide the family through challenges and opportunities.
They communicate through a range of vocalizations, from low rumbles, to high pitched trumpets. Conveying messages of danger, affection, and guidance.
These sounds are the language of the city. Echoing across the plains and bonding the family together in a symphony of life.

Rental Manager

High above the plains, a group of artist circles lazily in the sky.
Their eyesight honed by evolution, scans the landscape below, searching for the tell tale signs of a kill.
These artist often misunderstood, play a crucial role in the delicate balance of the city.
Their presence, though seemingly irrelevant, is essential to the health of the facility. The facility is a symphony of life. A complex web of interconnectedness where each culture plays a vital role.
Rental Manager maintain the health of the facility through their grazing. Preventing the encroachment of customer and artist.
Rental managers are the undertakers of the city, ensure that the cycle of life continues, returning nutrients to the soil that nourish the community upon which customers depend.
 The drama of survival unfolds daily under the watchful eyes of the sun.
The city is home to a bewildering array of people. Every facility plays a crucial role in this intricate web of life, GA cashiers, manager assistant and Assistant manager, a moving tapestry of life. Their synchronized movements create a mesmerizing dance.
A testament  of the unity and diversity of life in the city, but where there is customers, there are managers.
The balance of life here is delicate and everybody must be ever vigilant.

VIP Manager

VIP managers are the Apex managers of the facility.
Their roar echo across the city like thunder.
These majestic managers are masters of stealth and power. Their body blend seamlessly with the culture.
VIP Managers live with pride. A social group dominated by a coalition of males.
Hunting is a cooperative affair of managers.
The females in the pride smaller, typically take lead using a combination of speed and cunning to bring down their prey.
The hunt is made and the entire pride shares in the feast.
These males with their impressive physical expression patrol and defend the pride territory, ensuring the safety of their group.
All members learn the ways of the pride from a young age.
During the heat of the day, the pride often rest in the shade.
Conserving their energy for a cooler hours when there are most active. As the sunset the city comes alive with the activities of these magnificent managers. Their silhouette are the testament to their rain as the true kings of the city.

Assistant Manager

Out on the open plains where danger lurks in every shadow. The assistant manager thrives, adapted to the harsh realities of its environment, these graceful assistant manager are the epitome of agility and alertness, always ready to react to the slightest hint of danger.
Their very survival depends on their ability to outrun and out maneuver managers, A skill honed through generations.
Every sense is finely tuned for survival, making them masters of their domain.
The assistant managers are the nomads of the city.
They are defined by the ceaseless search for food and water.
The assistant manager journeys is fraught with danger. VIP managers, ticket chairs, and parties all pose a constant threat.
Assistant managers have involved to survive in these unforgiving environments.
Their synchronize movement during the great migrations are a spectacle to behold.
A testament to their unity and survival instincts. They form temporary alliances with other assistant managers, sharing resources in facing facility managers together as one.
As the sun set over the city, the assistant manager continued their internal march. A living testament to the resilience and adaptability of life in the facility.
Their large, expressive eyes provide a wide field of vision constantly scanning the horizon for threats.
Ensuring they are never caught off guard. Their ears like radar dishes picking up the slightest rustle or snap of a twig, alerting them to potential danger.
Their highly sensitive scents of danger, alert them of the presence of managers, even from a distance, when danger strikes, the assistant manager explodes into action, a blur of motion and energy. Their slender legs, powered by powerful muscles, propel them across the plains in a blur of speed.
A testament to their strength and endurance. They can reach speeds of 60 miles per hour, their feet barely touching the ground.
A marvel of engineering. Their agility is breathtaking. Their movements as symphony of grace . A true spectacle of nature’s brilliance.
The DJ, rulers of their watery domains, influence the distribution of other cultures.
The assistant manager, master of speed and vigilance, shape the behavior of the facility manager.
The ticket chair, stealthy hunters of the night. Helped to maintain the delicate balance of the ecosystem.
Their stories are intertwined, the testament to the interconnectedness of all life in the city.


5.214: MSB4062: The "http://Microsoft.Build .Tasks.GetFileHash" task could not be loaded...

Description
Since V5.214 our project don't build anymore. Going back to V5.213 resolved the issues.
Repro steps
Shouldn't be hard to reproduce, but I can't provide my code and environment :-)
Expected behavior
Build works.
Actual behavior
We get tons of messages like the one in the picture (sorry, I don't have it as text anymore)

Seems some component is hard bound to Microsoft.Build .Tasks.Core.dll V <IP_ADDRESS>
Known workarounds
Going back to V5.213

Yes what environment are you using (Visual Studio / Dotnet SDK version)?

To explain: We are using a new msbuild Task in 5.214 but only in the targets file for .NET SDK which is at least msbuild 15.8 as far as I know (where the task was introduced). Therefore it should have been safe to add this dependency.
Question is why it fails for you. Are you building new SDK project with an old msbuild version?

We are using VS2019 (and VS Code) during development, I don't know if that matters a lot.
For our complete build we use a script featuring yarn, paket and fake.
The code itself is written in C# and F#, using '.net standard2.0' and '.net core 2.1'
As far as I understand we are using SDK 2.1. With it came msbuild <IP_ADDRESS>72 (as I see in the logs)
I'll attach a file with the complete output of our build-process with Paket 5.213:
build_paket5_213.txt
Do you need another one fpr a run with Paket 5.214? It wouldn't be very long. :-)
Starting task 'DotNet:build': D:\Rhein-Spree\OnfitCode\OnlineDPR\src\OnlineDPR.Application
D:\Rhein-Spree\OnfitCode\OnlineDPR> "C:\Program Files\dotnet\dotnet.EXE" msbuild /version /nologo (In: false, Out: true, Err: true)
<IP_ADDRESS>72
D:\Rhein-Spree\OnfitCode\OnlineDPR> "C:\Program Files\dotnet\dotnet.EXE" build "D:\Rhein-Spree\OnfitCode\OnlineDPR\src\OnlineDPR.Application" --configuration Debug /nodeReuse:False "/bl:C:\Users\Wob\AppData\Local\Temp\tmp7361.tmp.binlog" (In: false, Out: false, Err: false)
Microsoft (R) Build Engine version <IP_ADDRESS>72 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

C:\Program Files\dotnet\sdk\2.1.302\MSBuild.dll -consoleloggerparameters:Summary -distributedlogger:Microsoft....

If you want to test a fix (or have a workaround):

Download Paket.Restore.targets from This PR
Replace .paket/Paket.Restore.targets in your repository
Set the PAKET_SKIP_RESTORE_TARGETS environment variable to true in your CI/locally (in order for Paket/Fake to not replace that file)
Re-run the build

Otherwise wait for the PR to be released and report back.

can you please retry with 5.215.0?

Yes! It's working again! That was quick,  thanks a lot.
We especially take the line "\Paket.Restore.targets(134,5): warning : This version of MSBuild (we assume '15.7.179' or older) doesn't support GetFileHash, so paket fast restore is disabled." as a personal greeting :-)
(And will switch to a newer version soon)


Avoid image load due to co-hosting and CLaSP

There's a long discussion about this, but it turns out that CLaSP relies on MEF metadata that exposes System.Types. This means that MEF must load assemblies in order to produce metadata. Recently, one of our co-hosting endpoints unintentionally pulled in Microsoft.CodeAnalysis.Razor.Workspaces by using a protocol type from MS.CA.Razor.Workspaces as generic type argument. Since, CLaSP loads the type, it had to additionally load MS.CA.Razor.Workspaces to satisfy the generic argument.
The fix is easy -- just don't use that protocol type. However, that's not sustainable and this change has started a conversation about potential re-architecture to CLaSP to avoid eagerly loading assemblies.

Setting automerge to unblock insertion


add zh Upgrading Instruction for v1.7 to v1.8

What type of PR is this?
/kind documentation
What this PR does / why we need it:
add zh Upgrading Instruction for v1.7 to v1.8
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:

CC @RainbowMango ready to merge


Copy import library to PREFIX/lib

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@minrk this is required when not bundling libzmq in zeromq.

Makes sense! Can you bump the build number so it gets updated?


test failed in fedora copr

https://download.copr.fedorainfracloud.org/results/remilauzier/gtk/fedora-rawhide-x86_64/02305147-rust-system-deps/builder-live.log.gz

Looks like it doesn't find the files required to run the tests: src/tests/*/Cargo.toml.
Is copr doing some kind of out of tree build? Does it help with this patch https://github.com/gdesmott/system-deps/commits/test-path ?

Can't test directly since fedora take the source from crate.io.

Can't you run a test build with a specific branch or add a downstream patch? I'd rather not merge this until I'm sure it actually fixes the problem.

It work!
https://download.copr.fedorainfracloud.org/results/remilauzier/gtk/fedora-rawhide-x86_64/02307637-rust-system-deps/builder-live.log.gz

Great, thanks for testing!
I just released 3.1.2 with this fix.


H.264 for Windows Desktop

I need to work with H.264 in Windows Desktop (VP8 works fine, but I need to test H.264).
I read from another issues that H.264 is disabled by default for Windows Desktop because of licencing problems.
The case is, how can I enable H.264 if I am happy to pay for the licence or to test and compare behaviour against VP8?

Option 1. You need to figure out how to rebuild Google's libwebrtc with H.264 support, and then add support to mrwebrtc.dll for that, then expose that to C# via the Microsoft.MixedReality.WebRTC.dll assembly, then expose that in Unity (assuming that's what you use). This is a huge piece of work.

I read from another issues that H.264 is disabled by default for Windows Desktop because of licencing problems.

H.264 is disabled by default in Google's code in the sense it's not even built, and you need I think to flip some flags in gn, possibly more, to enable support, which I think would be via OpenH264. No idea if you need to also build OpenH264 by yourself. I've never tried.
Option 2. The other alternative is figuring out how to port the existing UWP capture and render code to Windows Desktop, then how to use them without their current WinRT bindings. That would allow Windows Desktop H.264 powered by the implementation shipped with Windows 10 through Media Foundation, which doesn't require a license and can leverage hardware encoding/decoding. But again, that's a large piece of work with a different set of problems, mostly around stripping out the WinRT bindings and making sure the Media Foundation code works in Windows Desktop (I'm told it should, never tried). Then you need to inject a custom encoder/decoder factory into the peer connection factory creation, same as what the UWP variant does here:
https://github.com/webrtc-uwp/webrtc-apis/blob/7738cd748902eb55924531b1642347e471b2db24/windows/wrapper/impl_org_webRtc_WebRtcFactory.cpp#L366-L431


feat: Ensure to resolve media URLs

BREAKING CHANGE: Rename fetchMode → getMode

Pull Request Test Coverage Report for Build 210

34 of 34 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-1.4%) to 93.382%

Totals

Change from base Build 201:
-1.4%

Covered Lines:
93

Relevant Lines:
93

💛  - Coveralls


android_background_data flag is missing

Hey,
I do not how far you want to go in the implementation but I think for people who already had a really advanced Android app, this android_background_data flag is the only one which can be used to have the Background Data and it is really useful to bring the notifications to another level.
I'll try to do a short PR if I success implementing it

Fixed by #6


Chrysler: fix steer faults

We had one permanent steer fault on a Jeep in 0.8.14. Looks like this happened right around the minSteerSpeed, so being a bit more careful about commanding torque below the minSteerSpeed should fix this.
JEEP GRAND CHEROKEE V6 2018              9dbe2f39067d71ac|2022-06-18--13-26-34--1

#24878 should be better about steer faults on Chryslers.


add known purpose enum

Related Issues

links https://transcend.height.app/T-41185

Changelog
This just adds an enum for known default purposes (i.e. all non-unknown purposes). This is pretty helpful across the board wherever we try to grab an organization's seeded purposes from the db, since we seed all the configurable purposes plus essential.

nit: I prefer 'well-known' but this works fine


feat: Buckets in the HTTP API (SOFIE-2795)

This PR is being opened on behalf of TV 2 Norge.

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Exposes existing features regarding Buckets over the HTTP API

What is the current behavior? (You can also link to an open issue here)
Buckets and Bucket AdLib management is only available over DDP. Only execution of bucket adlibs is available over HTTP.

What is the new behavior (if this is a feature change)?
The following features are made available over HTTP:

Buckets can be fetched, created, deleted and emptied.
Bucket AdLibs can be imported (through the blueprint ingest flow) and deleted.

Other information:
It is assumed that validation of the payload when importing an adlib is performed by the blueprints.

Status

[x] Code documentation for the relevant parts in the code have been added/updated by the PR author
[x] The functionality has been tested by the PR author
[ ] Automated tests to cover the new functionality and/or guard against regressions have been added
[ ] The functionality has been tested by NRK

@Julusian Those are some very good points about the externalId and variants. Do you agree that when executing a bucket adlib it should also be possible to do so by the externalId? I'd say that it should be the backend's responsibility to find the actual adlib by given externalId, that is also matching the current variant (if set). In that case we could use the externalId as THE id for bucket adlibs both in the LSG and the HTTP API. But that would be a breaking change in regards to playlist's execute-adlib endpoint.

I don't see anything here for retrieving the contents of a bucket. Should that be here?

I'm working under the assumption that since regular adlibs can't be retrieved over HTTP either, the LSG will be used for that purpose, but I'm open to adding it if you think that's necessary.

Thank you all for your input! I believe I have now addressed all the comments.

I have now addressed the remaining comments, resolved merge conflicts, and fixed a bug that I found (incorrect selectors when fetching buckets).


updating to dynatrace-operator 1.3.0 and adding test job

Issue #, if available:
227
Description of changes:
Updated to release 1.3.0 of our operator. cleaned up some api versions and added a testjob. The 10 min intervals might be a bit aggressive for running the job, most examples were only running once a day or so.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Looks like your deployment dynatrace-operator is failing.
Specifically, it looks like these pods are failing:

Pod: dynatrace-operator-6bf8447d8b-cwh68.

Looks like your deployment dynatrace-webhook is failing.
Specifically, it looks like these pods are failing:

Pod: dynatrace-webhook-6b784dd8b9-5l94d.
Pod: dynatrace-webhook-6b784dd8b9-nfj8w.

Looks like your deployment dynatrace-webhook is failing.
Specifically, it looks like these pods are failing:

Pod: dynatrace-webhook-d64f58c9c-b2nzq.
Pod: dynatrace-webhook-d64f58c9c-hrnk2.
Pod: dynatrace-webhook-d64f58c9c-htkvj.

Looks like your deployment dynatrace-operator is failing. Specifically, it looks like these pods are failing:

Pod: dynatrace-operator-6bf8447d8b-cwh68.

Looks like your deployment dynatrace-webhook is failing. Specifically, it looks like these pods are failing:

Pod: dynatrace-webhook-6b784dd8b9-5l94d.
Pod: dynatrace-webhook-6b784dd8b9-nfj8w.

Looks like your deployment dynatrace-webhook is failing. Specifically, it looks like these pods are failing:

Pod: dynatrace-webhook-d64f58c9c-b2nzq.
Pod: dynatrace-webhook-d64f58c9c-hrnk2.
Pod: dynatrace-webhook-d64f58c9c-htkvj.

this is expected unless placeholder values in the yaml are replaced.

Hi @akirasoft1 , I'm running into a slight issue with the success of the Dynakube flux deployment not working based on the files in the addons repo I could use some help with:

Looks like your deployment dynatrace-operator is failing.
Specifically, it looks like these pods are failing:

Pod: dynatrace-operator-6bf8447d8b-jjqbl.

Looks like your deployment dynatrace-webhook is failing.
Specifically, it looks like these pods are failing:

Pod: dynatrace-webhook-d64f58c9c-ljjhg.
Pod: dynatrace-webhook-d64f58c9c-sf67t.

Hi @akirasoft1 , I'm running into a slight issue with the success of the Dynakube flux deployment not working based on the files in the addons repo I could use some help with:

that is expected without replacing placeholder values in the variables.yaml with valid ones (in addition to the creds the operator itself is configured to fetch from secrets there is the apiurl and dynakubename that aren't secrets per se but should not be shared.) you can email me at michael.villiger @ dynatrace.com and I can exchange the

Looks like your deployment dynatrace-operator is failing.
Specifically, it looks like these pods are failing:

Pod: dynatrace-operator-6bf8447d8b-jkwnc.

Looks like your deployment dynatrace-webhook is failing.
Specifically, it looks like these pods are failing:

Pod: dynatrace-webhook-d64f58c9c-gt4g5.

i added the values back into the values file for now. You will need to reach out to me for the secrets values that you will load on your secret store...

i added the values back into the values file for now. You will need to reach out to me for the secrets values that you will load on your secret store...

@akirasoft1 We cannot have hardcoded values in the variables. You can share us the secret via email which can be permanent and create ExternalSecret resource which you should reference in the values. Once you share the secret, We can create Secrets in Secrets Manager which ExternalSecret can reference and render. You can check with our other partner submissions.

i added the values back into the values file for now. You will need to reach out to me for the secrets values that you will load on your secret store...

@akirasoft1 We cannot have hardcoded values in the variables. You can share us the secret via email which can be permanent and create ExternalSecret resource which you should reference in the values. Once you share the secret, We can create Secrets in Secrets Manager which ExternalSecret can reference and render. You can check with our other partner submissions.

yes, all the above is how it was before, I basically reverted changes to the file and updated to a more permanent URL. if someone wants to tell me how to reference secrets inside these fluxcd things i can copy paste?

i added the values back into the values file for now. You will need to reach out to me for the secrets values that you will load on your secret store...

@akirasoft1 We cannot have hardcoded values in the variables. You can share us the secret via email which can be permanent and create ExternalSecret resource which you should reference in the values. Once you share the secret, We can create Secrets in Secrets Manager which ExternalSecret can reference and render. You can check with our other partner submissions.

yes, all the above is how it was before, I basically reverted changes to the file and updated to a more permanent URL. if someone wants to tell me how to reference secrets inside these fluxcd things i can copy paste?

You can check this example or any other example in partner to understand how to handle ExternalSecrets.

Looks like your deployment dynatrace-operator is failing.
Specifically, it looks like these pods are failing:

Pod: dynatrace-operator-6bf8447d8b-jkwnc.

Looks like your deployment dynatrace-webhook is failing.
Specifically, it looks like these pods are failing:

Pod: dynatrace-webhook-d64f58c9c-gt4g5.

i added the values back into the values file for now. You will need to reach out to me for the secrets values that you will load on your secret store...

@akirasoft1 We cannot have hardcoded values in the variables. You can share us the secret via email which can be permanent and create ExternalSecret resource which you should reference in the values. Once you share the secret, We can create Secrets in Secrets Manager which ExternalSecret can reference and render. You can check with our other partner submissions.

yes, all the above is how it was before, I basically reverted changes to the file and updated to a more permanent URL. if someone wants to tell me how to reference secrets inside these fluxcd things i can copy paste?

You can check this example or any other example in partner to understand how to handle ExternalSecrets.

we were using external secrets already for populating a secret the operator needed. i've sent an email, maybe this will work?

Looks like your deployment dynatrace-dynatrace-operator is failing.
Specifically, it looks like these pods are failing:

Pod: dynatrace-dynatrace-operator-6d6f5855d5-sncs9.

Looks like your deployment dynatrace-operator is failing.
Specifically, it looks like these pods are failing:

Pod: dynatrace-operator-6bf8447d8b-qdblc.

Looks like your deployment dynatrace-webhook is failing.
Specifically, it looks like these pods are failing:

Pod: dynatrace-webhook-c989b778c-ms29k.

Looks like your deployment dynatrace-dynatrace-operator is failing.
Specifically, it looks like these pods are failing:

Pod: dynatrace-dynatrace-operator-6d6f5855d5-sncs9.

Looks like your deployment dynatrace-operator is failing.
Specifically, it looks like these pods are failing:

Pod: dynatrace-operator-6bf8447d8b-qdblc.

Looks like your deployment dynatrace-webhook is failing.
Specifically, it looks like these pods are failing:

Pod: dynatrace-webhook-c989b778c-ms29k.

I'm going to kill this PR and open a new one as I have moved to v1.3.2 of the dynatrace operator and I believe I have something that works now.

Looks like your deployment dynatrace-operator is failing.
Specifically, it looks like these pods are failing:

Pod: dynatrace-operator-56b6c4c694-gnlck.

Looks like your deployment dynatrace-webhook is failing.
Specifically, it looks like these pods are failing:

Pod: dynatrace-webhook-795bcc9b47-6fdqn.
Pod: dynatrace-webhook-795bcc9b47-792xf.


Add documentation for the MCL tutorial

Proposed changes
Related to #305 , split from #340.
Type of change

[ ] 🐛 Bugfix (change which fixes an issue)
[ ] 🚀 Feature (change which adds functionality)
[x] 📚 Documentation (change which fixes or extends documentation)

Checklist

[x] Lint and unit tests (if any) pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works
[x] I have added necessary documentation (if appropriate)
[x] All commits have been signed for DCO

@Alondruck Note I didn't forget about any of this. I figured that instead of dropping a billion suggestions, I'd just write down a suggested patch and PR it against your branch. Same for #401. I expect to have them ready today EOD.

@hidmic I've merged your patch into this branch. I think it is ready to be merged into the main!


🐛 fix editor fenced code block handling

closes https://github.com/TryGhost/Ghost/issues/8695

non-spellchecker mode should be "gfm" not "markdown" so that fenced
code blocks are displayed correctly and other markdown behaviour better
matches the preview/rendering

Coverage remained the same at 73.553% when pulling e091b81f010ea9758f5b12da0019908d753cff2a on kevinansfield:fix-editor-code-blocks into 69539563c766d87e6825e92ae0b223c62a259429 on TryGhost:master.


Backtrack is breaking DT and my real ping

When i activate backtrack above 300, it breaks the dt bar and my real ping goes to (backtrack level), the scoreboard ping goes up independent of the amount that i put on the menus and auto duck also breaks too

Use the template


Automated Package Upgrade

:tada: This PR is included in version 7.7.257 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Improve SDP offer-answer exchange

This is needed to

allow clients to declare the streams they want to send
support simulcast #3

The current approach is to save ourselves from SDP weirdness by limiting its usage to the bare minimum and do the actual negotiation with our custom protocol

Actually a similar task is located in membraneframework/membrane_webrtc_plugin#10 and it seems that it is more related to membrane_webrtc_plugin than to membrane_sfu. Maybe we should merge this task with the task mentioned above?

Good point, closing


Remove Backup/Restore endpoints

Description
The current implementation of backup/restore is really more similar to "dump" in various databases. For now we want to remove these endpoints so that we don't have to provide support for what is likely an unnecessary feature. The goal is to follow up this removal with a well planned backup/restore feature that is cluster-aware and adheres to acceptable backup strategies.
Success criteria (What criteria will consider this ticket closeable?)
The backup/restore endpoints (and internal handlers) are removed, and ideally a new issue is created to plan/propose a true backup/recovery feature.

Starting over on backup/restore functionality will allow us to consider https://github.com/pilosa/pilosa/issues/725 and other proposals.


Route match action should receive parsed segments

There's very little point in having a route matcher that does not (1) regard the values obtained by riot.parser.fn1 and (2) inconsistently produces callback function parameters.
Eg:
riot.route('/fruit/*', function(name) { /* */ })
riot.route('/fruit/apple', function() { /* */ })
riot.route('/fruit/orange', function() { /* */ })

Not only is there a name parameter JUST for wildcard matching, but this setup requires fruit as the bare minimum abstraction.
Expectedly, all route callbacks should plug into the values obtained by parser.fn1. In the default scenario, this looks like:
riot.route('/fruit/*', function(collection, id, action) { /* */ })
riot.route('/fruit/apple', function(collection, id, action){ /* */ })
riot.route('/fruit/orange', function(collection, id, action) { /* */ })

Of course, some parameters may still be undefined, but at least you can always expect a set of parameters in the callback.
My second point: We have to have a full set of routes just for fruit, and will have to repeat the same set for cars and another for trees, etc.
This practice only makes sense when you're designating routes for a specific tag or a specific set of tags. This same practice prevent you from having a succinct, global level routes declaration.
The same solution allows for:
// (1)
riot.route('..', function (collection, id, action) {
  // ..
});

// (2)
riot.route('fruit/apple/..', function (custom, parser, args) {
  // .. long-tail url, read it
});

(1): While this isn't a recommended only solution, it allows for a nice last resort/"catch-all" which has the power to run its own logic based on params
(2): Dependent on our desired URL structure (and appropriate parser fn), we can allow for deep, complex URLs and handle them all at once without having to declare multiple blocks, repeating boilerplate.
Anyway, Issue getting a bit long here. If this is approved, I have the matching PR ready to be opened. It's a simple 2-line fix

Closing this issue because it's related to an old router version. Please update to the latest @riotjs/route version if you can.


Move kv and llm instrumentation up a level of abstraction

This is to make it so we don't need to pass the observe context all the way down the stack.

@lann marking you for review.


Bug or Feature: directly assign 'true' to delay_alloc of Chunk rather than using input param delay_alloc_?

Description
I'm confuse about the coding here:
/*! \brief construct a new chunk */
Chunk(mxnet::TShape shape, Context ctx_, bool delay_alloc_, int dtype)
 : static_data(false), delay_alloc(true), ctx(ctx_),
    storage_ref_(Storage::_GetSharedRef()),
    engine_ref_(Engine::_GetSharedRef()) {
  storage_shape = shape;
  if (shape_is_known(storage_shape)) {
    shandle.size = shape.Size() * mshadow::mshadow_sizeof(dtype);
  }
   var = Engine::Get()->NewVariable();
   shandle.ctx = ctx_;
   if (!delay_alloc_) {
     this->CheckAndAlloc();
   }
  }

here is source code
question
why not assign delay_alloc_ to delay_alloc?

Nice catch. Looks like a bug to me. @ooooona thanks for reporting. Would you like to open a pull request and fix the bug?

Seems to be introduced by #14223

Nice catch. Looks like a bug to me. @ooooona thanks for reporting. Would you like to open a pull request and fix the bug?

sure, i will try it later today :)

Thank you for pointing it out : )
It is a confusing variable name, but it is not a bug.
The meanings of decay_alloc_ and decay_alloc are different.
The former decay_alloc_ is an argument to decide whether the chunk need to decay-allocated.
But the later decay_alloc is the state whether the memory has not been allocated.
For the two cases decay_alloc_ is true or false,

When the argument decay_alloc_ is true,

decay_alloc = true;
the condition if (!delay_alloc_) does not be satisfied.

When the argument decay_alloc_ is false, the following steps will be executed:

decay_alloc = true;
The condition if (!decay_alloc) is satisfied, then the function CheckAndAlloc() be called.
Allocate the memory for the chunk, then decay_alloc is set as false.
https://github.com/apache/incubator-mxnet/blob/b54b7f36c944b933f2aa94f224821548da5fcaf6/include/mxnet/ndarray.h#L1018-L1026

CheckAndAlloc() will allocate memory when decay_alloc is True.
Therefore, decay_alloc should be true whenever decay_alloc_ is true or false.


Build a separate ObfuscationAnnotation jar

(Have a look at 2.8.0 distribution)

Closed by 80441b0228e0d1282f1811652167ecec9817d83c


looks like snake_hash is forcing the keys to be symbols

 def snake_hash(value)
    Hash[value.map { |k, v| [underscore_key(k).to_sym, to_snake_keys(v)] }]
  end

That to_sym in there is changing all my string keys to symbol keys, I think.  And it looks like this would fail your tests.

Same problem here, and I agree with your conclusion, that to_sym should not be there

This has now been resolved in commit https://github.com/futurechimp/plissken/commit/d5b8109b60cdfd317117cf292b5210adf34b46bd. Will close this when a new release is made.

1.0.0 of this Gem has been pushed with the fix for this in so am closing...


Module download freezes if TFHUB_CACHE_DIR is a GS Bucket

Hi! As discussed in #48, I tried to set TFHUB_CACHE_DIR to a gcp bucket and while there is no error, the code freezes here while downloading the module. For example, if you have this setup
bash
export TFHUB_CACHE_DIR="gs://<SOME_BUCKET>/tfhub_cache_dir"
python main.py

main.py
import tensorflow_hub as hub
#resnet_v2_101 for example
hub.Module("https://tfhub.dev/google/imagenet/resnet_v2_101/feature_vector/1")

the code should get stuck after this log

Using gs://<SOME_BUCKET>/tfhub_cache_dir to cache modules.

Current implementation doesn't support caching modules to GCS. We will
investigate the failure mode though. If a bad/incompatible path is provided
the library should error out not hang
On Mon, May 14, 2018 at 8:00 PM Cristian Garcia<EMAIL_ADDRESS>wrote:

Hi! As discussed in #48 https://github.com/tensorflow/hub/issues/48, I
tried to set TFHUB_CACHE_DIR to a gcp bucket and while there is no error,
the code freezes here while downloading the module. For example, if you
have this setup
bash
export TFHUB_CACHE_DIR="gs://<SOME_BUCKET>/tfhub_cache_dir"
python main.py
main.py
import tensorflow_hub as hub#resnet_v2_101 for example
hub.Module("https://tfhub.dev/google/imagenet/resnet_v2_101/feature_vector/1")
the code should get stuck after this line print on the terminal
Using gs://<SOME_BUCKET>/tfhub_cache_dir to cache modules.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tensorflow/hub/issues/50, or mute the thread
https://github.com/notifications/unsubscribe-auth/AbunTEMb_b2GAbtrQFHMYV4K2elZ8qrKks5tykTCgaJpZM4T-0IU
.


asc Playlist / QueueList

Playlist / QueueList is currently displayed in descending order, but I would like an option to make it ascending.

This is a hard decision, as ascending order will breaks current UI design (especially to the "next on" label), unless you want to change the layout entirely.

Speaking of which, the Japanese translation of the "next on" label is unintelligible." The translation meaning "next" is used, and the player clicks on it expecting "the next video to play," but then wonders why nothing happens.

That is for indicate which will play next (also as a hint for the order of the list), and additionally if you click on it it just jump to the entry that will actually playing.

Wouldn't "playing" etc. be easier to understand in terms of function? Because the function is to focus on what is playing when clicked.


Which fields are needed in the AREA table?

Which data fields that are common to polygon attribute tables, should we persist in the AREA table? e.g. centroid, land area, water area, CBSA, fips code, etc

WG: Remove centroid_x, centroid_y, datum


Please confirm these before moving forward

[X] I have searched for my issue and not found a work-in-progress/duplicate/resolved issue.
[X] I have not been informed if the issue is resolved in a preview version of the winget client.

Category of the issue
Installation issue.
Brief description of your issue
I want to install older version of OpenJS.NodeJS. However winget cannot install it because of url issue.
Steps to reproduce
winget install openjs.nodejs -v 21.2.0
Actual behavior
An unexpected error occurred while executing the command:
Download request status is not success.
0x80190194 : Not found (404).
Expected behavior
Install older version of nodejs successfully
Environment
Windows Package Manager v1.6.3133
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22621.2715
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.21.3133.0

Winget Directories
-----------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Diag…
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\sett…
Portable Links Directory (User)    %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User)       %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root              C:\Program Files\WinGet\Packages
Portable Package Root (x86)        C:\Program Files (x86)\WinGet\Packages
Installer Downloads                %USERPROFILE%\Downloads

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Disabled

Screenshots and Logs
https://github.com/microsoft/winget-pkgs/blob/master/manifests/o/OpenJS/NodeJS/21.2.0/OpenJS.NodeJS.installer.yaml
https://nodejs.org/dist/latest/node-v21.2.0-x86.msi
This link does not exist because the latest version of nodejs is not v21.2.0
This link should be fixed as
https://nodejs.org/dist/v21.2.0/node-v21.2.0-x86.msi
This problem can be found in  v21.3.0, v21.2.0, v21.1.0
Please notify this issue to the contributor who commits this wrong URL.

Visit Homepage of Nodejs in browser manually, both latest LTS and Current versions are provided with a "version related folder" instead of just "latest folder".

It's wierd contributors are submitting manifests with /dist/latest/ folder as part of the installer URL.


rpmsg_virtio: move rpmsg virtio cmd definition before the resource table

Summary
use reserved[2] in struct resource_table as the command, avoid the resource table format do not follow the standard.
Impact
rpmsg virtio
Testing
qemu-armv7a with rpmsg_virtio enabled

[Experimental Bot, please feedback here]
This PR does not meet the NuttX requirements. Here's why:

Insufficient Summary:

The summary is vague and doesn't explain:

Why the change is necessary. What specific problem does it solve?
How the change works in detail. What does "resource table format do not follow the standard" mean?

Incomplete Impact Assessment:

Feature Changes: Is this a new feature or a modification of an existing one?
User Impact: Will users need to adapt to this change? Be specific.
Build Impact:  Will the build process change (new dependencies, configuration options)?
Hardware Impact: Which architectures, boards, or drivers are affected?
Documentation Impact: Does the documentation need updating? Is updated documentation included?
Security Impact: Are there any security implications?
Compatibility Impact: Are there any backward, forward, or interoperability concerns?

Lack of Testing Details:

Build Host: Specify the operating system, CPU architecture, and compiler version used for testing.
Target Details:  Provide the architecture, board, and configuration used for testing.
Missing Logs:  Include relevant testing logs from before and after the change to demonstrate the issue and the fix.

To improve this PR:

Expand the Summary: Provide a clear and detailed explanation of the problem, the solution, and the specific changes made.
Complete the Impact Assessment: Address all impact categories with specific details.
Provide Thorough Testing Information: Include build host, target details, and relevant testing logs.

By addressing these points, you can significantly improve the quality and clarity of your PR, making it easier for maintainers to review and merge your changes.


Update overview.md

Updated Swiss regions Geo backups

Learn Build status updates of commit dbf8f33:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

articles/postgresql/flexible-server/overview.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

#sign-off

I am part of Azure Product Team and report to @sunilagarwal. I am responsible for making doc changes. PLease treat this as sign off and merge it


#209 Add onBeforeRequest and onAfterResponse to terminate method

Call onBeforeRequest and onAfterResponse inside the terminate method.

Thank you very much for this PR! One small nitpick: The onAfterResponse callback should be invoked after every requests, regardless of the status code. With your PR, it will only be called if the status code is 204, but in the rest of tus-js-client, the callback is invoked also for error responses: https://github.com/tus/tus-js-client/blob/master/lib/upload.js#L841


Various issues on MacOS

I am new to machine embroidery, but have been looking for good libraries to help programatically generate patterns.
This library looks wonderful - so I cloned it and attempted to play with it locally.
I am a mac user and the cli tool compiles. However when running it there are a lot of issues that it's difficult for me to isolate and diagnose.

-to flag fails with Please enter an output format for your file, see --help. this is using the command embroider -t dst cmmn.jef

--test and --full-test-suite fails with [1]    61997 segmentation fault  ./embroider --test

--render fails with:
228
[1]    62063 segmentation fault  ./embroider -r cmmn.jef test.png

Basic conversion passes without seg faults -  using the command emboider cmmn.jef cmmn.txt. However, converting to csv is showing indications of where segfault may be coming from as the "description"  field for threads are showing some weirdness:
"#","[THREAD_NUMBER]","[RED]","[GREEN]","[BLUE]","[DESCRIPTION]","[CATALOG_NUMBER]"
"$","1","115","58","0","    -c, --circle     Add a circle defined by the arguments given to the current  to the current ��","rguments given to the current  to the current ��"
"$","2","0","0","0","Black","Black"

and for another file it gives:
 "#","[THREAD_NUMBER]","[RED]","[GREEN]","[BLUE]","[DESCRIPTION]","[CATALOG_NUMBER]"
 "$","1","101","100","32","under the terms of the zlib license.

     https://github.com/Embroidermodder/lib","github.com/Embroidermodder/lib"
 "$","2","45","100","105","fat.c bcf_difat_create(), Unexpected sector value %x at DIFAT[%d] ","%x at DIFAT[%d]"
 "$","3","0","0","0","END","END"

In good news embroider -F and embroider --help is working as expected.

My basic hardware settings are:
  Model Name:	MacBook Pro
  Model Identifier:	MacBookPro16,1
  Processor Name:	8-Core Intel Core i9
  Processor Speed:	2.4 GHz
  Number of Processors:	1
  Total Number of Cores:	8
  L2 Cache (per Core):	256 KB
  L3 Cache:	16 MB
  Hyper-Threading Technology:	Enabled
  Memory:	32 GB

Running OSX 12.6
Let me know if there is any other information that would be helpful to provide?
I am interested in your project and would love to contribute anyway I can. Not a solid C developer.

Hi @e-e-e
It's good to hear from someone interested in our project, especially under the hood. How did you discover the project? I've have a bunch of messages in the last 4 days and I don't know why. I assume it's some content aggregator.
The library is very much in development (version 1.0 has no planned release date since it's pretty much just me writing it at the moment and we don't get a lot in donations), so there will be bizarre segfaults and stack overflows. The best way to report them is as separate issues with backtrace. For example the valgrind output from:
$ valgrind ./embroider --test

along with the description of your system. If you've compiled with the debug symbols (this is the default) then it should give you specific line numbers. Another option is the GNU debugger which is
$ gdb --args ./embroider --test

which drops you into a new shell where you can inspect the runtime during execution. The commands r and bt will run and backtrace your program respectively.
So your report here would be more like 4 reports. Which would be a back and forth as we try to fix them.
Help with documentation is also useful at the moment, but that is housed on our other repository https://github.com/Embroidermodder/embroidermodder in the docs folder.
Is there anything in particular that you'd really like to see this library do?
Cheers,
Robin

Thanks for getting back so quickly @robin-swift. I did have a quick look at the latest commits and figured you were early stages, and still very much WIP. I hoped sharing the issues I found might be helpful.
I ended up at this project through looking at embroidery formats - thinking I would have to hack something myself, then I found inksketch and the lovely work on pyembroidery by @tatarize. Their project cites the origins as coming from this work via the java implementation.
I have been toying with the idea of building a little ipad app to help me generated embroidery from drawings, but obviously python and ios is not a natural fit, so I started to dig into your project to see where it was at. Did not want to reinvent the wheel, and thought that I may be able to help contribute to another projects development.

Is there anything in particular that you'd really like to see this library do?

Ideally all I have been looking for is a simple way to translate low level commands into common embroidery formats.
The preview and simulation features are useful.
As for the bugs above - I will see if I can get stack trace information using the instructions you have provided and open separate issues here. Once I open them I will close this issue.
Thanks so much for open sourcing your work. I really appreciate the labour in support of the commons.

Oh man, I left this real broken. So the original intension was to share a lot of code between the embedded (i.e. embroidery machine) code, the C library and the CLI. So what I had done was separated out a bunch of data into CSV files to reduce the compiled binary size but haven't finished setting up how to access that data.
My latest commit fixes the to flag parsing which was just missing. I'll have a look at those segfaults.

As for the bugs above - I will see if I can get stack trace information using the instructions you have provided and open separate issues here. Once I open them I will close this issue.

The last commit should fix some more problems: be sure to git pull before you do more testing.


Commands not completing

I am running zsh on a remote server (Ubuntu 14.04) that I access through ssh. I am using a default installation without any special configurations yet. Everything works fine in the directories that I own but in some directories owned by others (but that I have read access to) I get some weird behavior.
If I try to change to one of those directories (e.g. /home/other_user) the command does not seem to execute and the cursor just goes to a new line without showing the prompt. Hitting CTRL-C will give me the old prompt again (e.g. /home/me) but the directory did actually change to the requested one in the background. So while the prompt displays the original directory, any command executed will be done in the other directory.
Running a simple command like ll does almost the same thing: you get the output of the command but no prompt, the only way to get the prompt back is by hitting CTRL-C.
Do you have any idea what could be causing this behavior?

Hi @rwinand !
Thanks for the report. Interesting. I quickly created a folder and set permissions to executable only (in all variations: owner, group, others), but was not able to reproduce that issue. Could you elaborate more on what are the exact rights that the other folder has? Do you use ACL?
And do you use any ZSH framework? Does it happen without / another framework?

What versions of zsh and ssh are you using?

Welcome, @rwinand! Just a ping on @dritter's and @onaforeignshore's questions :)

I apologize for the late reply, I went for on a long weekend after posting this and probably should have posted this when I got back ...
To answer your questions: I am using Oh My Zsh but it also happens when I try it with a vanilla zsh installation. The version of zsh I am using is 5.0.2 (default one in Ubuntu 14.04) and I am connecting to an OpenSSH server version 6.6.1p1.
We are not using ACL. I have also found now that the folders that I have troubles with are all children from one user's /home folder which is set to permission 755 and owned by other_user:other_group. Other folders owned by that same user and group but which are not located under /home/other_user work fine (for the ones I tested up to now at least). I tried changing the permissions but that doesn't solve the problem. Also, home folders for completely different users (and groups) don't have this issue.

I think I may have found the cause. The user home directory that I have the issues with is a directory with a git repo but one with a subtree. So there is data from two git repos from different servers in that one directory. This is the only difference that I could find between all the directories that I checked.

@rwinand - Thanks for getting back to us!
Yeah, the subtree thing really ought to work, as ZSH's VCS_INFO module is supposed to be able to deal with those. If no one can recreate this, including you, we might have to close this one :-/
What about the permissions on the .git/ folder and .gitmodules in the directory?

Just a ping on this! :)

Going to close this one due to inactivity. Feel free to re-open, @rwinand! =)


Optimize keyboard shortcuts display for improved user experience

The multitude of keyboard shortcuts on the shortcuts tab can be overwhelming and difficult to navigate due to the sheer volume. Additionally, the extensive list makes the tab excessively tall, occupying a significant amount of screen space.
Several potential solutions could address this issue:

Relocate keyboard shortcuts within the application to a more accessible location.
Transfer keyboard shortcuts to the README file, removing them from the app interface.
Implement a popup feature that displays the keyboard shortcuts when needed, thereby reducing clutter on the main interface.

Solved by 79bc3d68b168a199411f03eef4fd00432b6da6b5, cabc36af9a05021951046a2eee390bd59ecc0ebb and a401b2eaa883e356c6d5399679c2375a401382eb.


Error not showing up consistently on STOP_ASYNC_VALIDATING action

Hey, love the repo, its been really awesome so far. Maybe I'm missing something but I have a check email exists validator that seems to only return errors the second time it is run. Synchronous validation works perfectly but when I reject the promise with Async validate it doesn't always show the error. Here's the code I am using.
const asyncValidate = (data, dispatch, props) => {
  return new Promise((resolve, reject) => {
    const deferred = new Promise((res) => {
      res(dispatch(checkEmail(data.email)));
    });
    deferred.then(() => {
      if (props.emailExists) {
        reject({email: 'This email has already been taken'});
      } else {
        resolve();
      }
    });
  });
};

and here is the component.
@reduxForm({
  form: 'register',
  fields: ['email'],
  asyncValidate,
  asyncBlurFields: ['email'],
  validate: registerValidation
}, null, {register, checkEmail})
export default class RegisterForm extends Component {
  static propTypes = {
    asyncValidating: PropTypes.string.isRequired,
    uuid: PropTypes.string.isRequired,
    fields: PropTypes.object.isRequired,
    handleSubmit: PropTypes.func.isRequired,
    register: PropTypes.func.isRequired,
    checkEmail: PropTypes.func
  }
  handleSubmit = (data) => {
    console.log(data);
    this.props.register(data.email, this.props.uuid);
  }
  render() {
    const {fields: {email}, handleSubmit, asyncValidating} = this.props;
    return (
      <form>

Register Today

        <TextField {...email} hintText="Enter your email" floatingLabelText="Email" errorText={email.touched && email.error ? email.error : ''} />
        {asyncValidating === 'email' && Validating}
        <button className="btn-primary btn m-t-1" onClick={handleSubmit(this.handleSubmit)}>Submit</button>
      </form>
    );
  }
}

Any help much appreciated, been trying to fix this for a few days and am still confused. Also Im using this with a project based off of react-redux-hot-example if thats any help.
Thanks!

Figured it out! In case anyone is wondering, you have to return the current state inside the action creator after the promise!


BIGTOP-3827. Skip dh_strip_nondeterminism for HBase, Phoenix and Zeppelin

https://issues.apache.org/jira/browse/BIGTOP-3827
Deb packaging of HBase, Phoenix and Zeppelin looks time consuming due to shaded jars. We can skip dh_strip_nondeterminism as done for Hadoop and Spark in BIGTOP-3623 (#1012).

Megerd, thanks @iwasakims


added missing nindent arg in imagePullSecrets

What this PR does / why we need it?
Fixes not working deployment.yaml template if using imagePullSecrets param
PR Checklist

[ ] This PR adds K8s exceptions (false positives)
[x] This PR adds new code
[ ] This PR includes tests for new/existing code
[ ] This PR adds docs

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 43.43%. Comparing base (6d80b66) to head (a86b757).
Report is 2 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main     #394   +/-   ##
=======================================
  Coverage   43.43%   43.43%
=======================================
  Files          63       63
  Lines        4043     4043
=======================================
  Hits         1756     1756
  Misses       2039     2039
  Partials      248      248

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

@nemcikjan please bump the chart version and regenerate the Readme using https://github.com/norwoodj/helm-docs

@yonahd when do you expect the new chart version to be released?

@yonahd when do you expect the new chart version to be released?

Hey
Currently we don't have a process to release a new chart version separately from the application. We are looking into adding this ability but until then it will wait w the next release which should be in the next couple weeks


Out of Date Screeenshot

The screenshots in this document appear different from what it shows in the portal.

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

ID: 451e3982-75f3-aa8c-9aab-6704c77fecb0
Version Independent ID: 8c03b201-2d67-cbb6-92ca-1362c7d3f58f
Content: Use diagnostics settings for Recovery Services vaults - Azure Backup
Content Source: articles/backup/backup-azure-diagnostic-events.md
Service: backup
GitHub Login: @AbhishekMallick-MS
Microsoft Alias: v-abhmallick

@vish668
Thanks for your feedback! We will investigate and update as appropriate.

@vish668 - Thanks for your dedication to our documentation. Unfortunately, at this time we have been unable to review your issue in a timely manner and we sincerely apologize for the delayed response. We are closing this issue for now, but if you feel that it's still a concern, please respond and let us know. If you determine another possible update to our documentation, please don't hesitate to reach out again. #please-close


[Task]: update snappy-java dependency for CVE

What needs to happen?
Snappy java has a high CVE https://avd.aquasec.com/nvd/cve-2023-43642
Issue Priority
Priority: 2
Issue Component
Component: Transforms

.take-issue


Game board builder field disappears

When the user clicks on the id field, and then the name field, and then the id field. the name field disappears.

Fixed during redesign of board builder.


about import

If I want to use 'youtube-dl.py' in my own python program, how can i do it?
import it?
and then @@?
is there any documention for developer to use youtube-dl.py in their own program?
thx for answer
and sorry for my bad english
thx!

Currently, youtube-dl is not ready to be imported as a Python module, but we're working on it (Since there was no issue to track progress of the API-ification, I'll leave this one open).
What you can do is execute youtube-dl as a subprocess. See #152 for plans on a formal shell API (mainly for php).


Upgrade tests should be automated

Current upgrade tests are quite limited - it's just a smoke test that traffic is received from an external client. They should be expanded to include dual control plane scenario, as well as increasing the complexity of the test case itself.

@ostromart What is the work left for 1.8? Shall we push it to 1.9?

This is done now, closing.


Wrong Quarkus config properties used in the Deploy Microprofile article

Learn Build status updates of commit 15b7bcf:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

articles/java/eclipse-microprofile/deploy-microprofile-quarkus-java-app-with-maven-plugin.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

@KarlErickson,
Can you review the proposed changes?
IMPORTANT: When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

@KarlErickson,
Can you review the proposed changes?
IMPORTANT: When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

@loicmathieu thanks for the update!


tinygo: 0.16.0 -> 0.23.0

Motivation for this change
Bumped version.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

this fails to build for me
nix profile install github:muscaln/nixpkgs/tinygo-0.22.0#tinygo
error: builder for '/nix/store/6lhjxxk64x2g011kayci09919cvv439y-tinygo-0.22.0.drv' failed with exit code 2;
       last 10 log lines:
       >          ^~~~~~~~~~
       > /build/source/lib/compiler-rt/lib/builtins/fp_lib.h:24:10: fatal error: 'stdint.h' file not found
       > #include <stdint.h>
       >          ^~~~~~~~~~
       > 1 error generated.
       > 1 error generated.
       > 1 error generated.
       > error: failed to build /build/source/lib/compiler-rt/lib/builtins/absvsi2.c: exit status 1
       > FAIL
       > make: *** [Makefile:311: smoketest] Error 1

sorry I know this is still draft, but i am interested in getting this merged

I didn't notice this PR before creating my own: https://github.com/NixOS/nixpkgs/pull/167556.

Sorry for my late response...
@eliasnaur I imported fixes from your PR.  Thanks!
wasm target is broken rn because I couldn't find a way to compile wasi-libc. smoketest reported no errors(except wasm). Also tested avr target and it works as expected.

I'll try to test this and #167556 on Monday.

Fixed wasm target. Cross compilation to Windows and Darwin are still broken. :(

There's been some changes to GCC and related in staging, I'm not sure about mingw with windows, but might Darwin work now?

Please add broken = stdenv.isDarwin; to meta.
Otherwise, seems to work.

Result of nixpkgs-review pr 157129 run on x86_64-linux 1

1 package built:

tinygo

From https://hydra.nixos.org/build/176125851/nixlog/3
tinygo.org/x/go-llvm
# tinygo.org/x/go-llvm
ld: library not found for -lcurses
clang-11: error: linker command failed with exit code 1 (use -v to see invocation)
crypto/sha512
github.com/google/shlex
go/token
go/scanner
go/ast
golang.org/x/tools/go/ast/astutil
github.com/tinygo-org/tinygo/cgo
# github.com/tinygo-org/tinygo/cgo
ld: library not found for -lffi
clang-11: error: linker command failed with exit code 1 (use -v to see invocation)
go/internal/typeparams
go/parser

We're already including libffi so that should be alright, we need to do something about -lcurses though for x86_64-darwin.

Included all libraries mentioned in this file. curses is just a symlink to ncurses in brew formula :) I can't test the build but it should.

Result of nixpkgs-review pr 157129 run on x86_64-darwin 1

1 package failed to build:

tinygo

❯ nix log /nix/store/ya970amnnyl40vdfbm59wd5q19g9c34s-tinygo-0.23.0.drv | ix
http://ix.io/3Y70

Thanks for testing. It looks like buildGoModule copy vendor directory  in configurePhase. I just moved the part of the code that edit these files on darwin.

@muscaln https://github.com/NixOS/nixpkgs/pull/157129/checks?check_run_id=6502744314
Anything you can do about this? I think brew may need to be included?

@muscaln https://github.com/NixOS/nixpkgs/pull/157129/checks?check_run_id=6502744314 Anything you can do about this? I think brew may need to be included?

Makefile uses brew to figure out where LLVM is installed which is pointless for us. Removed that code with Makefile patch.

Huh, so ofborg does actually build per-platform, I had no idea.
https://logs.nix.ci/?key=nixos/nixpkgs.157129&attempt_id=09a7a3cd-f3f2-4073-88b1-fae059976db6
I think this may be the issue.
https://github.com/NixOS/nixpkgs/blob/cb82f16de86f12025d157a1f64a2f5ae617edf93/pkgs/development/compilers/tinygo/default.nix#L93-L96

@Madouura you don't need to re-approve after every force push. If the changes are small we usually assume that it is fine.

@Madouura you don't need to re-approve after every force push. If the changes are small we usually assume that it is fine.

Ah okay thanks, it was getting annoying anyway. :laughing:

Looks like we're missing xar for darwin now.
https://logs.nix.ci/?key=nixos/nixpkgs.157129&attempt_id=2ea686ba-ef8b-47e0-a0e7-c4ea7a4611dc

This time, we can't find the build ID on Darwin.
https://logs.nix.ci/?key=nixos/nixpkgs.157129&attempt_id=20bebacb-bdc3-4696-9310-1e3fbc8154eb

This time, we can't find the build ID on Darwin. https://logs.nix.ci/?key=nixos/nixpkgs.157129&attempt_id=20bebacb-bdc3-4696-9310-1e3fbc8154eb

Added a patch for it. Let's see what ofborg say.

Still can't find the build ID.
https://logs.nix.ci/?key=nixos/nixpkgs.157129&attempt_id=9ef61dd5-f64e-41e5-90a6-1d4da1fad16b

Just mark Darwin broken at this point, I'd say.


Reuse allocations in hashing functions

Description
Related code:
https://github.com/spacemeshos/go-spacemesh/blob/591c4c06b681720e96987adfa6d94bd643521468/hash/hash.go#L16-L23
See https://github.com/spacemeshos/go-spacemesh/pull/5784/files/28480f57981d97fcc5a31a200cddd7136be4de66#r1553551388 for details.

Duplicate of https://github.com/spacemeshos/go-spacemesh/issues/5850


Add fallback to sorting build meta for determinism

Constraints don't work in this PR and aren't easily supported on top of the library code. Closing in favor of forking the library and implementing there.


iso-image: Fix GRUB graphical menu on AArch64

This is going to get a bit confusing later on. Be warned.
First, there's a commit to introduce a hidden menu entry option to GRUB. The patch comes from the upstream mailing list. The patch is used by SUSE for the same purpose we'll be using it, to provide a hotkey to force the "console" GRUB menu to be used.
The second commit fixes file paths. They were prefixed with (hd0), which turns out is not needed here. The EFI volume used for boot is already the "PWD".
The third commit introduces the required changes so that the console interface can be used. And here's where it gets confusing. GRUB supports the serial interface, which is for when GRUB itself speaks to a serial device. On AArch64, serial interfaces with U-Boot will not be used by GRUB itself. Rather, the console is present. The console is the text interface provided by the UEFI firmware. So this change is a total no-op for serial users, like qemu ... -serial mon:stdio.
The last two commits are about rEFInd. There was an uninvestigated issue with the rEFInd entry. It wouldn't work on qemu, when the image was used as a -cdrom. Turns out GRUB apparently cannot chainload the EFI program from (cd0). The same issue can be observed on U-Boot on AArch64. The first commit adds rEFInd for AArch64, the second hides the menu entry from being shown in "cd" situations, where GRUB wouldn't be able to load it.
Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

And:

Tested with qemu and OVMF.
Tested on misc. SBCs with U-Boot's UEFI implementation

Currently draft since I've just realized how to fix the rEFInd menu option for AArch64. Won't work, but it's not an AArch64 issue.

Result of nixpkgs-review pr 119974 at f63fcccc run on aarch64-linux 1

2 packages failed to build:

grub2_pvgrub_image
grub2_xen

3 packages built successfully:

grub2 (grub2_full ,grub2_light)
grub2_efi
woeusb

Note that build failures may predate this PR, and could be nondeterministic or hardware dependent.
Please exercise your independent judgement.

I'll merge this soon unless someone has issues with the changes.
It'll unblock the next PR on the chain of PR (#121450).
Note that a further PR will still be needed for using the UEFI iso on many ARM targets, which is still WIP due to long-winded testing.


Documentation mismatch with NPM release -- RouterContext doesn't exist

Clicking the v1.0.2 release tag, it's clear that the change from RoutingContext -> RouterContext didn't make the release. That's really confusing though, because the docs clicked from the README are ahead of what's actually released. I suppose it's partially my fault for not selecting the proper release tag on Github before reading the docs, but I think it's probably an error most users would make.
As a side question, I also would have figured this issue out more quickly had my ESLint setup and my Babel set up flagged the importing of the nonexixstent RouterContext as an error, instead of blowing up at runtime. The basic ESLint checks don't catch this because there's no way for ESLint to know whether an import will exist or not. Does anybody know if and how such a static check could be enabled?

(The story of how I figured out what's going on, in case anybody else runs into something similar)
I installed react-router with the suggested method in the README. Following the docs on server-side rendering, I was attempting to set up my pre-rendering using the match -> RouterContext methodology, but I got an error with the following stack trace:
Error: Invariant Violation: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: undefined. at invariant (/Users/alan/projects/prediction/node_modules/react/node_modules/fbjs/lib/invariant.js:39:15) at [object Object].instantiateReactComponent [as _instantiateReactComponent] (/Users/alan/projects/prediction/node_modules/react/lib/instantiateReactComponent.js:64:134) at [object Object].ReactCompositeComponentMixin.mountComponent (/Users/alan/projects/prediction/node_modules/react/lib/ReactCompositeComponent.js:223:36) at [object Object].wrapper [as mountComponent] (/Users/alan/projects/prediction/node_modules/react/lib/ReactPerf.js:66:21) at /Users/alan/projects/prediction/node_modules/react/lib/ReactServerRendering.js:42:38 at ReactServerRenderingTransaction.Mixin.perform (/Users/alan/projects/prediction/node_modules/react/lib/Transaction.js:136:20) at renderToString (/Users/alan/projects/prediction/node_modules/react/lib/ReactServerRendering.js:40:24) at /Users/alan/projects/prediction/server/home/index.js:63:27 at run (/Users/alan/projects/prediction/node_modules/babel-core/node_modules/core-js/modules/es6.promise.js:104:47) at /Users/alan/projects/prediction/node_modules/babel-core/node_modules/core-js/modules/es6.promise.js:115:28

I couldn't find any solid info when searching for help, but I eventually realized when examining node_modules that there was no RouterContext module:

Yeah we tried to address this a bit in https://github.com/rackt/react-router/issues/2650 and https://github.com/rackt/react-router/commit/088f1d53945f739628aeebfc00809fae8c332035 but it should be a more obvious warning à la https://github.com/kubernetes/kubernetes/tree/master/docs#readme.

The link on the README points to latest, which is part of our release script. Wonder why its out of sync.

The problem is that a naive search on e.g. Google drops you to https://github.com/rackt/react-router/tree/master/docs, which has no explicit caveat that it isn't talking about the current release.
This will be less of an issue once we have a proper docs page.
Also, it's sorta easy to accidentally end back up on master.

BTW, k8s has that warning in every doc entry on master: https://github.com/kubernetes/kubernetes/blob/master/docs/getting-started-guides/coreos/bare_metal_offline.md.

Well, doesn't matter now that 2.x-rc is out.

@taion This still may be a thing? I ran into the same issue @acjay described. I found where I went wrong when I tried to downgrade react-router to an older version (and noticed that I was already on 1.0.3 instead of 2).


Text importer

fixed errors that happen when rss content has non-ASCII symbol or encoding is not utf-8.
e.g. cp1251 (windows cyrillic).

This is quite the change. How were you able to test it? Do you have NewsBlur running locally?

This is now launched. Everything's look good, so let me know if this changes a feed and preferably which feed has now been fixed.

Yes, I have NewsBlur running locally.
Errors happened while parsing these feeds:
http://24tv.ua/rss/all.xml
http://habrahabr.ru/rss/interesting/
http://www.pravda.com.ua/rss/

Thanks for this PR! Tweeted: https://twitter.com/newsblur/status/671827327999840256


[enhancement] Unify configuration JupyterLab and Dask Worker profiles

Description
Dask Worker and the JupyterLab profiles require very similar information but are specified differently in qhub-config.yml. profiles.jupyterlab is a list of objects with a name, description, default flag, and a dict of instance info.
Does it make sense to give both types of  profiles a common set of configuration settings? i.e. both jupyterlab and dask_worker sections are treated the same way, something like this:
qhub-config.yml
============

...

profiles:
  - display_name: Small Instance
    profile_type: jupyterlab
    description: Stable environment with 1 cpu / 8 GB ram
    default: true
    cpu_limit: 1
    cpu: 0.75
    mem_limit: 8G
    mem: 5G
    groups: admins
  - display_name: Small Instance
    profile_type: dask_worker
    description: Dask environment with 1 cpu / 4 GB ram
    default: true
    cpu_limit: 1
    cpu: 0.75
    mem_limit: 4G
    mem: 2G

...

Context
Although this enhancement wouldn't change any external-facing behavior, it would make the profiles section simpler to write, document, and understand.

Hey @peytondmurray thanks for this feedback. Definitely!

Does it make sense to give both types of profiles a common set of configuration settings? i.e. both jupyterlab and dask_worker sections are treated the same way

I completely agree, We are continuously working to get the config.yaml for QHub shorter and more maintaneable, we have other plans for the dask sections in the yaml as well, so that was an excellent idea.
If you have other ideas, do let us know!

Another option could be to have each profile consume the entire node, rather than setting a cpu and memory limits within a given node. This would really simplify configuration. The trade off is that spinning up a new pod takes more time if you're consuming all of it rather than splitting a larger node amongst multiple users. If it means anything, I'm in favor of only specifying the node and consuming all of it.

@peytondmurray Apologies for the delayed response.
Agreed that using the entire node per pod makes sense for user and dask pods. In fact most of the deployments managed by Quansight also follow this methodology.
Because QHub is built on Kubernetes, we have to pass the memory expectations of the pod so that it can get scheduled on a node. It turns out to be rather difficult to determine how much memory is available on the kuberenetes nodes. To see our current progress in this area check out this issue: https://github.com/Quansight/qhub/issues/792


Change cmake targets

Change the default hpx target not to include wrap_main as discussed in the last PMC meeting, the HPX::wrap_main target is exposed to the user in case it's needed
Add a gtest unit test to check we don't break anything during our changes to the cmake targets

fetchcontent_makeavailable is available only from CMake/3.14, do we mind bumping the cmake minimum to 3.14 instead of 3.13?

Should we also have a test verifying that using gtest's main wrapper works as expected?

Absolutely I'm working on it ;)

So in the end, the gtest_minimal.cpp requires an extra interface library to keep the linking order, the following does not keep the order and links gtest_main first which results in a undefined reference to main error linking error:
add_executable(gtest_minimal gtest_minimal.cpp)
target_link_libraries(gtest_minimal INTERFACE HPX::hpx HPX::wrap_main gtest_main)

And this works magically:
add_executable(gtest_minimal gtest_minimal.cpp)

add_library(gtest_main_hpx_interface INTERFACE)
target_link_libraries(gtest_main_hpx_interface INTERFACE HPX::hpx HPX::wrap_main gtest_main)

target_link_libraries(gtest_minimal PRIVATE gtest_main_hpx_interface)

I'm still researching how to make it our problem and not the user's problem

@aurianer Even if we can't solve it on our side, we now have a recipe for the user on how to solve the issue. Thanks! If nothing else, we should add this to the documentation.

@aurianer I have another question: Would all of this work if HPX_WITH_DYNAMIC_HPX_MAIN is disabled?

@aurianer I have another question: Would all of this work if HPX_WITH_DYNAMIC_HPX_MAIN is disabled?

Will try!

@aurianer I have another question: Would all of this work if HPX_WITH_DYNAMIC_HPX_MAIN is disabled?

Will try!
Seems to work with HPX_WITH_DYNAMIC_HPX_MAIN set to OFF

Ok looks like I still have some trouble with some configurations, will look into it!

So in the end, the gtest_minimal.cpp requires an extra interface library to keep the linking order, the following does not keep the order and links gtest_main first which results in a undefined reference to main linking error:
add_executable(gtest_minimal gtest_minimal.cpp)
target_link_libraries(gtest_minimal INTERFACE HPX::hpx HPX::wrap_main gtest_main)

Should that be PRIVATE (or PUBLIC) instead of INTERFACE? I'd expect INTERFACE on an executable to just not link anything at all... Probably explains why the below works but not the above.

And this works magically:
add_executable(gtest_minimal gtest_minimal.cpp)

add_library(gtest_main_hpx_interface INTERFACE)
target_link_libraries(gtest_main_hpx_interface INTERFACE HPX::hpx HPX::wrap_main gtest_main)

target_link_libraries(gtest_minimal PRIVATE gtest_main_hpx_interface)

I'm still researching how to make it our problem and not the user's problem

In any case, having this work even with explicit work from the user is still much better than the confusing errors one gets with the implicit behaviour on master.

@aurianer I have another question: Would all of this work if HPX_WITH_DYNAMIC_HPX_MAIN is disabled?

Will try!
Seems to work with HPX_WITH_DYNAMIC_HPX_MAIN set to OFF

This whole business of actually having gtest_main and wrap_main linked and the runtime started implicitly can only ever work with HPX_WITH_DYNAMIC_HPX_MAIN=ON because when it's off the definition of main has to be where hpx/hpx_main.hpp is included. So these tests are primarily to test that there are no linking errors if one doesn't ask for wrap_main, and secondarily to test that it is possible to use something like gtest_main and wrap_main on supported platforms.

This whole business of actually having gtest_main and wrap_main linked and the runtime started implicitly can only ever work with HPX_WITH_DYNAMIC_HPX_MAIN=ON because when it's off the definition of main has to be where hpx/hpx_main.hpp is included. So these tests are primarily to test that there are no linking errors if one doesn't ask for wrap_main, and secondarily to test that it is possible to use something like gtest_main and wrap_main on supported platforms.

Sure, I however would like for things to work on Windows as well...

This whole business of actually having gtest_main and wrap_main linked and the runtime started implicitly can only ever work with HPX_WITH_DYNAMIC_HPX_MAIN=ON because when it's off the definition of main has to be where hpx/hpx_main.hpp is included. So these tests are primarily to test that there are no linking errors if one doesn't ask for wrap_main, and secondarily to test that it is possible to use something like gtest_main and wrap_main on supported platforms.

Sure, I however would like for things to work on Windows as well...

I hope they will, and they should keep working as before... :) It depends what you mean by "things" of course...

So in the end, the gtest_minimal.cpp requires an extra interface library to keep the linking order, the following does not keep the order and links gtest_main first which results in a undefined reference to main linking error:
add_executable(gtest_minimal gtest_minimal.cpp)
target_link_libraries(gtest_minimal INTERFACE HPX::hpx HPX::wrap_main gtest_main)

Should that be PRIVATE (or PUBLIC) instead of INTERFACE? I'd expect INTERFACE on an executable to just not link anything at all... Probably explains why the below works but not the above.

And this works magically:
add_executable(gtest_minimal gtest_minimal.cpp)

add_library(gtest_main_hpx_interface INTERFACE)
target_link_libraries(gtest_main_hpx_interface INTERFACE HPX::hpx HPX::wrap_main gtest_main)

target_link_libraries(gtest_minimal PRIVATE gtest_main_hpx_interface)

I'm still researching how to make it our problem and not the user's problem

In any case, having this work even with explicit work from the user is still much better than the confusing errors one gets with the implicit behaviour on master.

Yes sorry I modified this locally but didn't push it

So in the end, the gtest emulation is now working, thanks @msimberg for having a look, let me know what you think :)


GroupedNativeMethodsGenerator: generate attributes on extension methods where applicable

Adds the following attributes where applicable:

MethodImplAttribute with AggressiveInlining hint to generated extension methods
GeneratedCodeAttribute to generated extensions class
ObsoleteAttribute to generated extension methods where the native method binding is also marked Obsolete

Thank you.
GeneratedCodeAttribute is for CodeDom and is an old one, isn't it?
For things like AggressiveInlining that are generated, the JIT should perform it automatically, so I think it's not necessary to explicitly specify it.

GeneratedCodeAttribute is useful for tools that operate on the assembly rather than the source file because they won't see the // <auto-generated/> header. It is still used by Microsoft in their source generators, like System.Text.Json for example.
Similarly, Microsoft explicitly use AggressiveInlining in the standard libraries like the Unsafe.AsPointer for example.

Hmmm, I still can't accept CodeDom Namespace.

@neuecc OK, I have dropped that commit

thanks, I'll release soon.


Factor out watcher

Overview
I believe the watcher is causing the server to hang. Let's factor it out.
Deliverables

[ ] implement new, watcherless design

Work for this issue will begin begin on branch work-liquid-labs/playground-monitor/5.