git-up: 1.4.2 -> 1.6.1

Motivation for this change
fixing @r-ryantm update failures.
bumped python2 to python3
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
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)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] 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.

Notify maintainers
cc @peterhoeg

Why not just change python2Packages to python3Packages?

@fridh, do you prefer the derivation to be specific about the python version (python2Packages vs python3Packages), or simply to take a pythonPackages and then have all-packages.nix override accordingly?

@GrahamcOfBorg build git-up

Please fix the merge conflict.

@GrahamcOfBorg build git-up
rebased off master


Add examples for how to use environment variables

Add docs example on how to override topaz config using environment variables.

I assume token_placeholder and token_placeholder are environment variables? If so can we please make the UPPERCASE, so they are easier to spot when reading a config file.

In this case, they are just random strings. The environment variable name determines the yaml path where the substitution will happen. I tried to improve the docs to describe the 2 cases (viper env substitution and interpolation).


add new extension category for language packs

We need to add a new category for package.json categories. the proposal is this:

Rename "Languages" to "Programming Languages" in the Marketplace

Keep the Languages category for package.json

Add a new category to the marketplace called "Language Packs"
Add a new category for package.json called  LanguagePack

https://github.com/Microsoft/vscode/blob/d917cc6bc408822160ff2aad2f3a223c7f5d1e51/src/vs/platform/extensions/common/extensionsRegistry.ts#L151
not sure if it needs to be added anywhere else.

Added Language Packs  category to package.json. To be consistent with other categories, made it plural and added space.


Spellchecking API

I'm currently using GrammarChecker class to check grammar mistakes.
I know CoGrOO can also detect mistyped words and make some suggestions. Is it availabe in cogroo4 API?

No. Cogroo can only do grammar, not orthographic check.
Take a look at Hunspell or Jspell.br
Em segunda-feira, 29 de agosto de 2016, Guilherme Passero <
<EMAIL_ADDRESS>escreveu:

I'm currently using GrammarChecker class to check grammar mistakes.
I know CoGrOO can also detect mistyped words and make some suggestions. Is
it availabe in cogroo4 API?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/cogroo/cogroo4/issues/14, or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-KoZvqABoksZj-bCvZODGLwbCXs3I1ks5qk26hgaJpZM4JwAg8
.

--
William Colen


OpenVR controller positions are below headset

XRTK - Mixed Reality Toolkit Bug Report
Describe the bug
OpenVR controllers are not tracking where the controllers are correctly in relation to headset position, instead they are tracked to the floor
To Reproduce

Run XRTK with Core + SDK with OpenVR only

Expected behavior
Controllers should position as normal in front of headset
Actual behavior
Controllers appear on the floor and also incorrectly rotated?
Screenshots

Your Setup (please complete the following information)

Unity Version 2019.1.14
XRTK Version development

Target Platform (please complete the following information)

OpenVR

@SimonDarksideJ any update on this?


chatbot behaviour init extended with chat object

Coverage remained the same at 100.0% when pulling 67976bcb180be36e4104566fdf8e33e756761bec on chatbot-behaviour-init into e965bb47bfb5dc6c7b8c9fe8d7c16cffb8d85156 on master.


GPIO and light sleep (CON-1164)

I use the example of a lock I am trying to use a GPIO to trigger a relay when I unlock the lock but the GPIO is not responding.
How do I disable light sleep while using the relay and then enable light sleep again.

You can find more details about the sleep mode here: https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/system/sleep_modes.html#sleep-modes
Also, could you elaborate more on your problem, and help with few details
Environment

ESP-Matter Commit Id:
ESP-IDF Commit Id:
SoC (eg: ESP32 or ESP32-C3):
Device Logs (Please attach the log file):
Host Machine OS:

ESP-IDF v5.2.1
SoC  ESP32-H2
Host Machine OS: Mac OS 14.5
ESP-Matter Commit Id: -
Thanks for responding. It turned out that GPIO actually works, but I can't implement GPIO correctly.
I get choppy output, I use an LED, but when I set gpio_set_level(gpio, 1);
lights up and starts flashing rapidly.

I was able to get a steady state of the GPIO using the function gpio_hold_en();

thanks


Adding siblings to nodes in a family tree

This example shows d3 being used to draw an ancestry chart.
I have been looking at chart having the ancestors, descendants and siblings as shown below. In the example John Doe, Mary Joe and Jacob Joes are siblings.
This is tree for John Doe. The tree for B1 Doe is collapsed. It will be complex if her tree is also shown in this chart. If that is done, her ancestor edges/links will cross with John Doe's.
Can a tree like this can be drawn with d3?

:) I recognize this trees, I mean genealogy/ancestors/descendants :)
I don't have development for such purpose so far, maybe in future. But Interesting question.
So what @mbostock would answer here !? :)

Please use Stack Overflow tag d3.js or the d3-js Google group if you want help. These issues are for feature requests and bug reports only.


Error pages reveal database password

The Symfony errror page shows the database password right in the Environment Variables. This can be a security threat that allows people who know a bug that they can trigger to display the database connection details.

You need to turn off app.debug mode within ./app/local/app.php.

Ideally you should be putting your ENV variable to production.

Can you please explain this?  There is no /app/local/app.php file, and what do you mean by setting the ENV variable to production?

With the latest version of Cachet, you need to change the .env file now. Specifically APP_DEBUG=false and APP_ENV=production.

We've done that, but the verbose error pages persist.
Robert Aspinall
NOAA's National Ocean Service
CO-OPS/Information Systems Division
1305 East-West Highway
Bldg. SSMC4, Station Id 6314
Silver Spring, MD 20910
<EMAIL_ADDRESS>On Tue, Jul 7, 2015 at 10:39 AM, James Brooks<EMAIL_ADDRESS>wrote:

With the latest version of Cachet, you need to change the .env file now.
Specifically APP_DEBUG=false and APP_ENV=production.
--
Reply to this email directly or view it on GitHub
https://github.com/cachethq/Cachet/issues/378#issuecomment-119224190.

We've done that, but the verbose error pages persist.

You need to clear your config cache and/or restart php5-fpm.

That did it.  This needs to be in the docs.
Robert Aspinall
NOAA's National Ocean Service
CO-OPS/Information Systems Division
1305 East-West Highway
Bldg. SSMC4, Station Id 6314
Silver Spring, MD 20910
<EMAIL_ADDRESS>On Tue, Jul 7, 2015 at 10:41 AM, Graham Campbell<EMAIL_ADDRESS>wrote:

We've done that, but the verbose error pages persist.
You need to clear your config cache and/or restart php5-fpm.
--
Reply to this email directly or view it on GitHub
https://github.com/cachethq/Cachet/issues/378#issuecomment-119224709.

It's in laravel's docs.

Or, actually, it should happen when you run composer install.

You're meant to configure that before you run that, that way we cache the correct config.

Laravel isn't even mentioned here:
https://docs.cachethq.io/v1.0/docs/installing-cachet
I also spoke too soon, the whole install is crashing now;
PHP Fatal error:  Call to undefined function Illuminate\Cache\apc_fetch()
in
/var/www/Cachet/vendor/laravel/framework/src/Illuminate/Cache/ApcWrapper.php
on line 32
Robert Aspinall
NOAA's National Ocean Service
CO-OPS/Information Systems Division
1305 East-West Highway
Bldg. SSMC4, Station Id 6314
Silver Spring, MD 20910
<EMAIL_ADDRESS>On Tue, Jul 7, 2015 at 10:43 AM, Graham Campbell<EMAIL_ADDRESS>wrote:

Or, actually, it should happen when you run composer install.
--
Reply to this email directly or view it on GitHub
https://github.com/cachethq/Cachet/issues/378#issuecomment-119225301.

You either need to install the apc extension, or not use the apc driver...

Is the APC driver explained somewhere?  I'm trying to follow the install
page, which is very minimal.  It got us up and running, but then we had
verbose error pages that gave up the database password.  This is how we got
to where we are now.
What are we missing?  Is there a list of example .env files somewhere in
the docs?  We'd be happy to use memcached, if we knew what .env settings
were appropriate.
Robert Aspinall
NOAA's National Ocean Service
CO-OPS/Information Systems Division
1305 East-West Highway
Bldg. SSMC4, Station Id 6314
Silver Spring, MD 20910
<EMAIL_ADDRESS>On Tue, Jul 7, 2015 at 10:46 AM, Graham Campbell<EMAIL_ADDRESS>wrote:

You either need to install the apc extension, or not use the apc driver...
--
Reply to this email directly or view it on GitHub
https://github.com/cachethq/Cachet/issues/378#issuecomment-119225972.

Is the APC driver explained somewhere?

You're probably best with the file driver if you want minimal.

Hi Robert,
Everything that you'll want to configure is found in .env.example which you should copy to .env.
APC is very easy to install and is lightweight. DigitalOcean have a really useful help topic on this - I advise you to check it out.
Memcached is fine to use too, but will require more configuration.
Cheers,
James

The file driver has zero dependencies. :)


Move Generate Parentheses to Backtracking

Generate Parentheses problem is currently in the Stack section, it would be better to move it to Backtracking section.

can i take this issue, i am new?


$router.push doesn't change the URL

router.push and this.$router.push does not changes the URL when using vuex-router-sync.
<router-link> works as expected.
When I remove vuex-router-sync router.push works as expected.
// current url #/foo
this.$router.push({path: 'bar'})
// expects URL to be #/bar
// actual URL is still #/foo

Hey @quangv,
Could you give more details? A reproducible jsfiddle or something maybe? I just tried to do this with newest versions of all libraries and it works like a charm. Is it possible that this has been fixed already?
Cheers,
Wojtek

There code base I was working with wasn't so great and I suspect I just had the signature of the call or name of path wrong.
Thanks. Closing now.

If I come across it again I'll re-open ticket.


Integrating Remix Router with React Transitions

What version of Remix are you using?
1.14.1
Are all your remix dependencies & dev-dependencies using the same version?

[X] Yes

Steps to Reproduce
Remix does not fully integrate with Suspense because the Remix router does not use startTransition. I was wondering if there is interest in exploring a fuller integration where Remix router would be more Suspense-y.
To illustrate this, I will offer a little example.
Initial setup
Suppose I have an /index route that just renders
 and a more complex /about page that loads some data. My navigation to /about looks like this:
https://user-images.githubusercontent.com/810438/224425334-d93ac601-4f35-4788-a62f-d43d26feba0c.mov
The data loads in two stages:

First, the "blocking" part holds the router navigation back.
Then, when the loader is ready, we show some content and "defer" the rest.

My code for about.js looks like this:
import { Suspense } from 'react'
import { Await, useLoaderData } from "@remix-run/react";
import { defer } from "@remix-run/node";

function sleep(ms) {
  return new Promise(resolve => setTimeout(resolve, ms))
}

export async function loader({ request }) {
  await sleep(1000);
  return defer({
    username: 'taylor',
    more: sleep(3000).then(() => ({ bio: 'Hi there!' }))
  })
}

export default function Index() {
  const data = useLoaderData();

  return (
    <>

About {data.username}

      <Suspense fallback={
Loading bio...
}>
        <Await resolve={data.more}>
          {more =>
{more.bio}
}
        </Await>
      </Suspense>
    </>
  );
}

So far so good.
A wild suspense appears!
Now let's say I add a component that suspends to my /about page.
import { lazy, Suspense } from 'react'
import { Await, Link, useLoaderData,  } from "@remix-run/react";
import { defer } from "@remix-run/node"; // or cloudflare/deno
+ import Counter from '../counter'
...
export default function Index() {
  const data = useLoaderData();

  return (

about {data.username}

+     <Counter />
      <Suspense fallback={
Loading bio...
}>
        <Await resolve={data.more}>
          {more =>
{more.bio}
}
        </Await>
      </Suspense>

  );
}

Suppose that Counter itself suspends for whatever reason. E.g. maybe it renders a lazy component inside. Maybe it does a client fetch with one of the Suspensey libraries. Maybe it is waiting for some CSS chunk to load (when we add Suspensey CSS integration into React). Etc. In general, you can expect components anywhere in the tree to be able to suspend — and that includes the "non-deferred" parts of the UI.
At first, we'll have an error:

OK, fair enough, it's a React error. It says there's no <Suspense> above it in the tree. Let's fix this.
I could add it around my outlet:
+        <Suspense fallback={
loading
}>
            <Outlet />
+        </Suspense>

But then the whole page "disappears" when it suspends:
https://user-images.githubusercontent.com/810438/224425184-a99c8412-8303-4f54-9ba2-c626937b43ab.mov
Or I could add it around the <Counter> itself:

about {data.username}

+     <Suspense fallback={
loading
}>
          <Counter />
+     </Suspense>
      <Suspense fallback={
Loading bio...
}>

But then my Counter "pops in" independently from the
.
https://user-images.githubusercontent.com/810438/224425518-0518655b-bd93-4d16-8359-b79c814ce7fc.mov
What I really want is to delay the route transition until all content in the "blocking" part (including <Counter /> and whatever it suspended on) is ready.
Is this even possible to fix?
Yes. The canonical fix for this is to wrap the setState which caused the navigation into startTransition. This will tell React that you don't expect that setState to finish immediately, and so it can keep showing the "previous" UI until the render caused by that setState has enough data to show meaningful UI.
As a concrete example, here is a similar navigation implemented in Next.js 13 (App Router):
https://user-images.githubusercontent.com/810438/224426869-74b4abc4-166c-4931-ad3a-d758c3c6f759.mov
Note that although <Counter /> suspends on the client (with an artificial delay), the router still "waits" for it — it "pops in" together with the
. I did not need to add any <Suspense> boundaries — neither around it nor above it.
import { Suspense } from "react";
import Counter from '../counter'

function sleep(ms) {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

async function loadUsername()  {
  await sleep(1000);
  return "taylor";
}

async function loadBio() {
  await sleep(3000);
  return "hi there";
}

export default async function About() {
  const bioPromise = loadBio();
  const username = await loadUsername();
  return (
    <>

about {username}

      <Counter   />
      <Suspense fallback={
Loading bio...
}>
        <Bio data={bioPromise} />
      </Suspense>
    </>
  );
}

async function Bio({ data }) {
  const bio = await data;
  return
{bio}
;
}

Of course, if I wanted to, I could add a <Suspense> boundary around just the <Counter>. Then it would not "hold" the router from a transition.
What's the higher-level point?
Remix currently implements its own machinery to "hold things back" until loaders have returned their result. Then it immediately "commits" the UI — even if that UI might immediately suspend.
React implements a first-class feature to "hold things back" — startTransition. (Or useTransition so you can report progress.) So I am wondering if there is some path towards using the built-in feature.
I imagine that, if Remix were to do that, it would start rendering the new route immediately — but it would suspend when in useLoaderData. If the router setState is wrapped in startTransition, you'd automatically get the "stay on the previous route until there's enough data to show the next route's shell" behavior. But unlike now, it would be integrated with anything else that suspends, like <Counter />.
Would love to hear any concerns or if there's something missing in React to make this happen. It's exciting Remix is taking advantage of Suspense for React SSR streaming already. Integrating Remix Router with React Transitions seems like a big next step towards Remix users being able to benefit from all React features.
Expected Behavior

Remix router transitions are React Transitions (see above)

Actual Behavior

Remix router transitions are not React Transitions (see above)

We started Remix on Suspense with the experimental releases back in the day but after a couple releases broke things we stopped relying on it to "hold things back".
Fast forward and now React Router uses useSyncExternalStore (https://github.com/remix-run/react-router/blob/main/packages/react-router/lib/components.tsx#L63-L70). In Remix v2 we're cleaning up the integration points with React Router and I imagine we won't have our own setState at all in Remix at that point, so it'll all just be useSyncExternalStore.
In that world do we still need startTransition?

and stuck to the stable React releases.

Fair enough! I think everything that's needed here is available in React 18, except for the "throw Promise" thing which would later become "use". But setting that aside, this should be possible to build with stable releases (e.g. it's what Relay works).

In Remix v2 we're cleaning up the integration points with React Router and I imagine we won't have our own setState at all in Remix at that point, so it'll all just be useSyncExternalStore.

At the moment, we can't make Transitions work with external stores. (Hence "sync".) I think we've explored potential APIs for more sophisticated multi-version stores but it's further out.
For Transitions to work, the state needs to be "rooted" in React (i.e. useState or useReducer) because we need to be able to pass different versions of state (either current or pending) to your component. This is what allows us to start rendering the "next' version (which may suspend) but keep responding to interactions with the previous version. I believe in Next 13, it's implemented as useReducer in the router component.

In that world do we still need startTransition?

If you'd like Remix users to be able to use Suspense fully (and avoid the issues described above), then yes.
I think it's also reasonable that Remix may choose not to support these patterns, and maintain its parallel implementation. I.e. not every React framework has to support the full range of React features.
Supporting only a subset of React features makes sense if the framework needs to cater to several UI libraries. Then it would have to use the lowest common denominator and, in the current landscape, it's sync rendering.

If you'd like Remix users to be able to use Suspense fully

Remix is designed specifically to avoid this kind of UX where render side effects trigger fetches, slowing down the page shifting the layout all around the screen.
Would love a concrete example of why you'd want to encourage these waterfalls when Remix has patterns to avoid it completely?
I'm quite happy with defer + <Suspense>, what else do you have in mind?

shifting the layout all around the screen

In the above example, it's the Remix version that shifts layout (because you're forced to add a boundary and can't let the content block instead). In the Next example, there is no extra shift because anything that suspends at the top-level "joins" the transition and blocks it. With Next, you have the freedom to decide what should block and what shouldn't. But you decide that on the UI level (with Suspense), not on the model layer (like defer).
If we set aside implementation concerns and forget about frameworks, I think “stuff outside <Suspense> blocks the route, but stuff inside <Suspense> doesn’t” is a rather intuitive heuristic.

where render side effects trigger fetches

Suspending doesn't mean a fetch is necessarily triggered on the client or by rendering. It only means that the component is not ready yet. It could be waiting for something that was triggered earlier and is already being fetched or transferred from the server. (From what I understand, this is how defer already works.)
For example, we're working on a CSS integration so that CSS chunks can be sent in parallel with JS (instead of blocking JS execution on them or loading them all upfront). If JS loads before associated CSS, React can start rendering the component. (Yay, no CSS-JS waterfalls!) But React would "wait" for associated CSS to load before revealing the contents of the Suspense boundary whose content depends on that CSS.
Images is another example where we might offer an API to "hold back" the boundary so that the route "pops together" with, say, a blurred cover image, or button icons.
Another use case is loading code — but it's true Remix is already limited in that sense. From what I understand, Remix can only load code eagerly (bundled with the route) or completely lazily (requested after client render attempt). So there is no way to conditionally prefetch Counter code based on whether loader's data says it will need to be rendered. However, if Remix did support that (via RSC or some other mechanism), then that would be another example of suspending on something that was already being fetched. Like defer but for code.
Finally, some things might just have to fetch on the client. I think it would be great if when you're forced to do this, you could still avoid unintentional layout jumps, and could hold back the router a bit.
All in all, I don't think this is strictly about one specific pattern. React offers a way to hold the UI back. It's ok not to use it, but I think it will start being more noticeable as more things start integrating it. Both under-the-hood things like CSS, and arbitrary user code taking advantage of this support.

I think it would be great if when you're forced to do this, you could still avoid unintentional layout jumps, and could hold back the router a bit.

That makes sense. I've wanted the ability to hold back the router to complete an animation in case the route transition is faster than the animation, or simply avoid flickering a spinner for 10ms.
I still maintain that we should be spending our energy designing APIs to avoid render-initiated asynchrony. Async components make it easier to do the wrong thing.

I feel like the async/await and server components talk is a derailing this issue a bit. It doesn't seem exactly related to the discussion of "remix router transitions should be wrapped in startTransition" - I think the code in the issue description is just showing how it works in server components, but it also applies to the remix of today when you start adding in suspense in it's many forms outside of server components.

Yeah sorry, didn’t mean to imply this has something to do with RSC per se. It’s just the latest example of “stuff can suspend anywhere” in my mind because it’s more granular about sending code. But the CSS stuff I mentioned is not gonna be RSC-specific — I think it would actually be great if Remix could try using it too once we get something working for that.
I also apologize if the focus on that Next example is distracting — Next isn’t where this behavior is. The heuristic itself is in React 18. (Transitions don’t get committed until you have enough to render the new screen.) So you can imagine the existing useLoaderData API, but if the router is implemented in the Suspensey paradigm (rendering the next route is a transition whose render suspends on its data/code), it should “just work” using the same heuristic.

Forgive me for intruding on this conversation considering I'm a nobody 😅. @gaearon with the example you gave with the Counter component, let's say for whatever reason it takes 30 seconds to resolve. Maybe its calling some long running external process and we have no control on how long it takes. With the startTransition approach wouldn't the user basically be stuck on the previous page until whatever long running process Count called completed ?
You could certainly wrap it in Suspense and show the new page immediately with a fallback  but that would need to be something intentional a developer does. If a developer misses that a component will not resolve in a reasonable amount of time well then you have a more jarring user experience in that the user thinks the site is stuck as opposed to showing the new page immediately and then the loader.
It would be great if startTransition maybe had something like a timeout that can be configured. Perhaps that could incentivize adoption as in the very least if a developer makes a mistake or doesn't anticipate something then there is a safety net ?

What you're describing is what the browser already does natively on anchor tag, full page reload navigation. It makes sense for Remix to mirror this as a default IMO.

For example, we're working on a CSS integration so that CSS chunks can be sent in parallel with JS (instead of blocking JS execution on them or loading them all upfront). If JS loads before associated CSS, React can start rendering the component. (Yay, no CSS-JS waterfalls!) But React would "wait" for associated CSS to load before revealing the contents of the Suspense boundary whose content depends on that CSS.

Images is another example where we might offer an API to "hold back" the boundary so that the route "pops together" with, say, a blurred cover image, or button icons.

To put something concrete behind this, we've just landed core support for this in the reconciler (https://github.com/facebook/react/pull/26398). No DOM integration yet, but it's coming. This will — at least initially — only be enabled during Transitions.

@Moro-Code for some time you could pass an object with options to useTransition and control the timeout with the timeoutMs property. Here is the explanation why it was removed: https://github.com/facebook/react/pull/19703
https://hu.reactjs.org/docs/concurrent-mode-patterns.html#transitions

@ryanflorence, is it unlikely that your stance on this issue will change?

That makes sense. I've wanted the ability to hold back the router to complete an animation in case the route transition is faster than the animation, or simply avoid flickering a spinner for 10ms.

I think this is a significant limitation in Remix (and React in general, before Suspense / Transitions). Being able to hold back the rendering of state updates is essential to provide smooth transitions. Both when you add animations to mask fetch delays and the fetch is faster than the animation (the issue I believe you describe?), but also more generally to enable "exit animations" where you keep the old state until an animation is done, before rendering the updated state (sliding content out-of/into view, open/close modals etc.).
I agree on your last comment about avoiding render-initiated asynchrony, but I don't think that's necessarily related?

How are you folks working around this limitation?
Our use case is: we have a SPA using React Router, a global suspense boundary, and a page showing some content using a suspense-compatible data fetching library. The request is driven by a search param. Changing the search param triggers a new request, and we were expecting that wrapping the setSearchParams call in startTransition would keep the previous data till the new one was ready, avoiding the suspense boundary.

startTransition support is added in https://github.com/remix-run/react-router/pull/10438 and will be available once React Router 6.12.0 and Remix 1.17.0 are released


Introduce pipeline monitoring

Introduce the concept of pipeline monitoring: A new monitor class is passed to the pipeline.run() function. The main idea is to separate the monitoring from the code that builds pipeline. Through the build process various methods will be called on that object, representing the different steps and their targets during the build process. This can be used to fully stream the output of the various stages or just indicate the start and finish of the individual stages.
This replaces the 'interactive' argument throughout the pipeline code. The old interactive behavior is replicated via the new FileMonitor class that logs the beginning of stages/assembler, but also streams all the output of them to stdout. The non-interactive of not reporting anything behavior is done by using the BaseMonitor class, which in turn does nothing.
Additionally it contains a new monitor class (yet unused) will stream JSON records according to RFC 7464, where JSON records are separated special characters:

<RS> %x1E, RFC20
<LF> %x0A, RFC20

For ever stage, assembler a message before it is being built a message is send (stdio) with the following information:
  <RS>{
    "type": "build",
    "module": {
      "type": "assembler",
      "name": "org.osbuild.rawfs",
      "id": "8cb7287d9ac5c561c9aa6ef712..."
    },
    "progress": {
      "current": 7,
      "total": 7
    }
  }<LF>

After the build is done another message is send, consisting of:
  <RS>{
    "type": "result",
    "module": {
      "name": "org.osbuild.rawfs",
      "id": "8cb7287d9ac5c561c9aa6ef7124...1"
    },
    "success": true,
    "output": "... output of the stage ..."
  }<LF>

This allows clients to follow the progress of the build process.
TODO:

[x] Tests
[ ] Integrate JsonMonitor via a new command line option

Solves #319

I like this a lot! My only questions are about the new JSON stream monitor: what's the usecase we have in mind here? Is the idea that this can contain any (stage-specific) metadata, not just logs (as we have discussed in the past), or would metadata be separate?

I like this a lot! My only questions are about the new JSON stream monitor: what's the usecase we have in mind here? Is the idea that this can contain any (stage-specific) metadata, not just logs (as we have discussed in the past), or would metadata be separate?

The JsonMonitor was mostly meant to be a proof-of-concept and a discussion starting point (it is not integrated at all yet). My main idea was to provide feedback to clients (i.e. composer) about the progress of the image building (the info contains the x of y done information) maybe with some high level status ("Installing boot loader", see below).
The question is about the separation of monitoring/logging versus result returning & reporting. I feel that monitoring and the actual result reporting should be separated, i.e. you still get the full JSON result dictionary on stdout at the end when everything is done (and doing something with the monitor output is optional). And that final result would also contain the metadata. I am very, very tempted to even remove the output field from the JSON monitor messages, because I am not sure how useful that is in the non-error case anyway. But I am not 100% sure and the line between monitoring and reporting of results is a bit blurry.
I also had the idea to add a another level of logging/status reporting to the API that can be used by the stages: the stages/assembler could use api.status("Downloading RPMs"), api.status("Installing RPMS"), api.status("Installing Bootloader"), that would then be handed from the stage via the JSON RPC to the monitor via monitor.status(), and that be reported back to the client (composer); there it could be used to show the status/progress within a stage in the UI. I feel that is more useful then reporting the output of the tools (which can be a lot of unhelpful gibberish).
Opinions?

Cool idea indeed. Would those be user-visible (translated) strings?

I'm not sure about best-practices here, but could we somehow make them identifiers, so the strings could live in the UI?

Cool stuffs!!

I also had the idea to add a another level of logging/status reporting to the API that can be used by the stages: the stages/assembler could use api.status("Downloading RPMs"), api.status("Installing RPMS"), api.status("Installing Bootloader"), that would then be handed from the stage via the JSON RPC to the monitor via monitor.status(), and that be reported back to the client (composer); there it could be used to show the status/progress within a stage in the UI. I feel that is more useful then reporting the output of the tools (which can be a lot of unhelpful gibberish).

It would be terrific to show UI users the progress of the different stages.

I.e., something like api.status("rpm.download"), so the UI sees the identifier rpm.download in the context of the org.osbuild.rpm stage and would map that to the (translatable) string "Downloading RPMs". We could then be very granular in what the stages emit, but the UI would opt in to show those status updates they think are useful.

I think this is a good idea since the UI would definitely map from the identifier to a translated string. I believe that the more granular we are in our status updates, the better a user will understand the progress of the image build.

I also had the idea to add a another level of logging/status reporting to the API that can be used by the stages: the stages/assembler could use api.status("Downloading RPMs"), api.status("Installing RPMS"), api.status("Installing Bootloader"), that would then be handed from the stage via the JSON RPC to the monitor via monitor.status(), and that be reported back to the client (composer); there it could be used to show the status/progress within a stage in the UI. I feel that is more useful then reporting the output of the tools (which can be a lot of unhelpful gibberish).

I like this idea. Monitoring is useful for telling users 'hey! I'm not dead yet!' but it doesn't need to be super detailed. And if things fail they will have the logs to dig through anyway so I don't see any reason for the monitor to include logs.

Cool idea indeed. Would those be user-visible (translated) strings?
I'm not sure about best-practices here, but could we somehow make them identifiers, so the strings could live in the UI?

I.e., something like api.status("rpm.download"), so the UI sees the identifier rpm.download in the context of the org.osbuild.rpm stage and would map that to the (translatable) string "Downloading RPMs". We could then be very granular in what the stages emit, but the UI would opt in to show those status updates they think are useful.

I love this!

I like this idea. Monitoring is useful for telling users 'hey! I'm not dead yet!' but it doesn't need to be super detailed. And if things fail they will have the logs to dig through anyway so I don't see any reason for the monitor to include logs.

Based on all the feedback I have removed it from the JsonStream logger.
I wonder if I should split the inclusion of the JsonStream logger out of this PR. I wanted to show them together to give a full picture. But maybe not it is conflating the general monitoring framework idea too much with discussion of that specific monitor.

I wonder if I should split the inclusion of the JsonStream logger out of this PR.

Makes sense to me. The JsonStream looks good to me, but might be good to give that some more time and gather some more input about how it would be used and what it should contain.

I changed the JsonStream monitor to stream JSON lines because I could not get jq to accept the record separated JSON. Additionally, I added two new command line parameters to osbuild:

--monitor: (string) selects which monitor class to be used, e.g. LogMonitor, JsoStream
--monitor-fd: (int) Use the supplied fd to write monitor output to.

The idea would be that clients can open a dedicated file descriptor and pass it to osbuild and then this is used for logging.
Not 100% happy with LogMonitor yet, maybe TextLogger, TextStream or something? Happy for input.

Removed the command line options, will be done together with the JSON based logger. Added even more tests.


Skip to selected image

Is it somehow possible to skip to the selected image? E.g. while implementing dots navigation.

I've managed to help myself by intercepting the carousel controller in a very nasty way. Still would be better to have a generic solution for that.
BTW: I've noticed that clicking and autoRotation don't play well with each other. It results in random images sliding, probably something $interval.


Doesn't work in docker container

Hello. I'm using utoipa-swagger-ui with "axum" and "vendored" features
utoipa-swagger-ui = { version = "8.0.3", features = ["axum", "vendored"] }
I'm running my dev server as docker compose service. It worked well until one of the recent updates
I'm making a request to my dev server and I see that the request is valid and it goes to swagger-ui. But when I try to reach it in the browser - I get 404 not found without any additional information. Swagger-ui silently don't work and I can't understand why. Is it possible to print some warnings/traces/errors so I can understand what's wrong, please? I'll be glad to have that information :)
I'm using "vendored" feature, as I said, but besides there's a curl in my docker container and it can download swagger even without "vendored" feature.

I tried the setup with examples/axum-utoipa-nesting-vendored with following docker file:
FROM alpine:3.14

COPY target/x86_64-unknown-linux-musl/release/axum-utoipa-nesting /axum-utoipa-nesting

ENTRYPOINT [ "/axum-utoipa-nesting" ]

Install with command
cargo build --release --target x86_64-unknown-linux-musl
docker build -t axum-utoipa-nesting:latest .

Run with command:
docker run -p 8080:8080 -t axum-utoipa-nesting:latest

Then browse to localhost:8080/swagger-ui and it does work like a charm.
For the rust embed to actually embed files to the docker image you either need to build the crate with --release or add debug-embed feature flag. Read more about rust embed docs: https://github.com/pyrossh/rust-embed?tab=readme-ov-file#documentation

Updated the example over here: https://github.com/juhaku/utoipa/tree/master/examples/axum-utoipa-nesting-vendored

Is it possible to print some warnings/traces/errors so I can understand what's wrong, please?

Yeah, at the moment there is no logging in the crate, but perhaps something like that could be added to remind people that they need to either use the --release build flag or add debug-embed feature.. :thinking:

Thanks a lot! I used debug-embed and it indeed works like a charm! I've puzzled over it for two days and now I finally can chill and happily enjoy swagger. Thanks to you again, cheers!


Move light-client commands into basecoin

But cli/cobra stuff where we use it.
All crypto logic stuff, certifiers and proofs, stays over in light-client land, waiting to merge into tendermint core.

Fixed with #174
What was in the light-client/commands (and under cmd/basecli/commands) is now under client/commands


kernel: return error instead of misaligned k_thread object

k_object_alloc(K_OBJ_THREAD) returns a usable struct k_thread pointer.
This pointer is 4 byte aligned. On x86 and x86_64 struct _thread_arch
has a member which requires alignment. Since this is currently not
supported k_object_alloc(K_OBJ_THREAD) now returns an error instead of
a misaligned pointer.
Relevant issues: #17893 and #29589
Returning an error makes it more clear, that this is currently not supported on x86 and x86_64 than an access error due to a misaligned pointer.

thanks, we should not leave sharp edges like this for end users while we sort out this issue.


[Grid] Issue

Using dense is bad for accessibility.
Since Radix is accessibility focused, I'd suggest we remove these options?

Nothing wrong with dense grids without interactive elements.

Wouldn't this still confuse users using screen magnifiers because the enlarged portion of the screen skips around and blind users working with sighted users, who read the page in visual order, when they encounter information in a different order?
Are those use cases not considered important enough for accessibility? Genuine question 😊

@andrecasal there're many other ways to create much worse accessibility problems using the components and styles that can be used accessibly. This isn't a Radix Themes concern, that's how everything on the web works. We just provide the tools to build your project, it's up to you to do a good job with it.


AttributeError: 'SubRequest' object has no attribute 'funcargnames'

path where exception creates: nameko/testing/pytest.py:274
        reorder_fixtures = ('container_factory', 'runner_factory', 'rabbit_config')
        for fixture in reorder_fixtures:
>           if fixture in request.funcargnames:
E           AttributeError: 'SubRequest' object has no attribute 'funcargnames'

Python 3.7, pytest==6.2.5

@antl31 make sure, you run the test within proper python environment.
I have similar issues, when:

having pytest installed globally
having project with virtual environment with it's own pytest
trying to run the test without having the virtual env being properly activated, thus unintentionally using the global pytest.

I you would have globally installed older version of pytest, I would expect such issues to happen.

I've solved the same problem by adding addopts = -p no:nameko


How to Parse JSON in Dart/Flutter

Proposed title of the article
How to Parse JSON in Dart/Flutter
Introduction paragraph (2-3 paragraphs):
Parsing JSON is a very common task for apps that need to fetch data from the Internet. It is hard to imagine a mobile app not needing to communicate with a web server or store structured data at some point. When making network-connected apps,  it needs to consume some good old JSON.
This guide looks into ways of using JSON with Flutter. It covers which JSON solution to use in different scenarios.
Key takeaways:
-The reader will learn how to create a plain dart object.
-The reader will learn how to make the network request.
-The reader will learn how to map the JSON objects to Dart Objects.
References:
N/A

@vincentkims49
Good afternoon and thank you for submitting your topic suggestion.
Your topic form has been entered into our queue and should be reviewed (for approval) as soon as a content moderator is finished reviewing the ones in the queue before it.

Hi, @vincentkims49.
Could you tell me how your article differs from those of a similar topic such as Parsing JSON in Flutter, Parsing Complex JSON in Flutter and How to Parse JSON in Flutter for Beginners?

Hi, @louisefindlay23.
Depending on how much JSON data you need to manage, I'll write all of the JSON processing code manually. In my article, I'll also go through encoding and decoding JSON, parsing JSON within a factory constructor, dealing with nullable variables and serialization back to JSON. You'll also learn how to create model classes with strong JSON parsing and validation code by the conclusion of this tutorial.

@louisefindlay23,
Thank you

@hectorkambow @lalith1403
I'll be providing original content.More than what is available in other websites since it's not available in github section and for learners to understand step by step on how to parse JSON .
Thank you.

its a total different topic @louisefindlay23


[pulsar-client-cpp] Upgrade protobuf

Motivation
protobuf 3.3.0 is vulnerable.
https://snyk.io/vuln/pip:protobuf
Modifications
upgrade the version of protobuf in pulsar-client-cpp to 3.20.0.
Verifying this change

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

This change is a trivial rework / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:
If yes was chosen, please highlight the changes

Dependencies (does it add or upgrade a dependency): (no)
The public API: (no)
The schema: (no)
The default values of configurations: (no)
The wire protocol: (no)
The rest endpoints: (no)
The admin cli options: (no)
Anything that affects deployment: (don't know)

Documentation
Check the box below or label this PR directly.
Need to update docs?

[x] no-need-doc

/home/runner/work/pulsar/pulsar/pulsar-client-cpp
bash: line 1: /opt/cmake/cmake-<IP_ADDRESS>-Linux-x86_64/bin/cmake: No such file or directory

Could you verify the Dockerfile locally before pushing the patch? It looks like we shouldn't modify the path to cmake.

@BewareMyPower I undid an unneccessary change of  cmake. PTAL.


PR: Fix url awareness missing variable and add regression test

Description of Changes

[x] Wrote at least one-line docstrings (for any new functions)
[x] Added unit test(s) covering the changes (if testable)

Issue(s) Resolved

Fixes #9614
Affirmation
By submitting this Pull Request or typing my (user)name below,
I affirm the Developer Certificate of Origin
with respect to all commits and content included in this PR,
and understand I am releasing the same under Spyder's MIT (Expat) license.

I certify the above statement is true and correct: @goanpeca

@jnsebgosselin please let me know if this fixes the issues for you.
@ccordoba12 do not merge yet (if test pass) I want to add an extra test to check the messagebox is being triggered as expected if there are problems with the new shorthand style issues (1gh-1231)

I confirm this fixes the issue for me.
I
nstead of adding all these if not testing: in the code, wouldn't it be better to mock these calls instead, like for example doing mocker.patch.object(QDesktopServices, 'openUrl') ?

Yes indeed that is a much better solution!! Will do that

Done @jnsebgosselin! Thanks for the suggestion, I forget about mock all the time!

Hello @goanpeca! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file spyder/plugins/editor/widgets/tests/test_goto.py:

Line 40:80: E501 line too long (82 > 79 characters)

@ccordoba12 merge :-) ?


call NumpyToTensor last

Checklist
GitHub

[x] I've given this PR a concise, self-descriptive, and meaningful title
[x] I've linked relevant issues in the PR body
[ ] I've applied the relevant labels to this PR
[x] I've assigned a reviewer

PR contents

[x] I've consulted ivadomed's internal developer documentation to ensure my contribution is in line with any relevant design decisions
[ ] I've added relevant tests for my contribution
[ ] I've updated the relevant documentation for my changes, including argparse descriptions, docstrings, and ReadTheDocs tutorial pages

Description

note I cannot provide a test for this since ivadomed still fails for the tutorial dataset (which is not the right dataset) for a different reason, we just got past the point where this was failing in the ticket, if you provide me with a dataset that would pass I would be glad to add some tests.
we would have to get rid of all NumpyToTensor in the config or it would be called twice if there is a NormalizeInstance
Linked issues

resolves #815

Pull Request Test Coverage Report for Build 903480077

7 of 7 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.03%) to 69.967%

Totals

Change from base Build 900933177:
0.03%

Covered Lines:
4049

Relevant Lines:
5787

💛  - Coveralls

we would have to get rid of all NumpyToTensor in the config

And from the documentation and tutorials, thanks

I ran locally everything passes, now you just have to remove NumpyToTensor from all of the configs or else it would fail

I ran locally everything passes, now you just have to remove NumpyToTensor from all of the configs or else it would fail

Sounds like a good plan! Thanks!!

someone approve this https://github.com/ivadomed/data_functional_testing/pull/7

now we just have to wait until https://github.com/ivadomed/data_functional_testing is archived again...

now we just have to wait until https://github.com/ivadomed/data_functional_testing is archived again...

can you please elaborate what needs to be done?

now we just have to wait until https://github.com/ivadomed/data_functional_testing is archived again...

can you please elaborate what needs to be done?

right now download_data script is downloading the archived file from the data_functional_testing repo, which is last updated two month ago...after the new commit goes in we have to archive the new data_functional_testing repo and change the download_data script to download the new archived data

now we just have to wait until https://github.com/ivadomed/data_functional_testing is archived again...

can you please elaborate what needs to be done?

right now download_data script is downloading the archived file from the data_functional_testing repo, which is last updated two month ago...after the new commit goes in we have to archive the new data_functional_testing repo and change the download_data script to download the new archived data

sorry i'm not sure i fully understand-- can you please let us know what needs to be done? do you need any help?

now we just have to wait until https://github.com/ivadomed/data_functional_testing is archived again...

can you please elaborate what needs to be done?

right now download_data script is downloading the archived file from the data_functional_testing repo, which is last updated two month ago...after the new commit goes in we have to archive the new data_functional_testing repo and change the download_data script to download the new archived data

sorry i'm not sure i fully understand-- can you please let us know what needs to be done? do you need any help?

this is the download_data script
        "url": ["https://github.com/ivadomed/data_functional_testing/archive/r20210204.zip"],
        "description": "Data used for functional testing in Ivadomed."
    }```
Now I just need data_functional_testing to be archived again, then I can change this url to download the latest data_functional_testing, thanks

Now I just need data_functional_testing to be archived again, then I can change this url to download the latest data_functional_testing, thanks

is that something you can do? sorry i have limited time

now everything passes, can I get an approval?


docs: update broken link for socket.io docs

Update to v4 of socket.io docs

Awesome, thanks! Would you be willing to update the other references to this same link in the website?

I would love to, but how to find that?

Awesome, thanks! Would you be willing to update the other references to this same link in the website?

Sure, already updated it


Out of date

Please update this to foundry vtt v.12 as it says it is only for 11 and will not work in 12

this module works fine in v12, you just can't enable it because the dependencies aren't available yet
feels a bit insincere labelling it as "v12 ready" when it's functionally useless, so I'll pass, for now


url: treat empty port as default

When parsing URLs, treat an empty port (eg http://hostname:/) as if it were unspecified.  RFC 3986 says:

URI producers and normalizers SHOULD omit the port component and its ":" delimiter if port is empty or if its value would be the same as that of the scheme's default.

(Emphasis mine.)  This indicates that URIs MAY be produced with an empty port and the : delimiter.
Thus, we stop failing if we end host parsing at the port delimiter.

cc @nodejs/http : are we aware of any possible side effects that might happen in Node.js after landing this?

@ethomson thank you for an excellent PR! The change looks great. It has to be considered in the context of Node.js too, however. Let's wait for @nodejs/http to get better understanding of interactions of this PR and Node core.

As a side note, I wonder if libgit2 might be interested in using llhttp instead of http_parser? The former is faster and verifiable, and is already used in the latest Node.js.

Interesting...!  Thanks for the pointer @indutny.  I’ll take a look, particularly since I’m interested in pausing in my on_headers_complete callback.  Would you happen to know offhand if llhttp fixes #97 or if that’s still an issue?

@nodejs/http, ping.

@nodejs/http


Missing search results statistics

References

Fixes #8729
PR on REST side

Description
This PR changes the search component to track clicks on listed objects (items/collections/communities) and sends a search event for them, containing the clicked object's UUID so REST can log them as a search_results statistic (see REST PR)
Instructions for Reviewers
Changes made

SearchService's trackSearch() method now accepts an optional object UUID
When present, it'll be added to the search event sent to angulartics2
Angulartics2DSpace supports an object property
Modified StatisticsService's trackSearchEvent() to support the object property
Added a subscribe (which is unsubscribed from on destroy) to the SearchComponent, listening to routing events going away from the current page. If it reads one and it's navigating to an object's page (entity, item, collection or community), call trackSearch() with the object UUID
I noticed SearchTrackerComponent, our old way of tracking search statistics, still exists and is now completely irrelevant. So I removed it, since we also don't want anyone to re-use it, as it would result in duplicate statistics because it extends from SearchComponent itself.

How to test
Testing is best done together with a local rest instance containing the changes from the REST PR. If not, you can always take a look at the network tab of your browser to spot statistic events being sent.

Click an item/collection/community from any page but the search page (e.g. homepage), this should not send any statistic events
Click an item/collection/community from the search page, this should send a statistic event containing the clicked object's UUID
If using a local REST API with the PR's changes, statistics with type "search_result" should show up with the object's UUID in your solr core.

Checklist
This checklist provides a reminder of what we are going to look for when reviewing your PR. You need not complete this checklist prior to creating your PR (draft PRs are always welcome). If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!

[x] My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
[x] My PR passes ESLint validation using yarn lint
[x] My PR doesn't introduce circular dependencies (verified via yarn check-circ-deps)
[x] My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
[x] My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
[x] If my PR includes new libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
[x] If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
[x] If my PR fixes an issue ticket, I've linked them together.

Thank you for the reviews, @tdonohue and @paulo-graca !
I've force-pushed some changes to the PR to keep the commit history a bit more clean.
The changes are:

Renaming "object" to "clickedObject" to be in-line with the feedback changes made on the Rest PR
Added some test cases

As for the scope property, @tdonohue , I tried to reproduce this issue, but wasn't able to do so. The scope parameter is passed on correctly on my end.


Example notebooks exhibiting the JuliaClimate stack

It would be nice to have some examples of the existing JuliaClimate stack in action in notebooks (if there redundancies, then maybe even feature / performance comparisons?).
My personal goal for the next few weeks is to basically implement a Julia translation of my "big data" Python tutorial [binder link] which uses the following stack:

xarray and dask as the building blocks for reading and analyzing out-of-memory labelled NetCDF arrays
intake (generic organizational tool leveraging xarray) to read in netcdf files stored in a cloud-optimized zarr format in Google Cloud storage as xarray.Dataset instances
xgcm for doing grid-aware operations (e.g. differentiation) on datasets
xmitgcm (model-specific package) to process the dataset's non-rectangular native grid into something more rectangular

These are basically the four categories of packages that I see as necessary to replicate the kinds of workflows that I am interested (and which are extremely straight-forward using the existing Pangeo Python-stack, as in my example above):

Basic data types that make handling large NetCDF-like datasets efficient (low overhead), effortless (intuitive and compact syntax), scalable (distributable, out-of-memory), and extendable (flexible and simple data structure types).
Organizational packages that simplify the workflow (e.g. organizing model ensembles, models vs. observations, downloading scripts)
Generic utility packages that extend the functionality of 1-type packages (e.g. for problem-specific, dimension-specific, or operation-specific uses).
Model-specific utility packages that rely on model-specific metadata (e.g. some of what @natgeo-wong and @gaelforget are working on).

I don't really know how much sense it makes in putting effort to develop 2, 3, and 4 if we haven't yet settled on a stable 1.

See https://github.com/JuliaClimate/meta/issues/3#issuecomment-594679533 about a notebook stack that we started putting together


n-queens plot solution not scaling

In the N-Queens colab, the PlotSolution() function does not scale well with n because of the fixed crown fontsize, causing a crown to span over multiple squares for higher values of n. Replacing fontsize=7*size with fontsize=56*size/n does the job.
Corrected code:
chessboard = np.zeros((n, n))

chessboard[1::2,0::2] = 1
chessboard[0::2,1::2] = 1

plt.figure(figsize=(size, size))
plt.imshow(chessboard, cmap='binary')

for i, j in x:
    if x[i,j]() > 0:
        plt.text(i-1, j-1, '♕', color='darkorange',
                 fontsize=56*size/n, fontweight='bold', ha='center', va='center')
plt.xticks([])
plt.yticks([])
plt.show()

Thanks! You're right, I have fixed and merged the corresponding notebook.
Let me know if you have any other suggestions.


Virtualized VM immediately crashing upon launch on M1 iPadOS 14.5, arm64 Windows 11

Describe the issue
Created VM using "Virtualize" option with Windows 11 (22000.918) arm64 ISO. 4GB RAM and 50GB storage.
Starting VM immediately crashes the app.
Disabling in Settings -> QEMU -> Use Hypervisor allowed the VM to launch.
Configuration (required)

UTM Version: 4.0.4, UTM.HV.ipa used
OS Version: iPadOS 14.5
Device Model: 5th Gen M1 12.9 inch iPad, 16GB RAM
Is it jailbroken (name jailbreak used)? Yes, unc0ver
How did you install UTM? Tried both filza/appsync unified & trollstore

Crash log
UTM-2022-09-11-170412.txt
Debug log
debug.log

Yes, that’s because you are not using iPadOS 15.0~15.1.1
Hypervisor on iPad M1 is only supported on iPadOS 15.0~15.1.1.

iOS 14 requires different hypervisor offsets. I am working on that right now and will provide an IPA to test soon.

Please test https://github.com/utmapp/UTM/suites/8313076043/artifacts/365026554 and post crash log if it still crashes.

It is still crashing but looks like some progress made. Before it would crash instantly after tapping start button but now it gets to grey screen with loading icon in middle that appears before booting.
UTM-2022-09-15-145258.txt
debug.2.log

@meerkatriptide please try https://github.com/utmapp/UTM/suites/8322812338/artifacts/365745890

Getting below screen, no loading bar or any further text appeared after waiting for 10+ minutes.

debug.3.log (This log I just quit the VM almost immediately to generate it)

Fixed in f1997bc976e18ebf31f94f169461a35f2f5c4859


[Issue-2889] Update min active stake for relaychain validators

🚀 Deployed on https://pr-2908--sw-web-runner.netlify.app


replace action shellcheck.yml with differential_shellcheck.yml

replace action shellcheck.yml with differential_shellcheck.yml
add shellcheck_roles.yml to group_vars to manage roles containing shell scripts.

Also git rm -f playbooks/templates/.github/workflows/shellcheck.yml

Also git rm -f playbooks/templates/.github/workflows/shellcheck.yml

I was wondering about the file. Since we put it in the absent_files, can we expect it will be automatically absent?
https://github.com/linux-system-roles/.github/pull/13/files#diff-ee877de6bbd0a00a6b5cad8bdb7ec1f27fbb4d5d96e5e77b27a56fce75562273R12-R14
How about the individual roles which do not have shell scripts? Do we want to do git rm shellcheck.yml and merge it, too?

Also git rm -f playbooks/templates/.github/workflows/shellcheck.yml

I was wondering about the file. Since we put it in the absent_files, can we expect it will be automatically absent?

It will be removed from the role repos, but it also should be removed from this .github repo as well.

https://github.com/linux-system-roles/.github/pull/13/files#diff-ee877de6bbd0a00a6b5cad8bdb7ec1f27fbb4d5d96e5e77b27a56fce75562273R12-R14
How about the individual roles which do not have shell scripts? Do we want to do git rm shellcheck.yml and merge it, too?

Yes.

@nhosoi please also revert this PR

@nhosoi please also revert this PR

Thank you, @richm. I've opened https://github.com/linux-system-roles/.github/pull/18.


Dax88 - 8 Zone Player

What version of Music Assistant has the issue?
2.0.0.b106
What version of the Home Assistant Integration have you got installed?
2024.3.0
Have you tried everything in the Troubleshooting FAQ and reviewed the Open and Closed Issues and Discussions to resolve this yourself?

[X] Yes

The problem
I see the Dax player itself but I cant select individual  zones - I have each zone installed as a media_player entity in home assistant  - Music assistant can not see the zones that are entities.  Is there a way to expose them to Music Assistant?
How to reproduce
no steps needed
Music Providers
Spotify and youtube
Player Providers
Airplay
Home Assistant
Cast
DLNA
Relevant log output
No response
Additional information
No response
What version of Home Assistant Core are your running
2024.3
What type of installation are you running?
Home Assistant OS
On what type of hardware are you running?
Generic x86-64 (e.g. Intel NUC)

Have you read our docs?

I didnt see anything about zone players

Well there is on the troubleshooting page. However I think you actually want to expose the HA media players as that is your question in your post. I am not sure why you haven’t been able to if you have read the docs. You don’t mention why you aren’t able to.

I guess I dont know how - I have tried everything to my knowledge

https://music-assistant.io/integration/installation/
Look at the home assistant player provider section

Do you have this workign now?

I have the Dax unit loaded but music assistant cannot control the zones - i have to go back to home assistant to turn zones on and off and control volume - I guess it is more of a feature request than a bug

Well, I suppose each "zone player" does not accept a play media command ? Its more like a single player that accepts play media commands and you can then switch zones on/off ?
That is indeed something you need to solve with HA. Music Assistant can only send audio to the "master" player.
You could trick this btw if you make use of template/universal media players in HA

I tried that - I get a single entity called media_player.dax_zone_ma
I do not get any actual zones - there's no error showing

platform: universal
name: Dax_Zones_MA
unique_id: dax_zma
children:

media_player.zone_16 #garage
media_player.zone_13 #patio
media_player.zone_11 #master_bedroom
media_player.zone_12 #master_bath
media_player.zone_14 #josh_office
media_player.zone_15 #cara_office
media_player.zone_17 #pool
media_player.zone_18 #living_room
commands:
turn_on:
service: media_player.turn_on
target:
entity_id:

media_player.zone_16 #garage
media_player.zone_13 #patio
media_player.zone_11 #master_bedroom
media_player.zone_12 #master_bath
media_player.zone_14 #josh_office
media_player.zone_15 #cara_office
media_player.zone_17 #pool
media_player.zone_18 #living_room
turn_off:
service: media_player.turn_off
target:
entity_id:
media_player.zone_16 #garage
media_player.zone_13 #patio
media_player.zone_11 #master_bedroom
media_player.zone_12 #master_bath
media_player.zone_14 #josh_office
media_player.zone_15 #cara_office
media_player.zone_17 #pool
media_player.zone_18 #living_room
volume_up:
service: media_player.volume_up
target:
entity_id:
media_player.zone_16 #garage
media_player.zone_13 #patio
media_player.zone_11 #master_bedroom
media_player.zone_12 #master_bath
media_player.zone_14 #josh_office
media_player.zone_15 #cara_office
media_player.zone_17 #pool
media_player.zone_18 #living_room
volume_down:
service: media_player.volume_down
target:
entity_id:
media_player.zone_16 #garage
media_player.zone_13 #patio
media_player.zone_11 #master_bedroom
media_player.zone_12 #master_bath
media_player.zone_14 #josh_office
media_player.zone_15 #cara_office
media_player.zone_17 #pool
media_player.zone_18 #living_room
volume_mute:
service: media_player.mute
target:
entity_id:
media_player.zone_16 #garage
media_player.zone_13 #patio
media_player.zone_11 #master_bedroom
media_player.zone_12 #master_bath
media_player.zone_14 #josh_office
media_player.zone_15 #cara_office
media_player.zone_17 #pool
media_player.zone_18 #living_room
select_source:
service: media_player.select_source
target:
entity_id:
media_player.zone_16 #garage
media_player.zone_13 #patio
media_player.zone_11 #master_bedroom
media_player.zone_12 #master_bath
media_player.zone_14 #josh_office
media_player.zone_15 #cara_office
media_player.zone_17 #pool
media_player.zone_18 #living_room
data:
source: "{{ source }}"
volume_set:
service: media_player.volume_set
target:
entity_id:
media_player.zone_16 #garage
media_player.zone_13 #patio
media_player.zone_11 #master_bedroom
media_player.zone_12 #master_bath
media_player.zone_14 #josh_office
media_player.zone_15 #cara_office
media_player.zone_17 #pool
media_player.zone_18 #living_room
data:
volume_level: "{{ volume_level }}"

Can you just format that properly by highlighting all the YAML and press the <> button

  - platform: universal     name: Dax_Zones_MA     unique_id: dax_zma     children:       - media_player.zone_16 #garage       - media_player.zone_13 #patio       - media_player.zone_11 #master_bedroom       - media_player.zone_12 #master_bath       - media_player.zone_14 #josh_office       - media_player.zone_15 #cara_office       - media_player.zone_17 #pool       - media_player.zone_18 #living_room     commands:       turn_on:         service: media_player.turn_on         target:           entity_id:            - media_player.zone_16 #garage           - media_player.zone_13 #patio           - media_player.zone_11 #master_bedroom           - media_player.zone_12 #master_bath           - media_player.zone_14 #josh_office           - media_player.zone_15 #cara_office           - media_player.zone_17 #pool           - media_player.zone_18 #living_room               turn_off:         service: media_player.turn_off         target:           entity_id:           - media_player.zone_16 #garage           - media_player.zone_13 #patio           - media_player.zone_11 #master_bedroom           - media_player.zone_12 #master_bath           - media_player.zone_14 #josh_office           - media_player.zone_15 #cara_office           - media_player.zone_17 #pool           - media_player.zone_18 #living_room       volume_up:         service: media_player.volume_up         target:           entity_id:            - media_player.zone_16 #garage           - media_player.zone_13 #patio           - media_player.zone_11 #master_bedroom           - media_player.zone_12 #master_bath           - media_player.zone_14 #josh_office           - media_player.zone_15 #cara_office           - media_player.zone_17 #pool           - media_player.zone_18 #living_room       volume_down:         service: media_player.volume_down         target:           entity_id:            - media_player.zone_16 #garage           - media_player.zone_13 #patio           - media_player.zone_11 #master_bedroom           - media_player.zone_12 #master_bath           - media_player.zone_14 #josh_office           - media_player.zone_15 #cara_office           - media_player.zone_17 #pool           - media_player.zone_18 #living_room       volume_mute:         service: media_player.mute         target:           entity_id:            - media_player.zone_16 #garage           - media_player.zone_13 #patio           - media_player.zone_11 #master_bedroom           - media_player.zone_12 #master_bath           - media_player.zone_14 #josh_office           - media_player.zone_15 #cara_office           - media_player.zone_17 #pool           - media_player.zone_18 #living_room       select_source:         service: media_player.select_source         target:           entity_id:            - media_player.zone_16 #garage           - media_player.zone_13 #patio           - media_player.zone_11 #master_bedroom           - media_player.zone_12 #master_bath           - media_player.zone_14 #josh_office           - media_player.zone_15 #cara_office           - media_player.zone_17 #pool           - media_player.zone_18 #living_room         data:           source: "{{ source }}"       volume_set:         service: media_player.volume_set         target:           entity_id:            - media_player.zone_16 #garage           - media_player.zone_13 #patio           - media_player.zone_11 #master_bedroom           - media_player.zone_12 #master_bath           - media_player.zone_14 #josh_office           - media_player.zone_15 #cara_office           - media_player.zone_17 #pool           - media_player.zone_18 #living_room         data:           volume_level: "{{ volume_level }}"

platform: universal
name: Dax_Zones_MA
unique_id: dax_zma
children:

media_player.zone_16 #garage
media_player.zone_13 #patio
media_player.zone_11 #master_bedroom
media_player.zone_12 #master_bath
media_player.zone_14 #josh_office
media_player.zone_15 #cara_office
media_player.zone_17 #pool
media_player.zone_18 #living_room
commands:
turn_on:
service: media_player.turn_on
target:
entity_id:

media_player.zone_16 #garage
media_player.zone_13 #patio
media_player.zone_11 #master_bedroom
media_player.zone_12 #master_bath
media_player.zone_14 #josh_office
media_player.zone_15 #cara_office
media_player.zone_17 #pool
media_player.zone_18 #living_room
turn_off:
service: media_player.turn_off
target:
entity_id:
media_player.zone_16 #garage
media_player.zone_13 #patio
media_player.zone_11 #master_bedroom
media_player.zone_12 #master_bath
media_player.zone_14 #josh_office
media_player.zone_15 #cara_office
media_player.zone_17 #pool
media_player.zone_18 #living_room
volume_up:
service: media_player.volume_up
target:
entity_id:
media_player.zone_16 #garage
media_player.zone_13 #patio
media_player.zone_11 #master_bedroom
media_player.zone_12 #master_bath
media_player.zone_14 #josh_office
media_player.zone_15 #cara_office
media_player.zone_17 #pool
media_player.zone_18 #living_room
volume_down:
service: media_player.volume_down
target:
entity_id:
media_player.zone_16 #garage
media_player.zone_13 #patio
media_player.zone_11 #master_bedroom
media_player.zone_12 #master_bath
media_player.zone_14 #josh_office
media_player.zone_15 #cara_office
media_player.zone_17 #pool
media_player.zone_18 #living_room
volume_mute:
service: media_player.mute
target:
entity_id:
media_player.zone_16 #garage
media_player.zone_13 #patio
media_player.zone_11 #master_bedroom
media_player.zone_12 #master_bath
media_player.zone_14 #josh_office
media_player.zone_15 #cara_office
media_player.zone_17 #pool
media_player.zone_18 #living_room
select_source:
service: media_player.select_source
target:
entity_id:
media_player.zone_16 #garage
media_player.zone_13 #patio
media_player.zone_11 #master_bedroom
media_player.zone_12 #master_bath
media_player.zone_14 #josh_office
media_player.zone_15 #cara_office
media_player.zone_17 #pool
media_player.zone_18 #living_room
data:
source: "{{ source }}"
volume_set:
service: media_player.volume_set
target:
entity_id:
media_player.zone_16 #garage
media_player.zone_13 #patio
media_player.zone_11 #master_bedroom
media_player.zone_12 #master_bath
media_player.zone_14 #josh_office
media_player.zone_15 #cara_office
media_player.zone_17 #pool
media_player.zone_18 #living_room
data:
volume_level: "{{ volume_level }}"``

  - platform: universal
    name: Dax_Zones_MA
    unique_id: dax_zma
    children:
      - media_player.zone_16 #garage
      - media_player.zone_13 #patio
      - media_player.zone_11 #master_bedroom
      - media_player.zone_12 #master_bath
      - media_player.zone_14 #josh_office
      - media_player.zone_15 #cara_office
      - media_player.zone_17 #pool
      - media_player.zone_18 #living_room
    commands:
      turn_on:
        service: media_player.turn_on
        target:
          entity_id:
          - media_player.zone_16 #garage
          - media_player.zone_13 #patio
          - media_player.zone_11 #master_bedroom
          - media_player.zone_12 #master_bath
          - media_player.zone_14 #josh_office
          - media_player.zone_15 #cara_office
          - media_player.zone_17 #pool
          - media_player.zone_18 #living_room
      turn_off:
        service: media_player.turn_off
        target:
          entity_id:
          - media_player.zone_16 #garage
          - media_player.zone_13 #patio
          - media_player.zone_11 #master_bedroom
          - media_player.zone_12 #master_bath
          - media_player.zone_14 #josh_office
          - media_player.zone_15 #cara_office
          - media_player.zone_17 #pool
          - media_player.zone_18 #living_room
      volume_up:
        service: media_player.volume_up
        target:
          entity_id:
          - media_player.zone_16 #garage
          - media_player.zone_13 #patio
          - media_player.zone_11 #master_bedroom
          - media_player.zone_12 #master_bath
          - media_player.zone_14 #josh_office
          - media_player.zone_15 #cara_office
          - media_player.zone_17 #pool
          - media_player.zone_18 #living_room
      volume_down:
        service: media_player.volume_down
        target:
          entity_id:
          - media_player.zone_16 #garage
          - media_player.zone_13 #patio
          - media_player.zone_11 #master_bedroom
          - media_player.zone_12 #master_bath
          - media_player.zone_14 #josh_office
          - media_player.zone_15 #cara_office
          - media_player.zone_17 #pool
          - media_player.zone_18 #living_room
      volume_mute:
        service: media_player.mute
        target:
          entity_id:
          - media_player.zone_16 #garage
          - media_player.zone_13 #patio
          - media_player.zone_11 #master_bedroom
          - media_player.zone_12 #master_bath
          - media_player.zone_14 #josh_office
          - media_player.zone_15 #cara_office
          - media_player.zone_17 #pool
          - media_player.zone_18 #living_room
      select_source:
        service: media_player.select_source
        target:
          entity_id:
          - media_player.zone_16 #garage
          - media_player.zone_13 #patio
          - media_player.zone_11 #master_bedroom
          - media_player.zone_12 #master_bath
          - media_player.zone_14 #josh_office
          - media_player.zone_15 #cara_office
          - media_player.zone_17 #pool
          - media_player.zone_18 #living_room
        data:
          source: "{{ source }}"
      volume_set:
        service: media_player.volume_set
        target:
          entity_id:
          - media_player.zone_16 #garage
          - media_player.zone_13 #patio
          - media_player.zone_11 #master_bedroom
          - media_player.zone_12 #master_bath
          - media_player.zone_14 #josh_office
          - media_player.zone_15 #cara_office
          - media_player.zone_17 #pool
          - media_player.zone_18 #living_room
        data:
          volume_level: "{{ volume_level }}"

Sorry about that - You fixed the code or the post?  I do not see any changes to the code?

also the entity called media_player.dax_zone_ma does not show in music assistant - only in HA

Sorry about that - You fixed the code or the post? I do not see any changes to the code?

Just the post

also the entity called media_player.dax_zone_ma does not show in music assistant - only in HA

So confirm it doesn't show in the list of players like this

correct it is not there - but I need each individual zone to show there - the zones do not show in HA or MA

What do you mean by the zones don't show in HA. Aren't the zones these: media_player.zone_15

Also I don't think you are using the universal player properly. I think Marcel might have meant you would have a universal player per zone. I think maybe Marcel was suggesting to recreate the zone wrapped in a universal player. So;
  - platform: universal
    name: Dax_Zone_Garage_MA
    unique_id: dax_z_garage_ma
    children:
      - media_player.zone_16 #garage
    commands:
      turn_on:
        service: media_player.turn_on
        target:
          entity_id:
          - media_player.zone_16 #garage
      turn_off:
        service: media_player.turn_off
        target:
          entity_id:
          - media_player.zone_16 #garage
      volume_up:
        service: media_player.volume_up
        target:
          entity_id:
          - media_player.zone_16 #garage
      volume_down:
        service: media_player.volume_down
        target:
          entity_id:
          - media_player.zone_16 #garage
      volume_mute:
        service: media_player.mute
        target:
          entity_id:
          - media_player.zone_16 #garage
      select_source:
        service: media_player.select_source
        target:
          entity_id:
          - media_player.zone_16 #garage
        data:
          source: "{{ source }}"
      volume_set:
        service: media_player.volume_set
        target:
          entity_id:
          - media_player.zone_16 #garage
        data:
          volume_level: "{{ volume_level }}"

Try that, see if the universal player appears in HA and is usable and then see if it appears in MA. Also I am assuming you can see other HA media players in MA

Yes you are correct - I figured that out last night as I was trouble shooting -  So it does show up in HA but still not MA

I think I figured it out -  In order for MA to acknowledge it - it needs to support play_media  - so I added it to the yaml and it now shows in MA
I really appreciate everything you did to assist in getting me there - Thank You!!!

Hi fin05.
I found this thread as I am pulling the trigger on DAX88 myself.
Have you sorted things out and where you able to fully integrate it with HA/MA ?

@fin05 Just got mine and I am unable to connect to it.
The Hi Fly app that is required for network setup doesnt work on recent android versions ;-(
I am able to ping dhcp assigned ip but I am unable to login to web browser of DAX88. How have you dealt with initial setup?

platform: universal
name: Dax_Zone_Garage_MA
unique_id: dax_z_garage_ma
children:
- media_player.zone_16 #garage
commands:
turn_on:
service: media_player.turn_on
target:
entity_id:
- media_player.zone_16 #garage
turn_off:
service: media_player.turn_off
target:
entity_id:
- media_player.zone_16 #garage
volume_up:
service: media_player.volume_up
target:
entity_id:
- media_player.zone_16 #garage
volume_down:
service: media_player.volume_down
target:
entity_id:
- media_player.zone_16 #garage
volume_mute:
service: media_player.mute
target:
entity_id:
- media_player.zone_16 #garage
select_source:
service: media_player.select_source
target:
entity_id:
- media_player.zone_16 #garage
data:
source: "{{ source }}"
volume_set:
service: media_player.volume_set
target:
entity_id:
- media_player.zone_16 #garage
data:
volume_level: "{{ volume_level }}"

Could you share the play_media code you have added to make it avaible under MA please?


fix: Pass auto session tracking interval to iOS

:scroll: Description
In SwiftSentryFlutterPlugin we look for sessionTrackingIntervalMillis in
the arguments. Instead, it must be autoSessionTrackingIntervalMillis, see https://github.com/getsentry/sentry-dart/blob/8406d676d4839606b89665ed65a99dcdb3910a98/flutter/lib/src/sentry_flutter_options.dart#L35.
:bulb: Motivation and Context
We want to be able to change the autoSessionTrackingIntervalMillis  in iOS.
:green_heart: How did you test it?
With an emulator.
:pencil: Checklist

[x] I reviewed the submitted code
[ ] I added tests to verify changes
[x] All tests passing
[x] No breaking changes

:crystal_ball: Next steps

Codecov Report

Merging #269 (4d2e701) into main (8406d67) will decrease coverage by 5.71%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #269      +/-   ##
==========================================
- Coverage   86.42%   80.71%   -5.72%
==========================================
  Files          52        5      -47
  Lines        1739      223    -1516
==========================================
- Hits         1503      180    -1323
+ Misses        236       43     -193

Impacted Files
Coverage Δ

dart/lib/src/noop_client.dart

dart/lib/src/protocol/sentry_stack_frame.dart

dart/lib/src/protocol/browser.dart

dart/lib/src/transport/noop_transport.dart

dart/lib/src/http_client/sentry_http_client.dart

dart/lib/src/integration.dart

dart/lib/src/default_integrations.dart

dart/lib/src/noop_sentry_client.dart

dart/lib/src/protocol/message.dart

dart/lib/src/utils.dart

... and 37 more

Continue to review full report at Codecov.

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

Codecov Report

Merging #269 (4d2e701) into main (8406d67) will decrease coverage by 5.71%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #269      +/-   ##
==========================================
- Coverage   86.42%   80.71%   -5.72%
==========================================
  Files          52        5      -47
  Lines        1739      223    -1516
==========================================
- Hits         1503      180    -1323
+ Misses        236       43     -193

Impacted Files
Coverage Δ

dart/lib/src/noop_client.dart

dart/lib/src/protocol/sentry_stack_frame.dart

dart/lib/src/protocol/browser.dart

dart/lib/src/transport/noop_transport.dart

dart/lib/src/http_client/sentry_http_client.dart

dart/lib/src/integration.dart

dart/lib/src/default_integrations.dart

dart/lib/src/noop_sentry_client.dart

dart/lib/src/protocol/message.dart

dart/lib/src/utils.dart

... and 37 more

Continue to review full report at Codecov.

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


french translation

Sorry I made a mistake (merged 2 branchs that should not have been merged) that made me delete the repository and re-fork
So here is only the french translation (with update and fix of previously noted errors)
Formspec modifications are separated in an other branch (and PR)
And I made a separate mod to add an "award board" node

Merci pour la relecture !
Ça ne concerne peut être que moi, mais les accents sur autres que é et è (àûÉÈ...) ne s'affichent pas dans le jeu.
Et, pour l'instant, je n'ai pas trouvé d'équivalent satisfaisant en français à l'expression "girl's best friend"
Pour le reste j'ai corrigé tout ce que j'ai vu, j'espère n'avoir rien manqué.
Thanks for the review !
This may apply only for me but accent others than é and è (àûÉÈ...) are not displayed in-game.
And I have not found a satisfying equivalent to the expression  "girl's best friend" yet.
Appart from that, I have corrected everything I've noticed, I hope I haven't missed anything.

About accentuated letters, what version of minetest are you using? If you are using the lastest version and still have problems, please open an issue on https://github.com/minetest/minetest/ , and I will approve this pull request.
If not, try to update your version and check if there are no more problems: if so, please use the accentuated letters in the translation.

You're right about accents ! I hadn't re-checked since I updgarded to 0.4.15
I added missing accents everywhere I could find them.
n.b. :  Do you happen to know where I can read the changelog of minetest 0.4.15

One more untranslated string. Can you fix?

I have rebased this and converted to the new catalog format.
Please review #40.


Ci/GitHub actions

set up tests to also run on github actions.
closes #24
TODO:

coverage
Manifest.in ?

using this tox-gh-actions separates tests into different gh runners, which helps a little with speed. However now there is an annoying amount of actions. I'm not really tied to using it if you'd prefer to not.

Looks like pre-commit is having a lot of trouble on windows. but I can't find anything in tox to like conditionally not do pre-commit on windows, or how to fix this issue.

@mkolopanis I would actually separate the pre-commit stuff from tox altogether -- make it a separate github action.

So currently it is run by tox as what is called flake8 do you mean you'd have another action in the tox suite that is just pre-commit. Or a single github action that only runs pre-commit (presumably on a single OS?) for each push/pr?

Yeah, I'd take the flake8 out of tox, and add a separate github action just to run pre-commit.

Oh I changed the name to remove the reference to "Tox". Looks like you'll have to update the "required checks" since those will never run again.

🎉


[Error] Logged out error 0: For security reasons, you were logged out...

My corp mates and I keep getting this error randomly after using pathfinder for about 30 min to 2 hours. Only some of us are being affected though. What are these security reasons, and how come this keeps happening?
Processor: Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz (4 CPUs), ~3.2GHz
Memory: 8 GB DDR4 SDRAM x 2 Dual-Channel
GPU: MSI GTX 980 (MS-V317)
DirectX Version: DirectX 12
Operating System: Windows 10 Pro 64-bit (10.0, Build 14393) (14393.rs1_release.160915-0644)
Browser: Chrome Version 53.0.2785.143 m

Hi, there is feature in Pathfinder , which will automatically logout every user after 4 hours, you can change this parameter. If this happens randomly, then maybe exodus has some ideas , why this is happening.

dkrotil commented 6 hours ago
Hi, there is feature in Pathfinder , which will automatically logout every user after 4 hours, you can change this parameter. If this happens randomly, then maybe exodus has some ideas , why this is happening.

How do you disable this "feature" I cant seem to find it in the settings.

https://github.com/exodus4d/pathfinder/blob/master/app/pathfinder.ini#L81
240 (default) will log out any user after 240min(4h) Change it it what ever you want.

Im guessing the only way for me to edit the .ini file is if im hosting pathfinder on my own. Which means web users are stuck with the 4 hour log off timer?

@dingdongdiddlerydoo exact. This is just for performance reasons. Inactive users still require a lot network/CPU traffic to keep there maps up2date. There are several hundred active users on my installation, and I can´t handle to much traffic without upgrading my VPS even further (which costs even more €/month). -> Install your own copy of Pathfinder and configure everything to your needs)
So "inactive" users get logged out after 4h.


Loading editor takes a long time

If you find a security vulnerability, do NOT open an issue. Email<EMAIL_ADDRESS>instead.
Describe the bug
Loading editor takes a long time, even if the content is very small
To Reproduce
open a document using this Markdown Editor
Expected behavior
load Markdown Editor faster
Screenshots

Which versions of Sanity are you using?
Run sanity versions in the terminal and copy-paste the result here.
What operating system are you using?
macOS 14.4.1 (23E224)
Which versions of Node.js / npm are you running?
npm -v && node -v
10.7.0
v22.2.0

Additional context
the source code of CustomMarkdownInput
import { useMemo } from 'react';
import { MarkdownInput, MarkdownInputProps } from 'sanity-plugin-markdown';

import<EMAIL_ADDRESS>import 'easymde/dist/easymde.min.css';

const mdeOptions = {
    toolbar: ["heading", "bold", "italic", "strikethrough",
        "code", "quote", "unordered-list", "ordered-list",
        "link", "upload-image", "horizontal-rule",
        "preview", "side-by-side"],
    previewClass: ['prose', 'prose-slate', 'dark:prose-invert',
        'bg-background', 'text-foreground'],
};

export function CustomMarkdownInput(props: MarkdownInputProps) {
    const reactMdeProps: MarkdownInputProps['reactMdeProps'] =
        useMemo(() => {
            return {
                options: mdeOptions,
            }
        }, []);

    return <MarkdownInput {...props} reactMdeProps={reactMdeProps} />
}

The editor seems to be OK if I turned off disable cache on Chrome Inspector, so I close this issue.


[feature] Ease the postCSS customization

Submit a feature request or bug report

[x] I've read the guidelines for Contributing to Roots Projects
[x] This is a feature request
[x] This is a bug report
[x] This request isn't a duplicate of an existing issue
[x] I've read the docs and NPM Debugging Guidelines post and followed them (if applicable)
[x] This is not a personal support request that should be posted on the Roots Discourse forums

Currently, the only way to use custom postCSS modules (other than autoprefixer) is overriding a resources/assets/build/webpack.config.js which is of course bad idea if you want to stick with the latest Sage version. It would be very nice to provide some clean and easy way for enabling more postCSS modules (in my case it is lost but there are more of them).
General idea for providing build process extensibility without modifications:

Conditionaly require all files from e.g.resources/assets/build/custom/ (a new folder in the building structure which will be empty by default but may be filled with a custom scripts)
Provide some kind of API for the custom scripts

Does it fit to the Sage concept? If so I may implement such feature and send you a PR.

Can you check the PR I put up yesterday. I think it would be sufficient for what you're asking.
postcss.config.js: https://github.com/roots/sage/blob/update-dependencies/resources/assets/build/postcss.config.js
The function receives the following:

file: the current file being processed by postcss
options: the same config object that's used throughout all of our webpack routine
env: an alias of process.env.NODE_ENV, which we now set

Docs: https://github.com/postcss/postcss-loader#usage
If that satisfies what you're asking, feel free to close this issue.

This is similar to the existing problem. I can modify the postcss.config.js but then I will have to manually merge this file each time there will be some changes in it.
What I want to do is creating some API like the Wordpress Hooks system, which will allow for an easy extension without a need for modifications. For starters (and as an example) I would provide two hooks configReady (where you can modify webpack config just before it is used by webpack) and postcssReady (for postCSS arguments modification). The use of this API will be completely optional but it should make the build much more flexible.
Should I implement it or you don't want such feature?

There is a similar issue #1931 in regards only being able to process/lint SCSS files with the way that webpack.config.js is presently set up. I suggested there, to use Jeffrey Way's Laravel Mix which provides an API for defining basic webpack build steps. You will be able to define any postCSS modules to your hearts content.

Sage 10 will be using Laravel Mix which makes working with postCSS significantly easier.


fix(v3): Add --client-only and fix --validate for helm template

A.k.a "allow helm template to optionally skip api versions check while keeping existing use-cases and features as-is"
This introduces a new flag --client-only to helm template, so that (1)we can optionally disable the validation at all, (2)while keeping the ability to switch what are validated.
(1) is achieved by changing the semantics of the existing flag --validate=[true|false] new in v3 and (2) is achieved by adding --client-only=[true|false] that mostly the same as the former --validate.
This should address all the three use-cases listed in https://github.com/helm/helm/pull/6729#issuecomment-547249311 after fixing other related bugs.
Closes #6505
Replaces #6729

Even though the semantics of the existing flag --validate has changed, the existing and default behavior of helm template is maintained. That is, helm template without any flags means do client-only validation before/after this change.
Regarding changes in the --validate, as you can see from the existing code-base and the description of the flag, unlike it's name, it had been used for toggling the client-only mode of the validation. For instance, helm template [--validate=false] had been left api versions check running even though, --validate=false or omitting the flag would had disabled the whole validation according to it's name.
This change adds --client-only so that we can toggle the validation and the client-only mode separately, which allows more granular control, and more specifically, support the do not validate at all scenario.

Hey @mumoshu! We merged #6817 to fix the main issue, but we think there is still some value for being able to turn off all API validation during an install or upgrade (for the "YOLO cases"), so we are keeping this one open in case you want to continue forward with the NoValidate option

Hey @mumoshu. https://github.com/helm/helm/pull/6819 should be identical to the feature proposed in this PR now that #6817 has been merged. I feel that a more descriptive flag than --client-only is the right approach here, as that flag has implications with Helm 2's helm version --client-only flag, implying that TIller is still somehow involved.
Let me know what you think

@thomastaylor312 Thanks! It all makes sense now.
One of my purposes for this PR was to be able to disable the api-versions check, and your change did resolve that. So I have no use for this PR at least in that regard.

Hey @bacongobbler, thanks a lot for all your hard work and releasing rc.2! I tested it today and it worked like a charm with helmfile and helm-diff 🎉
--disable-openapi-validation looks much better. But I don't have a specific use-case for that myself.
I think I just happened to cover some of --disable-openapi-validation use-case in this PR due to the way I tried to make the api-versions check togglable. I thought it was necessary, but turned out we could just remove the api-versions check in the sorter instead.
That said, anyways, I'm fine with closing this PR as not necessary anymore.
Re --disable-openapi-validation, I believe there's no specific and concrete use-case for --disable-openapi-validation yet, as you've also mentioned in the PR.
Perhaps we can close it for now to reduce the maintenance work and focus on GA of v3.0.0, and wait for anyone to raise an issue with real use-case(s) that can possibly be addressed with --disable-openapi-validation?
Also, I understand your concerns on the naming of --validation. I have no better idea either.
But I believe that the name works for most people now. Now that the vanilla helm template doesn't berk on api-versions anymore, it would LOOK LIKE to have no validations by default. Implementation-wise that might be wrong, but U/X wise that's fine as long as they encounter any real problem.

Closing this as unnecessary now. Thanks a lot for all your works and thoughtful responses! You made my day 😄