Variable length brittleness

Variable length brittleness
Context in GR
We use Simple Binary Encoding (SBE) a lot within GR - dozens of apps sending / receiving countless messages every day. We interact with the data format using auto-generated code in both C++ and C#.
In both languages we have use cases which are:

latency-sensitive (e.g. live trading)
not latency-sensitive (e.g. post-trade analysis)

We often pass around lists / strings whose length we can't know ahead of time, using the variable length feature in SBE for this purpose.
Problem
Accessing a variable length SBE property modifies the state of the auto-generated C++ / C# class by advancing an offset field. Client code has to access every variable length property exactly once, in order.
This makes SBE brittle to work with. For example:

Code must read all variable length fields, even if it only needs to access a subset of fields

We can work around this by inserting unused reads to trigger the advancing of the offset, but this remains error-prone

Writing tests which interact with SBE is harder, due to the error-prone nature of building / asserting on a test message
The debugger can exhibit undesirable behaviour by attempting to evaluate property values, but doesn't know it must do this in a specific order

Given the above, workflows for interacting with variable length properties typically involve either:

Allocating SBE classes to / from in-house DTOs whose fields can be safely accessed in any order
Writing the code carefully once, with a "never touch this again" mindset adopted after that

Requested enhancements
1. Auto-generate DTOs
In any context which is not sensitive to latency / memory allocations, mapping the SBE message to / from an auto-generated SBE DTO avoids this issue. In practice this is already regularly done at GR, with the DTO and mapping code either auto-generated by an in-house tool or manually written.
These DTOs would also be useful in testing of latency-sensitive apps; they would make it easier to construct sample messages to be processed in a test, with less risk that the test code itself is wrong.
We would like to request that the DTOs are added to the auto-generated C++ / C# code.
2. Debug-only checks
We think it would be useful to add runtime checks to the auto-generated C++ / C# code which do the following:

In a debug build (possibly indicated by some cli flag or #define to the generator):

Register calls that access variable length properties
If variable length properties are access out-of-order, throw an exception with a diagnostic error message

In a release build:

Do nothing. Ideally, don't even compile the code which enforces the check

These checks have the advantage that:

No change to client code is required - these checks are triggered behind the scenes in a debug build, with no performance hit in a release build
Teams at GR could readily incorporate these checks into existing continuous integration plans which run tests in a debug build (sometimes this also includes the C++ address sanitizer)

Summary
The central issue is the brittleness of working with variable length SBE given the "access every field exactly once in order" limitation. This represents a significant usability issue for us.
The two feature requests described in this document would both be useful additions and help establish SBE as the binary message tool of choice within GR's C++ / C# applications. The DTOs are more important to us than the debug-only checks but ideally we would like both features.

@grlrrchapman Thanks for this.
This is something that we have considered for a while now. It is something we would like to get time to do. And even looked into it in the past, it doesn't seem out of scope to do. It has been, though, of a lower priority than other items. One of the things that working with Adaptive allows us to do is get to a long backlog of things in the various projects. Hopefully, this is one we can get to in the near future.
I see this repo is public. But would you mind posting this, or an edited version of it, on the main repo we can make comments on and track? Perhaps someone might even pick it up in the future and contribute to it.

Thanks for your response @tmontgomery - I appreciate it.
I raised this issue here to mark it as one which GR is keen to prioritise; following some discussions with @mjpt777, this was the proposed way of following up on the issues we've raised. In a similar fashion we are also raising Aeron-related issues in https://github.com/G-Research/aeron/issues. I don't mind raising an edited version of this issue in the main repo if that's the most pragmatic way to bump this up your backlog, but probably best to catch up offline to clarify this first.


Astro 3.0 breaking changes tracker

📋 Explain your issue
This issue is to track 3.0 breaking changes to be part of the guide. Will add things to this through comments, using this template:
### [changed/removed/added/deprecated] feature/name/title/description
In Astro v2.x, [ a statement in the past tense about what Astro did/used to do. e.g. Astro bundled all assets into several different folders....]

Astro v3.0 [ a statement in the present tense about how Astro works now. e.g. now bundles all assets into one single folder located in... ]

#### What should I do?

[Active sentences in the imperative (command) tense, with code examples showing diffs as appropriate]

e.g. Update... / Remove... / Replace... / Create...

Example upgrade guide: https://docs.astro.build/en/guides/upgrade-to/v2/

Removed support for Node 16
In Astro v2.x, Node 16 was supported.
Astro v3.0 it's not the case anymore, the lowest supported version is now v18.14.1
What should I do?
https://docs.astro.build/en/guides/upgrade-to/v2/ has a section for when we dropped Node 14, so it'll be pretty much the same thing. This page also has a mention of the supported version: https://docs.astro.build/en/install/auto/
If a technical reason is wanted, Node 16 is getting deprecated in September, so not too long after Astro 3.0 releases. Additionally v18.14.1 was chosen specifically because of bugs in previous versions of Node 18

Deprecated lowercase function endpoints
In Astro v2.x, endpoints are defined using lowercase function names: get, post, put, all, and del.
Astro v3.0 deprecates them in favour of uppercase function names.
What should I do?
Update the names as follow:

get to GET
post to POST
put to PUT
all to ALL
del to DELETE

[changed/removed/added/deprecated] feature/name/title/description
In Astro v2.x, we would magically flatten the result of getStaticPaths automatically for the user, so if you returned an array of array, it would still work
Astro v3.0 we removed this in favour of the user doing it themselves when they need to, in line with how we typically prefer for users to do explicit things.
What should I do?
If you're returning an array of arrays instead of an array of object (as you should), please flatten it using .flat(), or if you're using a .map(), use .flatMap() instead
(we also added an error message for this)

Changed internal MDX and JSX plugins sorting responsibility
In Astro v2.x, Astro core would sort the MDX plugin before the JSX plugin to transform code correctly.
Astro v3.0 now lets the MDX integration (@astrojs/mdx) be responsible for the plugin sorting. Astro core does not have hardcoded MDX plugin sorting handling.
What should I do?
Update @astrojs/mdx to latest.
(PR: https://github.com/withastro/astro/pull/7872)

[changed/removed/added/deprecated] feature/name/title/description
In Astro v2.x, Astro.cookies.get(key) would always return a AstroCookie object, even if the cookie did not exist. To check for the existence you needed to use Astro.cookies.has(key).
Astro v3.0 Astro.cookies.get(key) will return undefined if the cookie does not exist.
What should I do?
With TypeScript you will need to use the ! assertion when getting a cookie that you know exists:
---
if(Astro.cookies.has(id)) {
  const id = Astro.cookies.get(id)!;
}
---

If you could also skip has() and just check if the value is undefined like so:
---
const id = Astro.cookies.get(id)!;
if(id) {
  // TypeScript knows id is an AstroCookie
}
---

Changed astro check command to use an external package @astrojs/check
In Astro v2.x, astro check's dependencies were bundled in Astro. This was problematic because it meant a larger package even if you don't use astro check and also prevented users from having control over the version of TypeScript and the Astro Language Server to use
Astro v3.0, astro check now requires @astrojs/check and typescript to be installed into the user's project. When starting astro check without those dependencies being present, Astro will prompt the user to install them, like so:

What should I do?
Either run astro check and press Yes at the "Astro will install the deps for you" question, or manually install @astrojs/check and typescript into your project

[changed/removed/added/deprecated] feature/name/title/description
In Astro v2.x, Squoosh was the default image service
Astro v3.0, Sharp is now the default image service
What should I do?
For 99.999% of people, nothing! This change is invisible. However, if you still need the Squoosh service for some reason, you can use it like this:
import { defineConfig, squooshImageService } from "astro/config";

// https://astro.build/config
export default defineConfig({
  image: {
    service: squooshImageService(),
  }
})

But be warned that it will highly probably be removed in the future.

Changed internal MDX custom components export handling responsibility
In Astro v2.x, the export const components feature in MDX is handled through Astro core, causing MDX integration logic tied to core.
Astro v3.0 moves this responsibility back to the MDX integration to handle it itself.
What should I do?
Update @astrojs/mdx to latest.
(PR: https://github.com/withastro/astro/pull/7904)

Removed @astrojs/image
In Astro v2.x, this package existed
Astro v3.0, it does not anymore, replaced by astro:assets
What should I do?
Migrate to astro:assets. In .astro files this is really just a replace @astrojs/image by astro:assets in most cases, however if you used the Picture component, you'll need at this time to recreate it using the getImage APIs.

changed - default port used
In Astro v2.x, Astro ran on port 3000 by default
Astro v3.0 changes the default port to 4321 🚀
What should I do?
Update any references to localhost:3000 for example in tests or in your README
(Discord user reported this as a breaking change: https://discord.com/channels/830184174198718474/830184175176122389/1136797603393183775 )

Removed @astrojs/markdown-component support
In Astro v2.x, it included internal code to keep @astrojs/markdown-component working, which had been deprecated since Astro v1. This increases the SSR bundle size for projects not using the <Markdown /> component.
Astro v3.0 removes the internal code, so <Markdown /> will no longer work.
What should I do?
Remove usages of <Markdown /> and the @astrojs/markdown-component package, or use community packages that provide a similar component like https://github.com/natemoo-re/astro-remote instead.
(PR: https://github.com/withastro/astro/pull/7931)

NOTE FOR SARAH Issues are now for beta.1 changelog entries

Changed import.meta.env.BASE_URL default trailingSlash behaviour
In Astro v2.x, import.meta.env.BASE_URL, which derives from base config, is always appended a trailingSlash by default or when trailingSlash: "ignore" is set.
Astro v3.0 import.meta.env.BASE_URL is not appended with a trailingSlash by default or when trailingSlash: "ignore" is set. The existing behavior of base in combination with trailingSlash: "always" or trailingSlash: "never" is unchanged.
What should I do?
If your base already has a trailing slash, no change is needed.
If your base does not have a trailing slash, add one to preserve the previous behaviour:
// astro.config.mjs
- base: 'my-base',
+ base: 'my-base/',

(PR: https://github.com/withastro/astro/pull/7878)

deprecated build.excludeMiddleware and build.split
In Astro v2.x, build.excludeMiddleware and build.split could be used to change how specific files were emitted.
Astro v3.0, these options have been deprecated.
What should I do?
Update the config file to use the option in the adapter.
import { defineConfig } from "astro/config";
import vercel from "@astrojs/vercel/serverless";

export default defineConfig({
     build: {
-        excludeMiddleware: true
     },
     adapter: vercel({
+        edgeMiddleware: true
     }),
});

import { defineConfig } from "astro/config";
import vercel from "@astrojs/vercel/serverless";

export default defineConfig({
     build: {
-        split: true
     },
     adapter: vercel({
+        functionPerRoute: true
     }),
});

Changed tsconfig.json presets
In Astro v2.x, the tsconfig.json presets include support for both TypeScript 4.x and 5.x.
Astro v3.0 updates the tsconfig.json presets to only support TypeScript 5.x.
What should I do?
Update your TypeScript version to at least v5.0.
npm install typescript@latest --save-dev

(PR: https://github.com/withastro/astro/pull/7785)

Added simple asset support for Cloudflare, Deno, Vercel Edge and Netlify Edge
In Astro v2.x, using the assets feature in Cloudflare, Deno, Vercel Edge and Netlify Edge errors in runtime as the environments do not support Astro's builtin Squoosh and Sharp image optimization.
Astro v3.0 allows these environments to work without errors, but does not perform any image transformation and processing. However, you would still get benefits, e.g. no Cumulative Layout Shift (CLS), enforced alt attribute, etc.
What should I do?
If you previously avoided the assets feature due these constraints, you can now use them without issues. You can also use the no-op image service to explicitly opt-in to this behaviour:
// astro.config.mjs
export default {
  image: {
    service: {
      entrypoint: 'astro/assets/services/noop'
    }
  }
}

(PR: https://github.com/withastro/astro/pull/7903)

Changed the default value of scopedStyleStrategy
In Astro v2.x, the default value of scopedStyleStrategy was "where".
Astro v3.0, the default value is "attribute"
What should I do?
You need to update the configuration file if you want to retain the old behaviour
export default defineConfig({
+	scopedStyleStrategy: "where"
})

Changed Multiple JSX framework configuration
In Astro v2.x, you could use multiple JSX framework integrations (React, Solid, Preact) in the same project and Astro without having to identify which files belonged to which framework.
Astro v3.0, in order to better support single-framework usage, now requires that you specify which files are included in each integrations config. This change is only needed if using more than one of these frameworks; otherwise no configuration is needed.
What should I do?
When using multiple JSX frameworks in the same project, use the include and/or exclude configuration options to specify which files belong to which framework. We recommend having common framework components in the same folder; for ex. components/react/ and components/solid/. This is not required but makes configuration easier:
import { defineConfig } from 'astro/config';
import preact from '@astrojs/preact';
import react from '@astrojs/react';
import svelte from '@astrojs/svelte';
import vue from '@astrojs/vue';
import solid from '@astrojs/solid-js';

export default defineConfig({
  // Enable many frameworks to support all different kinds of components.
  integrations: [
    preact({ include: ['**/preact/*'] }),
    solid({ include: ['**/solid/*'] }),
    react({ include: ['**/react/*'] }),
  ],
});

Removed kebab-case transform for camelCase CSS variables
In Astro v2.x, camelCase CSS variables passed to the style attribute are rendered as camelCase (original) and kebab-case (incorrect by kept for backwards compatibility).
Astro v3.0 the kebab-case transform is removed. Only the original camelCase CSS variable is rendered.
---
const myValue = "red"
---

What should I do?
If you were relying on the kebab-case transform in your styles, make sure to use the camelCase version to prevent missing styles. For example:

(PR: https://github.com/withastro/astro/pull/8019)

Changed entrypoint export paths
In Astro v2.x, you can import internal Astro APIs from astro/internal/* and astro/runtime/server/*.
Astro v3.0 removes the two entrypoints in favour of the existing astro/runtime/* entrypoint.
What should I do?
These are entrypoints for Astro's internal API and should not affect your project, but if you do use these entrypoints, you can migrate like below:
- import 'astro/internal/index.js';
+ import 'astro/runtime/server/index.js';

- import 'astro/server/index.js';
+ import 'astro/runtime/server/index.js';

(PR: https://github.com/withastro/astro/pull/8085)

[changed/removed/added/deprecated] feature/name/title/description
In Astro v2.x, Astro serialized props passed to Astro Islands as JSON embedded in an HTML attribute.
Astro v3.0 now uses a more efficient serialization library to embed serialized props as a script.
What should I do?
This update should not change any user-facing behavior, but developer-facing tools that inspect Astro Islands may need to be updated to support this new output format.
- <astro-island props="{\"value\":\"Hello world!\"}">
+ <astro-island>
+

Hello world!

  </astro-island>

(PR: https://github.com/withastro/astro/pull/8004)

Small stylesheets now get inlined by default
In Astro v2.x, all project stylesheets were sent as  tags by default, and you could opt-in to inlining them by using the build.inlineStylesheets configuration.
Astro v3.0 defaults inlineStylesheets to "auto", which means stylesheets smaller than 4kB get included in the initial response.
What should I do?
Nothing, this change does not require any migration. To go back to the old behavior, configure inlineStylesheets to "never"
export default defineConfig({
    build: {
+       inlineStylesheets: "never"
    }
})

(PR: https://github.com/withastro/astro/pull/8118)

Changed implementation of class:list directive
In Astro v2.x, class:list used a custom implementation inspired by clsx with a few extra features like deduplication and Set support.
In Astro v3.0, class:list uses clsx directly, which does not support deduplication or Set values.
What should I do?
Replace any Set elements passed to the class:list directive with a plain Array.
 <Component class:list={[
    'a',
    'b',
-   new Set(['c', 'd'])
+   ['c', 'd']
  ]} />

(PR: https://github.com/withastro/astro/pull/8142)

Changed behavior of class:list directive for components
In Astro v2.x, class:list values were sent to components via Astro.props['class:list'].
In Astro v3.0, class:list values are normalized into a string before being sent to components via Astro.props['class']
What should I do?
Remove any code that expects to receive the class:list prop.
---
- import { clsx } from 'clsx';
- const { class: className, 'class:list': classList } = Astro.props;
+ const { class: className } = Astro.props;
---

(PR: https://github.com/withastro/astro/pull/8142)

(Sarah's placeholder entry)
Unexperimenalized: astro:assets
In Astro v2.x, astro:assets and the Image Services API was behind an experimental flag.
Astro v3.0 unflags these image services and replaces the former @astrojs/image integration, which has been completely removed and is no longer supported.
What should I do?
Read Sarah's amazing image upgrade guide cover to cover!

Changed astro package entrypoint exports
In Astro v2.x, the "astro" package entrypoint exported and ran the Astro CLI directly. It is not recommended to run Astro this way in practice.
Astro v3.0 removes the CLI from the entrypoint, and exports a new set of experimental JavaScript APIs, including dev(), build(), preview(), and sync().
What should I do?
If wanted to run the Astro CLI programatically, you can use the new experimental JavaScript APIs:
import { dev, build } from "astro";

// Start the Astro dev server
const devServer = await dev();
await devServer.stop();

// Build your Astro project
await build();

(PR: https://github.com/withastro/astro/pull/7979)

Deprecated the markdown.drafts configuration option
In Astro v2.x, markdown.drafts is used to create draft pages that are viewable in dev, but not in prod.
Astro v3.0 deprecates this feature in favour of Content Collections and handling drafts filtering manually instead, which gives more control of the feature.
What should I do?
You should migrate to content collections and manually filter out pages with the draft: true frontmatter property instead.
(PR: https://github.com/withastro/astro/pull/8099)

Changed how scoped style hashes
In Astro v2.x, scoped style hashes were uppercase.
Astro v3.0 generates hashes in lowercase.
What should I do?
Nothing

I am closing this (final v3.0) issue!  :partying_face:
This is now our source of truth for breaking changes. Any corrections/updates before Wednesday can go directly to PR #4166
Deploy preview of the upgrade guide
Thanks, everyone! I loved this process and it was exceptionally helpful. Let's do this again... BUT NOT SOON.  :raised_hands:


"Crucea" is listed in the drop-down menu

Description:
When user writes "Crucea" the location appears in the drop-down menu next to the comune and the county witch is a part according to the law
Precondition:
The website is up an running.

Step 1
Write in the search bar "Crucea"

Expected results
The location appears in the drop-down menu as "Comuna Crucea, CONSTANȚA"


ENH: Added script to assist with using CLion from a superbuild enviro…

…nment.

@hjmjohnson You committed this to the SuperResolutionCode branch only. I think it would be good to have as part of master. I also change the file to an executable.


$Service is now deprecated. Use $uibService instead.

I've updated to 0.14.0 to make use of the fixed tooltips and a few other things and I now have the warning listed in the comment. Are there some ongoing issues regarding migrating to 0.14.0? For example, I have no instances of $tooltip used within my app, but I still get the warning to use $uibTooltip and to use uib-tooltip-html-popup. Similarly, after replacing all $modal instances with $uibModal, I still receive the warnings. I did also try updating the directives on the page to uib-tooltip-... as well.

Even if your are not using the $tooltip service, the message tells you to replace all tooltip classes and directives like:
  =>

There could be some edge cases where you see a deprecation warning when you shouldn't.
I tracked lot of them and I wasn't able to get more.
Check the migration guide (link on readme) and see if you're missing something.

Yeah I've taken a look at the migration guide. I'm only using tooltip in one HTML file currently, so I know the warning can't be coming from anywhere else. I replaced all instances of tooltip with uib-tooltip (although I didn't see any information for tooltip-class in the guide/source code as uib-tooltip-classes threw some errors) and the warning still appears. To be more specific I'm using tooltip-html, tooltip-class, tooltip-position and tooltip-html.

@declanelcocks Can you create a plunker with the popover that is causing that issue for you?

@Foxandxss Sorry for slacking on the replies, I had to move on to working on something else first as this was a minor issue in my project. I will try to play around with this before the weekend and let you know how it goes. I believe after updating the demo page, it's a bit easier to understand the migration so it may just be a simple error on my end.

@Foxandxss I was able to reproduce a misleading deprecation warning with the popover class.
Here is a plunkr of the issue.

@Dilatorily Correct, I receive warnings for this as well but the warning should be a bit more explicit as you find yourself looking through the source code for tooltip rather than popover

@declanelcocks I agree. Other libraries use the Bootstrap's popover class, and they will create a false deprecation warning.
If the warnings could be clearer by having the right source, and by having the right use case (element, attribute, or class), it would have saved me a lot of headaches.

@Dilatorily Angular will process all classes in the HTML and check if they are directives.
I spent at least 5 hours figuring it out and we had to do some workarounds to avoid that.
I think I can go one step further to make it better. Will investigate.
Also, I will investigate if I can make the warning a bit more useful.

@Foxandxss It's a very picky improvement so it's not much of a big deal 😊

It was a dead end at the end.
I am playing with logging the element and attributes for each deprecation. Way more verbose now, so I am not entirely sure if it is a good idea.
Will discuss it with the other guys.

Well, we thought that there is no best way to improve the error messages and since this issue is now resolved, I am closing this.

I also tinkered on my side to try to disable the deprecation warning when it gets called from popover.
In the end, I had the same conclusion as @Foxandxss and just disabled all $tooltip deprecation warnings.
Relevant snippet of code:
$provide.decorator('$tooltipSuppressWarning', function () { return true; });

If you really need to add that tooltip class by hand (I Don't think there is a real need) yes, better disable it.
Still, you don't need to decorate it, it is just a service. Inject it in a .config method and disable it.

So I'm confused here.  The deprecation warnings are totally superfluous.  Why are you wanting to disable them?  Why can't you change the directive names?

Guys, what do you think about cutting a new release with the old (unprefixed) things dropped? I understand that we want to be nice to users but it seems like there are corner cases / issues on ng side to do it properly. On top of this supporting 2 sets of directives adds bytes to the library, runtime overhead etc.
If users want / need to migrate this is a relatively simple process (search and replace).
WDYT?

The main goals was to make the transition as painless as possible, that is why we did all this extra work to having both versions to coexist.
Our implementation is not flawless but I think we covered almost all use cases. The use case in here is a very concrete use case that can be silenced easily.
The goal is also to provide time to people to upgrade. There is some overhead, I agree, but is not that big.
The big concern right now is to have versioned docs (which I am fixing in this very moment). After that, we could consider that big BC.

Hi.
I encountered same issue, I searched all over the project for missed piece of code to be renamed but ended with no result.
Then I remembered that we extended 'template/tooltip/tooltip-html-popup.html' template like so:
angular.module('template/tooltip/tooltip-html-popup.html', []).run(['$templateCache', function($templateCache) {
    $templateCache.put('template/tooltip/tooltip-html-popup.html',
        '
\n' +
        '

\n' +
        '

\n' +
        '
\n' +
        '');
}]);

we did it before upgrading to 0.14.x.
I found that class="tooltip" actually thats what was reason behind the warning, it was removed in 0.14.x.
http://plnkr.co/edit/VFnXUMuQRi6RS3biXKG9?p=preview
Hope it helps someone.

@Vladimir-Purple this is the danger when using custom templates - one should scour the changelog for any major changes there that could impact templates
@pkozlowski-opensource I have been thinking about that - I think we should potentially explore moving to 1.0 in a few weeks (I'm hoping to have a 1.0 release in a month from now or so), we currently have been focused on monitoring any critical issues related to prefixing or tooltip/popover issues to ensure we can move fast to fix them & making new releases when the bugs were critical (i.e. garbage collection issues or breaking 1.3 compatibility).

Will the service names still be prefixed with $? What for? Isn't this prefix reserved for Angular's own services only?

I think the same, but we decided to leave it with $.

It's a bad example for other library authors. Why not drop it if you're renaming things anyway?

I talked about it at #4373

Closing as I believe we have done all we can for helpful prefixing warning for 0.14.x - we have started 1.0 work and stripped out the deprecated directives/services in master.

If I upgrade to 0.14.x.There has to be a way to ignored warning message with do not add any prefix?

@kimx, I've no idea what you're trying to ask so I'm just going to take stab in the dark here.  If you want to turn off the warning messages, yes, there is a way.  Each component has its own warning suppression flag.
E.g., taking a look at the alert component, specifically, the diff where the deprecated code was removed, you can see that it checks the $alertSuppressWarning flag for when deprecated directives, i.e., those without prefixes are used.
If this is not what you meant, please clarify your question and let us know.  Cheers.

@icfantv  The answer is what I want,thanks you.
I have another question is that turn off the warning messages can be used all of next release in the future or will until specific version then cannot use.

next version won't have warning messages nor old non prefixed directives. You're forced to put the prefix if you want to update to the next version.

@kimx, they've already been removed in master meaning the next release, 1.0.0, all the deprecated code will no longer be supported as it will be removed.
Disabling any deprecation warnings is usually a bad idea as the API is trying to tell you to do something via the new way and if you disable them, well....one day you're going to upgrade and stuff isn't going to work anymore.

@Foxandxss  @icfantv  I got it,thank you all answer me.


Refactor/refactor for dynamic connection

⚠   Pre Checklist

Please complete ALL items in this checklist, and remove before submitting

[ ] I have read through the Contributing Documentation & PR Template
[ ] This PR is using a label (bug, feature etc.)
[ ] My code is has necessary documentation (if appropriate)
[ ] I have added any relevant tests
[ ] This section (⚠   Pre Checklist) will be removed when submitting PR

Summary

Does this close any open issues?
Please mention the issues here.
Screenshots
Include any relevant screenshots here.
Other Information
Any other information that is important to this PR.

@likyh @klesh I have a different plan for setting up dynamic plugins that I am drafting, I don't agree with much of the changes on this PR. Please invest time in feature tickets and stop refactoring UI.

@likyh @klesh Some of the intended goals on this ticket will be addressed and adapted for use with #2882

@likyh @klesh I have a different plan for setting up dynamic plugins that I am drafting, I don't agree with much of the changes on this PR. Please invest time in feature tickets and stop refactoring UI.

Please support my idea. Or tell me why don't agree.

@likyh @klesh I have a different plan for setting up dynamic plugins that I am drafting, I don't agree with much of the changes on this PR. Please invest time in feature tickets and stop refactoring UI.

Please support my idea. Or tell me why don't agree. @e2corporation

@likyh As lead maintainer on UI I have more time invested in the frontend codebase, I have a certain idea of how the configuration system should evolve. Instead of the Product Owner creating a detailed ticket on the needs of "Dynamic" Plugins etc., you are taking it upon yourself without any discussion with me at all to refactor code that has hours of time in development and testing applied to it. This is not proper team co-ordination, and as you continue to run this nature of a refactor we have new features to add to this sprint and I need the UI system to be in a known state. All this time could have been invested in the other feature ticket I opened for Gitlab Proxy. It's not that I don't support your idea, but it has to be inline with my strategy. I already mentioned some of the goals you have on this PR will be accomplished on the other ticket and you will have the opportunity to continue development work there.


Valid drop frame values fail to parse

Hello! Thank you for creating this library, it's been a huge help. I ran into an issue where drop frame values are failing to parse when they're too few frames beyond a minute boundary. So for instance, 20:22:47;02 in 59.94DF should be fine, but that failed with drop-frame tc cannot have a frames value of less than 4 on minutes not divisible by 10, found '2'.
It looks like the drop_frame_tc_adjustment function is checking for multiples of 10 minutes when doing this check, but it didn't look at the seconds value.
I made a pull request here with a fix: https://github.com/opencinemac/vtc-rs/pull/6 (and no rush, I'm operating off my fork in the meantime)

Hello!
Thanks for filling this issue. I've already left a comment on the PR but just wanted to comment here as well and say thanks for using the lib!

Fixed by #11


blockchain_market_price_history returns open/close outside of low/high range

https://bitsharestalk.org/index.php?topic=10171.msg133005#msg133005

Superseded by: #1300


build: Add BUILD_WSI options

This PR adds BUILD_WSI_XCB_SUPPORT  , BUILD_WSI_XLIB_SUPPORT  and BUILD_WSI_WAYLAND_SUPPORT  which match other projects within the vulkan-sdk like VulkanTools or Vulkan-Loader. Note that this will replace NO_XCB with BUILD_WSI_XCB_SUPPORT  to remain consistent.
https://github.com/LunarG/VulkanTools/blob/5fdd9fc4724680d4267a101728a8adeff043df50/CMakeLists.txt#L106
https://github.com/KhronosGroup/Vulkan-Loader/blob/a132dee142c0d6bf54d09d50ed7fff28f4b491ef/CMakeLists.txt#L121

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

CI gfxreconstruct build queued with queue ID 9033.

CI gfxreconstruct build # 53 running.

CI gfxreconstruct build # 53 passed.

Looks good, thanks!


cli: Implement resource removal

Allow removal of resources via CLI
Closes #1413

Changed removal to only delete modified env vars.
Added assertions that test this behaviour.

LGTM!


Fix some typos

This PR is fix some typos.

@ydah Thanks for this, but unfortunately you'll need to bump a potential version. Can be done with yarn version:bump:bin patch.

Thanks for the review. Commit has been added. How do you like it?

Thank you!


Exception system_install with vagrant

I'm trying to install rvm::system_install from vagrant but getting the following error
[Fri, 27 Apr 2012 12:55:02 -0700] INFO: Processing execute[install system-wide RVM] action run (rvm::system_install line 69)
[Fri, 27 Apr 2012 12:55:02 -0700] INFO: execute[install system-wide RVM] sh(            bash -c "bash               <( curl -Ls https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer )"
)
[Fri, 27 Apr 2012 12:55:06 -0700] ERROR: execute[install system-wide RVM] (rvm::system_install line 69) has had an error
[Fri, 27 Apr 2012 12:55:06 -0700] ERROR: Running exception handlers
[Fri, 27 Apr 2012 12:55:06 -0700] ERROR: Exception handlers complete
[Fri, 27 Apr 2012 12:55:06 -0700] FATAL: Stacktrace dumped to /tmp/vagrant-chef-1/chef-stacktrace.out
[Fri, 27 Apr 2012 12:55:06 -0700] FATAL: Chef::Exceptions::ShellCommandFailed: execute[install system-wide RVM] (rvm::system_install line 69) had an error: Expected process to exit 0, but it exited with 1
---- Begin output of             bash -c "bash               <( curl -Ls https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer )"
 ----
STDOUT: Downloading RVM from wayneeseguin branch master

Installing RVM to /usr/local/rvm/

...
...
...
...

# vagrant,
#
#   Thank you for using RVM!
#   I sincerely hope that RVM helps to make your life easier and more enjoyable!!!
#
# ~Wayne
STDERR: % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  994k  100  994k    0     0   326k      0  0:00:03  0:00:03 --:--:--  609k
---- End output of             bash -c "bash               <( curl -Ls https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer )"
 ----
Ran             bash -c "bash               <( curl -Ls https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer )"
 returned 1
Chef never successfully completed! Any errors should be visible in the
output above. Please fix your recipes so that they properly complete.

Closing due to inactivity, please reopen if this is still an issue


Remove Application-Insights 2.21

Closes https://github.com/dotnet/source-build/issues/4248
Now that the application-insights patch in Arcade has been removed, we can remove application-insights 2.21 from SBE.

I question whether we should rename to a versionless pattern because it's just going to need to be versioned the next time we need to upgrade.

I'm impartial about this. On one hand, I could argue that we should version all the repos if possible. On the other hand, it is added work to rename the submodule each time we have to upgrade.

If we updated this line to use a version property, then arcade would float their AppInsights version and we wouldn't have this problem(needing to support multiple versions) with future upgrades (unless there is an breaking change).

I'm impartial about this. On one hand, I could argue that we should version all the repos if possible. On the other hand, it is added work to rename the submodule each time we have to upgrade.

I don't think it's necessary to version all the repos because most of them do not have scenarios where it's necessary to define multiple versions of the package. This one is special because of Arcade.


Change view, reduce line spacing, adjust font

hello is there a way to reduce the line spacing in the list and if necessary change the font and font color ?
thank you in advance for your feedback
Marc

Hi, the integration itself does not control any of the list styling. It just generates todo entities for Home Assistant to display.
You may be able to change the list styling using something like https://github.com/thomasloven/lovelace-card-mod.


Initial Config Manager Design and Implementation

The Config Manager is responsible for instantiating and managing the lifecycle of the various system components
in Envoy Gateway based on the Envoy Gateway Bootstrap spec

@arkodg I assigned this issue to you based on the 5/24/22 community meeting notes. Please unassign yourself if that's not the case.

Although the initial Config Manager will focus on k8s, it should be designed to support add'l config sources, xref: https://github.com/envoyproxy/gateway/issues/30

Fixed by https://github.com/envoyproxy/gateway/pull/146

Reopened by https://github.com/envoyproxy/gateway/pull/197

@arkodg can this issue be closed?

sure lets close, we seem to be doing fine w/o any sophisticated config manager atm, lets reopen if the need arises.


Performance issue "animating with MapViews"

The example with the animated callouts Using Mapview with animated API
is lagging extremely. We ran the example out of the box from the repo.
Are we missing something?

Same problem here

Exactly the same here. Tested on real Android & iOS devices (Huawei P8 Lite, iPhone 6). The performance of this demo is really poor - the animations are like 2-3 FPS or so. How did you manage to make that animated gif screen recording smooth enough?

One thing I noticed is that when I have debugger ON, the example runs pretty smoothly. When I have it OFF, it lags. Anybody else experiencing same thing?

I have the same problem NedYork

Please read the comments in this issue: https://github.com/react-community/react-native-maps/issues/1896
Closing.

@NedYork this is a known issue with the debugger. You should always test your app in production mode anyway :)


AD-165020: Retrieve HTML Content from STAX using GraphQL

HealthController forced to work - doesn't need unit test as it will work no matter what. Does not deploy otherwise.


Add accordion and fix minor issues

Add accordion
Fix fetch function to allow removing headers
Minor web-test UI tweaks
Add error catching for all web-test functions
fix novelupdates (a bit)
fix Syosetu (waiting for separate search and popularNovels filters)

Could you merge the current master to reduce the number of changes

Novel Updates doesnt work for me in web

Novel Updates doesnt work for me in web

I'll revert the changes to pre-accordion then.


definition of endpoints, protected by the auth-middlware does not work.

I tried manually adding 'security: BearerAuth', but it didn't work, although I tried different spellings...
middleware connection:

...
Route
.group(() => {
Route.delete('/delete/:id', 'ApartmentsController.delete')
Route.post('/create', 'ApartmentsController.create')
Route.post('/update', 'ApartmentsController.update')
})
.prefix('apartments')
})
.prefix('/api/v1').middleware('apiAuth')

adonis-autoswagger:

...
Route.get('/docs', async () => {
return AutoSwagger.ui('/swagger')
})
})
.prefix('/api/v1')
Route.get('/swagger', async () => {
return await AutoSwagger.docs(Route.toJSON(), {
path: __dirname,
title: 'Rento',
version: '1.0.0',
tagIndex: 3,
ignore: ['/swagger', '/docs', '/', '/health', '/uploads/*'],
common: {
parameters: {},
headers: {},
},
snakeCase: false
})
})

What exactly do you mean by "it didn't work". Does it throw errors, or does it just not recognize it as an auth-protected endpoint?

I tried to slip something like 'BearerAuth' or 'bearer' using the example of the settings of the original swagger. What I think was pointless))
it does not recognize it as an authorization-protected endpoint. Renders it correctly, but does not add a security property to every operation in the Swagger document, which is displayed in the UI as a padlock next to the operation.

Do you have a middleware called auth or auth:api applied to your routes?, this is where autoswagger automatically detects it. Custom middleware-names for auth are not supported yet.

Thanks a lot! Works! :relaxed:


Beacon geofence

Show a notification when nearby the beacon using a geofence. The user can enable / disable geofencing on any beacon.
The original suggestion was around georeferenced notes, though I think this is better suited for beacons + beacon comments. I should also look into adding geofencing to notes as well though, maybe pulled into another issue (with reminders?)
Things to research:

[ ] Would it make more sense to have the beacon show a notification when close? Beacons can have comments on them, which would make the notes redundant
[ ] How much battery does geofencing use?
[ ] How reliable is geofencing?

Just cause I sumbled over it, here is a link to a research paper from IEEE about an efficient geofencing algorithm.
Low computation in-device geofencing algorithm using hierarchy-based searching for offline usage
Can probably contact the author via research gate to check if he would provide the paper for free for the project, cause it fits kinda well into the problem.

@Portagoras thank you, that would be great!

The author was so nice to make their paper publicly available:
https://www.researchgate.net/publication/339904498_Low_computation_in-device_geofencing_algorithm_using_hierarchy-based_searching_for_offline_usage

@Portagoras thank you for reaching out to the author! That is great news, I will give it a read.

I read through the paper and it is a very interesting topic. The method described seemed to be focused around computational efficiency (time complexity and frequency of recalculation), but it didn't seem to talk about frequency of the trigger (ex. how frequent to wake up and poll the GPS). This approach may be useful to implement if there are a lot of geofences set up, though I'm not sure I'm too concerned about there being a lot yet in Trail Sense. But I am interested in seeing if this will benefit the nearby beacons filtering - currently I'm retrieving all beacons and filtering to those that are nearby, which is pretty inefficient. I could use a tree structure, like this paper describes, to more efficiently filter the beacons.
My main concern is how often the geofencing check will be triggered in the background.
My potential solution to this is that the delay becomes longer the further away from the geofences you are, with a min/max restriction on the frequency. For example, if I won't be able to travel to the nearest geofence within an hour, I shouldn't run the geofence algorithm again for another hour.
When the process is triggered, I could use a version of the algorithm described by the paper to check the geofences without needing to recalculate all distances, but I will need to do some performance tests with the naïve approach before implementing it.
If the paper did talk about this, but I missed it, please let me know.

I actually thought about the same issue and also think I found a pretty good solution(s).
1. Optimization
When the geofencing first triggeres, it checks in what part of the tree you are. For now lets focus on the root, so you are in no geofence.
The first time it triggeres, it finds the closest first level region and retrieves the distance. Then we create a virtual geofence with a radius to the closest geofence. Now whenever it triggers we only need to check if we left that zone, or if the tree changed. So we just eliminated all first level computations. This oshould also work on any other level of the tree.
2. Optimization
Estimating speed is essential for this. We can use anything from accelerometers to short gps usage.
When we know the size of our virtual fence, how far away we are from the center of it, and therefore how far away we are from the perimiter and we know our speed, we can find intervals when we need to check the gps again.
Example. Our virtual geofence free zone is 10km and we are currently 2 km from the center, then the distance to the perimiter is 8km. When we are on foot we travel somethign like 5km/h so we can easily wait over an hour for the next gps check.
This could also be an energy saving related setting.

I hid my own comment, cause it was suggesting the same feature you suggested :) I basically thought of the same thing when In read it. Might be a nice followup paper actually :)

Just a simple first idea about the trigger frequency: Wouldn't it be possible to just use an active backtrack as foundation for this problem? This way the user could decide for itself on which timescale the geofence will be reached and how precise the notification time has to be.

You may want to have a larger backtrack interval than that you need for detecting your geofence entering.
What happens if your location cannot be detected at the time a backtrack record fires?

@Z3NOX that could be possible, and maybe a good initial implementation. My only concern is that they serve two different purposes. The geofence would be for navigation and reminders, while backtrack's main purpose it for retracing your steps. I think the two should operate independently, so that you don't need to record a path if you only want to be notified about the proximity to a beacon.


Ability to prevent new windows from stealing focus?

Read the full docs, and searched through issues. apologies if this was already discussed somewhere
I'm developing a desktop app with Rust. The watcher automatically re-compiles and re-runs the app on every file save. This also triggers the app's GUI window to re-open. I need it to do so, but the fact that it steals focus away from my text editor is extremely annoying
the only workaround I found so far is nofocus, but that then prevents me from focusing the window afterwards to fill out forms

You can use window to rule open it on workspace with silent option.
windowrule = workspace 1 silent, ^(window)$

@naps62 Have you tried using focuscurrentorlast in your window rule? That should at least immediately change focus back to your editor.

#!/usr/bin/env bash

editor_address=$(hyprctl activewindow -j | jaq -r .address) # or jq

socat -u UNIX-CONNECT:/tmp/hypr/"$HYPRLAND_INSTANCE_SIGNATURE"/.socket2.sock - | \
while read -r line; do
    if [[ ${line:0:10} == openwindow ]]; then
        window=${line:27}
        # class=${window%,*}
        # title=${window#*,}
        if [[ $window == "<poping_window_class>,<popping_window_title" ]]; then
            # or use class/title separately
            hyprctl dispatch focuswindow address:"$editor_address"
        fi
    fi
done

I'm having this problem too now. Any time Viber gives a notification, the notification grabs focus. This is beyond enfuriating when somebody keeps sending me a stream of messages while I'm trying to write something elsewhere.
The only config solution that seems to work is nofocus, but then I can't click the notification, which I want to be able to do.
I think it would be valuable to have a nofocus-like option that only prevents the initial focus, but still allows focusing the window later.

notifications should not open windows anyways, they should use the system notification bus

done in dbb6d9d17421618901d3e7d985af1aee4414e537

@vaxerski I agree, it's damn annoying that applications keep rolling their own, but they do. This is also true for Steam.

at least steam sets the atoms correctly so that they're not focused


Add an ingame option for toasties, judgements

When selecting these there should be a static preview like how there is for noteskins. Toasties can be discovered by looking for images, and then looking for audio files with the same base name.

duplicate #413


Your library works well with ESP32 S3

Hi,
Thanks for your works. And I have got a ESP32 S3 these days. With your library, ESP32 S3 works well.
I have tried "descdump", it works well:
8ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x1 (POWERON),boot:0x9 (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd0108,len:0x43c
load:0x403b6000,len:0xbd0
load:0x403ba000,len:0x29c8
entry 0x403b61d8
[   114][I][usbhhelp.hpp:77] usbh_setup(): [] usb_host_install: 0
[   114][I][usbhhelp.hpp:92] usbh_setup(): [] usb_host_client_register: 0
[   499][I][usbhhelp.hpp:40] _client_event_callback(): [] New device address: 1
[   499][I][usbhhelp.hpp:49] _client_event_callback(): [] speed: 1 dev_addr 1 vMaxPacketSize0 8 bConfigurationValue 1
[   505][I][show_desc.hpp:44] show_dev_desc(): [] bLength: 18
[   511][I][show_desc.hpp:45] show_dev_desc(): [] bDescriptorType(device): 1
[   517][I][show_desc.hpp:46] show_dev_desc(): [] bcdUSB: 0x200
[   523][I][show_desc.hpp:47] show_dev_desc(): [] bDeviceClass: 0x00
[   529][I][show_desc.hpp:48] show_dev_desc(): [] bDeviceSubClass: 0x00
[   535][I][show_desc.hpp:49] show_dev_desc(): [] bDeviceProtocol: 0x00
[   542][I][show_desc.hpp:50] show_dev_desc(): [] bMaxPacketSize0: 8
[   548][I][show_desc.hpp:51] show_dev_desc(): [] idVendor: 0x46d
[   554][I][show_desc.hpp:52] show_dev_desc(): [] idProduct: 0xc52f
[   560][I][show_desc.hpp:53] show_dev_desc(): [] bcdDevice: 0x3000
[   566][I][show_desc.hpp:54] show_dev_desc(): [] iManufacturer: 1
[   571][I][show_desc.hpp:55] show_dev_desc(): [] iProduct: 2
[   577][I][show_desc.hpp:56] show_dev_desc(): [] iSerialNumber: 0
[   583][I][show_desc.hpp:57] show_dev_desc(): [] bNumConfigurations: 1
[   589][I][show_desc.hpp:64] show_config_desc(): [] bLength: 9
[   595][I][show_desc.hpp:65] show_config_desc(): [] bDescriptorType(config): 2
[   602][I][show_desc.hpp:66] show_config_desc(): [] wTotalLength: 59
[   608][I][show_desc.hpp:67] show_config_desc(): [] bNumInterfaces: 2
[   614][I][show_desc.hpp:68] show_config_desc(): [] bConfigurationValue: 1
[   621][I][show_desc.hpp:69] show_config_desc(): [] iConfiguration: 4
[   627][I][show_desc.hpp:74] show_config_desc(): [] bmAttributes(, Remote Wakeup): 0xa0
[   635][I][show_desc.hpp:75] show_config_desc(): [] bMaxPower: 49 = 98 mA
[   642][I][show_desc.hpp:82] show_interface_desc(): [] bLength: 9
[   648][I][show_desc.hpp:83] show_interface_desc(): [] bDescriptorType (interface): 4
[   655][I][show_desc.hpp:84] show_interface_desc(): [] bInterfaceNumber: 0
[   662][I][show_desc.hpp:85] show_interface_desc(): [] bAlternateSetting: 0
[   669][I][show_desc.hpp:86] show_interface_desc(): [] bNumEndpoints: 1
[   675][I][show_desc.hpp:87] show_interface_desc(): [] bInterfaceClass: 0x03
[   682][I][show_desc.hpp:88] show_interface_desc(): [] bInterfaceSubClass: 0x01
[   689][I][show_desc.hpp:89] show_interface_desc(): [] bInterfaceProtocol: 0x02
[   696][I][show_desc.hpp:90] show_interface_desc(): [] iInterface: 0
[   702][I][show_desc.hpp:115] show_hid_desc(): [] bLength: 9
[   708][I][show_desc.hpp:116] show_hid_desc(): [] bDescriptorType (HID): 33
[   715][I][show_desc.hpp:117] show_hid_desc(): [] bcdHID: 0x0111
[   720][I][show_desc.hpp:118] show_hid_desc(): [] bCountryCode: 0
[   726][I][show_desc.hpp:119] show_hid_desc(): [] bNumDescriptor: 1
[   732][I][show_desc.hpp:120] show_hid_desc(): [] bDescriptorType: 34
[   739][I][show_desc.hpp:121] show_hid_desc(): [] wDescriptorLength: 67
[   745][I][show_desc.hpp:100] show_endpoint_desc(): [] bLength: 7
[   751][I][show_desc.hpp:101] show_endpoint_desc(): [] bDescriptorType (endpoint): 5
[   758][I][show_desc.hpp:104] show_endpoint_desc(): [] bEndpointAddress(In): 0x81
[   766][I][show_desc.hpp:107] show_endpoint_desc(): [] bmAttributes(Interrupt): 0x03
[   773][I][show_desc.hpp:108] show_endpoint_desc(): [] wMaxPacketSize: 8
[   780][I][show_desc.hpp:109] show_endpoint_desc(): [] bInterval: 2
[   786][I][show_desc.hpp:82] show_interface_desc(): [] bLength: 9
[   792][I][show_desc.hpp:83] show_interface_desc(): [] bDescriptorType (interface): 4
[   799][I][show_desc.hpp:84] show_interface_desc(): [] bInterfaceNumber: 1
[   806][I][show_desc.hpp:85] show_interface_desc(): [] bAlternateSetting: 0
[   813][I][show_desc.hpp:86] show_interface_desc(): [] bNumEndpoints: 1
[   819][I][show_desc.hpp:87] show_interface_desc(): [] bInterfaceClass: 0x03
[   826][I][show_desc.hpp:88] show_interface_desc(): [] bInterfaceSubClass: 0x00
[   833][I][show_desc.hpp:89] show_interface_desc(): [] bInterfaceProtocol: 0x00
[   840][I][show_desc.hpp:90] show_interface_desc(): [] iInterface: 0
[   847][I][show_desc.hpp:115] show_hid_desc(): [] bLength: 9
[   852][I][show_desc.hpp:116] show_hid_desc(): [] bDescriptorType (HID): 33
[   859][I][show_desc.hpp:117] show_hid_desc(): [] bcdHID: 0x0111
[   865][I][show_desc.hpp:118] show_hid_desc(): [] bCountryCode: 0
[   870][I][show_desc.hpp:119] show_hid_desc(): [] bNumDescriptor: 1
[   877][I][show_desc.hpp:120] show_hid_desc(): [] bDescriptorType: 34
[   883][I][show_desc.hpp:121] show_hid_desc(): [] wDescriptorLength: 79
[   889][I][show_desc.hpp:100] show_endpoint_desc(): [] bLength: 7
[   895][I][show_desc.hpp:101] show_endpoint_desc(): [] bDescriptorType (endpoint): 5
[   903][I][show_desc.hpp:104] show_endpoint_desc(): [] bEndpointAddress(In): 0x82
[   910][I][show_desc.hpp:107] show_endpoint_desc(): [] bmAttributes(Interrupt): 0x03
[   918][I][show_desc.hpp:108] show_endpoint_desc(): [] wMaxPacketSize: 20
[   924][I][show_desc.hpp:109] show_endpoint_desc(): [] bInterval: 2
And I also tried usbhhidboot with my USB keyboard:
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x1 (POWERON),boot:0x8 (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd0108,len:0x43c
load:0x403b6000,len:0xbd0
load:0x403ba000,len:0x29c8
entry 0x403b61d8
[   114][I][usbhhelp.hpp:77] usbh_setup(): [] usb_host_install: 0
[   115][I][usbhhelp.hpp:92] usbh_setup(): [] usb_host_client_register: 0
[   499][I][usbhhelp.hpp:40] _client_event_callback(): [] New device address: 1
[   500][I][usbhhelp.hpp:49] _client_event_callback(): [] speed: 1 dev_addr 1 vMaxPacketSize0 8 bConfigurationValue 1
[   506][I][show_desc.hpp:44] show_dev_desc(): [] bLength: 18
[   511][I][show_desc.hpp:45] show_dev_desc(): [] bDescriptorType(device): 1
[   518][I][show_desc.hpp:46] show_dev_desc(): [] bcdUSB: 0x110
[   523][I][show_desc.hpp:47] show_dev_desc(): [] bDeviceClass: 0x00
[   530][I][show_desc.hpp:48] show_dev_desc(): [] bDeviceSubClass: 0x00
[   536][I][show_desc.hpp:49] show_dev_desc(): [] bDeviceProtocol: 0x00
[   542][I][show_desc.hpp:50] show_dev_desc(): [] bMaxPacketSize0: 8
[   548][I][show_desc.hpp:51] show_dev_desc(): [] idVendor: 0x258a
[   554][I][show_desc.hpp:52] show_dev_desc(): [] idProduct: 0x2a
[   560][I][show_desc.hpp:53] show_dev_desc(): [] bcdDevice: 0x1201
[   566][I][show_desc.hpp:54] show_dev_desc(): [] iManufacturer: 1
[   572][I][show_desc.hpp:55] show_dev_desc(): [] iProduct: 2
[   577][I][show_desc.hpp:56] show_dev_desc(): [] iSerialNumber: 0
[   583][I][show_desc.hpp:57] show_dev_desc(): [] bNumConfigurations: 1
[   590][I][show_desc.hpp:64] show_config_desc(): [] bLength: 9
[   595][I][show_desc.hpp:65] show_config_desc(): [] bDescriptorType(config): 2
[   602][I][show_desc.hpp:66] show_config_desc(): [] wTotalLength: 59
[   608][I][show_desc.hpp:67] show_config_desc(): [] bNumInterfaces: 2
[   615][I][show_desc.hpp:68] show_config_desc(): [] bConfigurationValue: 1
[   621][I][show_desc.hpp:69] show_config_desc(): [] iConfiguration: 0
[   628][I][show_desc.hpp:74] show_config_desc(): [] bmAttributes(, Remote Wakeup): 0xa0
[   635][I][show_desc.hpp:75] show_config_desc(): [] bMaxPower: 250 = 500 mA
[   642][I][show_desc.hpp:82] show_interface_desc(): [] bLength: 9
[   648][I][show_desc.hpp:83] show_interface_desc(): [] bDescriptorType (interface): 4
[   656][I][show_desc.hpp:84] show_interface_desc(): [] bInterfaceNumber: 0
[   662][I][show_desc.hpp:85] show_interface_desc(): [] bAlternateSetting: 0
[   669][I][show_desc.hpp:86] show_interface_desc(): [] bNumEndpoints: 1
[   676][I][show_desc.hpp:87] show_interface_desc(): [] bInterfaceClass: 0x03
[   682][I][show_desc.hpp:88] show_interface_desc(): [] bInterfaceSubClass: 0x01
[   690][I][show_desc.hpp:89] show_interface_desc(): [] bInterfaceProtocol: 0x01
[   697][I][show_desc.hpp:90] show_interface_desc(): [] iInterface: 0
[   703][I][usbhhidboot.ino:66] check_interface_desc_boot_keyboard(): [] Claiming a boot keyboard!
[   712][I][show_desc.hpp:115] show_hid_desc(): [] bLength: 9
[   717][I][show_desc.hpp:116] show_hid_desc(): [] bDescriptorType (HID): 33
[   724][I][show_desc.hpp:117] show_hid_desc(): [] bcdHID: 0x0111
[   730][I][show_desc.hpp:118] show_hid_desc(): [] bCountryCode: 0
[   735][I][show_desc.hpp:119] show_hid_desc(): [] bNumDescriptor: 1
[   742][I][show_desc.hpp:120] show_hid_desc(): [] bDescriptorType: 34
[   748][I][show_desc.hpp:121] show_hid_desc(): [] wDescriptorLength: 67
[   754][I][show_desc.hpp:100] show_endpoint_desc(): [] bLength: 7
[   760][I][show_desc.hpp:101] show_endpoint_desc(): [] bDescriptorType (endpoint): 5
[   768][I][show_desc.hpp:104] show_endpoint_desc(): [] bEndpointAddress(In): 0x81
[   775][I][show_desc.hpp:107] show_endpoint_desc(): [] bmAttributes(Interrupt): 0x03
[   783][I][show_desc.hpp:108] show_endpoint_desc(): [] wMaxPacketSize: 8
[   789][I][show_desc.hpp:109] show_endpoint_desc(): [] bInterval: 1
[   795][I][usbhhidboot.ino:96] prepare_endpoint(): [] USB boot keyboard ready
[   802][I][show_desc.hpp:82] show_interface_desc(): [] bLength: 9
[   808][I][show_desc.hpp:83] show_interface_desc(): [] bDescriptorType (interface): 4
[   816][I][show_desc.hpp:84] show_interface_desc(): [] bInterfaceNumber: 1
[   822][I][show_desc.hpp:85] show_interface_desc(): [] bAlternateSetting: 0
[   829][I][show_desc.hpp:86] show_interface_desc(): [] bNumEndpoints: 1
[   835][I][show_desc.hpp:87] show_interface_desc(): [] bInterfaceClass: 0x03
[   842][I][show_desc.hpp:88] show_interface_desc(): [] bInterfaceSubClass: 0x00
[   849][I][show_desc.hpp:89] show_interface_desc(): [] bInterfaceProtocol: 0x00
[   857][I][show_desc.hpp:90] show_interface_desc(): [] iInterface: 0
[   863][I][show_desc.hpp:115] show_hid_desc(): [] bLength: 9
[   868][I][show_desc.hpp:116] show_hid_desc(): [] bDescriptorType (HID): 33
[   875][I][show_desc.hpp:117] show_hid_desc(): [] bcdHID: 0x0111
[   881][I][show_desc.hpp:118] show_hid_desc(): [] bCountryCode: 0
[   887][I][show_desc.hpp:119] show_hid_desc(): [] bNumDescriptor: 1
[   893][I][show_desc.hpp:120] show_hid_desc(): [] bDescriptorType: 34
[   899][I][show_desc.hpp:121] show_hid_desc(): [] wDescriptorLength: 204
[   906][I][show_desc.hpp:100] show_endpoint_desc(): [] bLength: 7
[   911][I][show_desc.hpp:101] show_endpoint_desc(): [] bDescriptorType (endpoint): 5
[   919][I][show_desc.hpp:104] show_endpoint_desc(): [] bEndpointAddress(In): 0x82
[   926][I][show_desc.hpp:107] show_endpoint_desc(): [] bmAttributes(Interrupt): 0x03
[   934][I][show_desc.hpp:108] show_endpoint_desc(): [] wMaxPacketSize: 16
[   940][I][show_desc.hpp:109] show_endpoint_desc(): [] bInterval: 1
[   947][I][usbhhidboot.ino:46] keyboard_transfer_cb(): [] HID report: 00 00 1c 15 22 00 00 00
[  1038][I][usbhhidboot.ino:46] keyboard_transfer_cb(): [] HID report: 00 00 00 15 22 00 00 00
[  1068][I][usbhhidboot.ino:46] keyboard_transfer_cb(): [] HID report: 00 00 00 15 00 00 00 00
[  1078][I][usbhhidboot.ino:46] keyboard_transfer_cb(): [] HID report: 00 00 00 00 00 00 00 00
[  1647][I][usbhhidboot.ino:46] keyboard_transfer_cb(): [] HID report: 00 00 15 17 1c 00 00 00
[  1768][I][usbhhidboot.ino:46] keyboard_transfer_cb(): [] HID report: 00 00 00 00 1c 00 00 00
[  1817][I][usbhhidboot.ino:46] keyboard_transfer_cb(): [] HID report: 00 00 00 00 00 00 00 00

I am glad to hear it is working. I want to remind everyone this code was to help me understand USB and the ESP32 USB host
library https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/api-reference/peripherals/usb_host.html. This code does not follow all the ESP32 USB host library recommendations so be cautious. I do not have time to develop this further.

I have used your library to build a USB Keyboard to BLE Keyboard converter. The code is as below. And I'm make a video to show how it works these days.
`#include <elapsedMillis.h>
#include <BleKeyboard.h>
#include <usb/usb_host.h>
#include "show_desc.hpp"
#include "usbhhelp.hpp"
BleKeyboard bleKeyboard;
bool isKeyboard = false;
bool isKeyboardReady = false;
uint8_t KeyboardInterval;
bool isKeyboardPolling = false;
elapsedMillis KeyboardTimer;
const size_t KEYBOARD_IN_BUFFER_SIZE = 8;
usb_transfer_t *KeyboardIn = NULL;
void keyboard_transfer_cb(usb_transfer_t *transfer)
{
if (Device_Handle == transfer->device_handle) {
isKeyboardPolling = false;
if (transfer->status == 0) {
if (transfer->actual_num_bytes == 8) {
uint8_t const p = transfer->data_buffer;
ESP_LOGI("", "HID report: %02x %02x %02x %02x %02x %02x %02x %02x",
p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7]);
if(bleKeyboard.isConnected()) {
bleKeyboard.sendReport((KeyReport) p);
}
}
else {
ESP_LOGI("", "Keyboard boot hid transfer too short or long");
}
}
else {
ESP_LOGI("", "transfer->status %d", transfer->status);
}
}
}
void check_interface_desc_boot_keyboard(const void *p)
{
const usb_intf_desc_t *intf = (const usb_intf_desc_t *)p;
if ((intf->bInterfaceClass == USB_CLASS_HID) &&
(intf->bInterfaceSubClass == 1) &&
(intf->bInterfaceProtocol == 1)) {
isKeyboard = true;
ESP_LOGI("", "Claiming a boot keyboard!");
esp_err_t err = usb_host_interface_claim(Client_Handle, Device_Handle,
intf->bInterfaceNumber, intf->bAlternateSetting);
if (err != ESP_OK) ESP_LOGI("", "usb_host_interface_claim failed: %x", err);
}
}
void prepare_endpoint(const void *p)
{
const usb_ep_desc_t *endpoint = (const usb_ep_desc_t *)p;
esp_err_t err;
// must be interrupt for HID
if ((endpoint->bmAttributes & USB_BM_ATTRIBUTES_XFERTYPE_MASK) != USB_BM_ATTRIBUTES_XFER_INT) {
ESP_LOGI("", "Not interrupt endpoint: 0x%02x", endpoint->bmAttributes);
return;
}
if (endpoint->bEndpointAddress & USB_B_ENDPOINT_ADDRESS_EP_DIR_MASK) {
err = usb_host_transfer_alloc(KEYBOARD_IN_BUFFER_SIZE, 0, &KeyboardIn);
if (err != ESP_OK) {
KeyboardIn = NULL;
ESP_LOGI("", "usb_host_transfer_alloc In fail: %x", err);
return;
}
KeyboardIn->device_handle = Device_Handle;
KeyboardIn->bEndpointAddress = endpoint->bEndpointAddress;
KeyboardIn->callback = keyboard_transfer_cb;
KeyboardIn->context = NULL;
isKeyboardReady = true;
KeyboardInterval = endpoint->bInterval;
ESP_LOGI("", "USB boot keyboard ready");
}
else {
ESP_LOGI("", "Ignoring interrupt Out endpoint");
}
}
void show_config_desc_full(const usb_config_desc_t *config_desc)
{
// Full decode of config desc.
const uint8_t *p = &config_desc->val[0];
static uint8_t USB_Class = 0;
uint8_t bLength;
for (int i = 0; i < config_desc->wTotalLength; i+=bLength, p+=bLength) {
bLength = *p;
if ((i + bLength) <= config_desc->wTotalLength) {
const uint8_t bDescriptorType = *(p + 1);
switch (bDescriptorType) {
case USB_B_DESCRIPTOR_TYPE_DEVICE:
ESP_LOGI("", "USB Device Descriptor should not appear in config");
break;
case USB_B_DESCRIPTOR_TYPE_CONFIGURATION:
show_config_desc(p);
break;
case USB_B_DESCRIPTOR_TYPE_STRING:
ESP_LOGI("", "USB string desc TBD");
break;
case USB_B_DESCRIPTOR_TYPE_INTERFACE:
USB_Class = show_interface_desc(p);
check_interface_desc_boot_keyboard(p);
break;
case USB_B_DESCRIPTOR_TYPE_ENDPOINT:
show_endpoint_desc(p);
if (isKeyboard && KeyboardIn == NULL) prepare_endpoint(p);
break;
case USB_B_DESCRIPTOR_TYPE_DEVICE_QUALIFIER:
// Should not be config config?
ESP_LOGI("", "USB device qual desc TBD");
break;
case USB_B_DESCRIPTOR_TYPE_OTHER_SPEED_CONFIGURATION:
// Should not be config config?
ESP_LOGI("", "USB Other Speed TBD");
break;
case USB_B_DESCRIPTOR_TYPE_INTERFACE_POWER:
// Should not be config config?
ESP_LOGI("", "USB Interface Power TBD");
break;
case 0x21:
if (USB_Class == USB_CLASS_HID) {
show_hid_desc(p);
}
break;
default:
ESP_LOGI("", "Unknown USB Descriptor Type: 0x%x", bDescriptorType);
break;
}
}
else {
ESP_LOGI("", "USB Descriptor invalid");
return;
}
}
}
void setup()
{
ESP_LOGI("","Starting BLE work!");
bleKeyboard.begin();
usbh_setup(show_config_desc_full);
}
void loop()
{
usbh_task();
if (isKeyboardReady && !isKeyboardPolling && (KeyboardTimer > KeyboardInterval)) {
KeyboardIn->num_bytes = 8;
esp_err_t err = usb_host_transfer_submit(KeyboardIn);
if (err != ESP_OK) {
ESP_LOGI("", "usb_host_transfer_submit In fail: %x", err);
}
isKeyboardPolling = true;
KeyboardTimer = 0;
}
}
`

Esp32 S3 connected to USB keyboard fail

Could you try another Keyboard and mouse? Don't use the Keyboard which behind the USB HUB.


Blog

I've updated Ira's code to match that for the blog. Integrated it with existing tutorials to have a linear progression through the topics (as before).

Coverage remained the same at 9.62% when pulling a70b5eb73f8fd6f6afaa2f26f42a1f3c614a8e07 on blog into 798b93a331e82484fe44a53ab5838782c5e29c8c on master.


proposal: text/template: safe navigation with ?.

It would be beautiful if the package text/template (used by e.g. Helm) could support optional chaining. Similar to JavaScript in latest standard ECMAScript 2020. See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining
It would basically look like this:
spec:
  type: {{ .Values.service?.type | default "ClusterIP" }}

If service is not defined, it would short-circuit to undefined/false and thus default to "ClusterIP".
This could be used in other cases, such as:
spec:
  {{- if .Values.global?.internalIPFamily }}
  ipFamily: {{ .Values.global.internalIPFamily }}
  {{- end }}

It solves a few things in e.g. Helm that uses text/template for templating:

default not working when parent values does not exist in a chain, giving errors, see https://github.com/helm/helm/issues/8026.
It would be able to get rid of the, in my opinion, not great best practice for nested or flat values for e.g. Helm (which I assume is applicable to other text/template usages as well), see https://helm.sh/docs/chart_best_practices/values/#flat-or-nested-values. Optional chaining would instead still make the code more readable (one-liner) not caring about value depth. It would also in my opinion make it easier to read YAML files with the nested structure, clearly separating levels, than to use camelCase.

As I know very little about Go and the packge text/template, feel free to add more precise info on how this translates to what needs to be done in text/template.

This seems more like a proposal. I'm adding the text/template owners in order to begin the discussion.
/cc @robpike @mvdan

This seems more like a proposal. I'm adding the text/template owners in order to begin the discussion.
/cc @robpike @mvdan

@cagedmantis @robphoenix @mvdan please any update on this task? It would be super helpful if we can use this style of property resolver.

@bilak @cagedmantis @robphoenix @mvdan do you have some opinions on this?

There are dozens of open text/template issues. Please don't ping proposals every few weeks; we have limited time.
Personally, I think we should implement the already-accepted proposals (https://github.com/golang/go/issues/20531 and https://github.com/golang/go/issues/31103) before we consider new ones. Any help with those is welcome.

It was 5 months ago this was written, and I find it common courtesy to give a short comment that it has been seen. But each repo to his own.

The way to make progress on this is to turn it into a proposal with a precise definition of the suggested change and the new semantics.
For example, if I pass
var s struct {
    p *struct {
        f int
    }
}

to a template and write s.p.f then assuming that s.p is not nil I will get an integer.  What should happen for s.p.?f if p is nil?  Should I get 0?  If I get nil that may cause a different error.
The initial comment on the issue says "feel free to add more precise info on how this translates to what needs to be done in text/template" but that is hard for us to do.  There are many many many more people suggesting changes than there are people implementing those changes.  This can only scale if the people interested in the change can describe exactly what how it should work.
Thanks.

@ianlancetaylor I do not have the knowledge in Go to give specifics, but regarding semantics one can look at https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining which can serve as the spec for how it should work.
But regarding s.p?.f it should return nil (since undefined does not exist in Go?).
Anyone more comfortable in Go; feel free to write up a proper proposal. I can link it in the original issue.

There is no value in nil pointer panics and maybe not much code that depends on it to work properly. Because it just breaks things and doesn't fix anything, the nicest solution would be to make the optional chaining the default.
Now I know we can't have nice things because of the remote chance that some code depends on the panics, backward compatibility and all, so the next best thing would be to make it a configuration option for templates.

It seems like this proposal has got a little stuck because those who are proposing it don't have enough familiarity with the template language implementation to state concretely what they would like it to do, but those who do have that knowledge are busy with other things and so unable to try to "meet the proposers in the middle" with some context to work on.
I'm admittedly not incredibly invested in this proposal since I don't really use Go's template language in any software I work on, but I do know a little about how it works and so I'm sharing the following in the hope that it gives others some hooks to pull on to make this proposal more concrete.

An important starting piece of context for the template language is that all values that the template interacts with are represented as reflect.Value, which is more or less the reflection system's equivalent of any[^1].
This proposal seems to be focused on the specific detail of what the template language documentation refers to as a "field invocation":

The name of a field of the data, which must be a struct, preceded by a period, such as .Field The result is the value of the field. Field invocations may be chained: .Field1.Field2 Fields can also be evaluated on variables, including chaining: $x.Field1.Field2

I would recommend that those iterating on this proposal also consider how the new proposed behavior might change or take inspiration from the similar syntax for accessing "a key of the data" (from a map), since that also uses the . syntax but with a slightly different meaning:

The name of a key of the data, which must be a map, preceded by a period, such as .Key The result is the map element value indexed by the key. Key invocations may be chained and combined with fields to any depth: .Field1.Key1.Field2.Key2 Although the key must be an alphanumeric identifier, unlike with field names they do not need to start with an upper case letter. Keys can also be evaluated on variables, including chaining: $x.key1.key2

The code that handles this kind of traversal today -- including the rule of returning an error if you try to traverse through a nil pointer -- is here:
https://github.com/golang/go/blob/f4e3ec3dbe3b8e04a058d266adf8e048bab563f2/src/text/template/exec.go#L679-L761
In particular I think y'all are interested in this particular case:
https://github.com/golang/go/blob/f4e3ec3dbe3b8e04a058d266adf8e048bab563f2/src/text/template/exec.go#L746-L758
The key question that this proposal needs to answer, I think, is what replaces the s.errorf call in that if isNil { ... } branch. s.errorf causes a panic, meaning that currently that function doesn't return in the regular way at all when that situation occurs. This proposal suggests that it should instead return normally, and so the important question is exactly which reflect.Value it ought to return.
When considering the answer to that, it's important to recognize that the identifier nil in the main Go language does not actually represent a single value of a particular type. Instead, it's a special typeless thing that can convert into a value of a subset of Go's types, and can be compared to a subset of Go's types. So there is no single reflect.Value that represents what nil would represent in a Go program.
What we do have is the concept of the "zero value" of each type. For a number of different types, including pointers, the zero value is considered to be equal to nil, and so one possible answer is to say that the return value would be the zero value of whatever type the named field was declared with, assuming that there is a field with that name. This would be similar to the treatment of accessing a non-existent key in a map when the missingkey=zero option is set, although it would presumably still need to fail if the given field name doesn't exist in the struct type at all, or if the pointer is not of a struct type, because then there would be no field to use to decide the result type.
However, the motivation for this issue linked to a downstream Helm issue involving its default function. As far as I can tell, that default function is actually from github.com/Masterminds/sprig, and has its own special idea of "empty" which (despite what the documentation says) doesn't seem to exactly match "the zero value of the value's type". However, the only difference that stuck out to me is that it never considers a struct-typed value to be empty, regardless of its value, and so it seems like it would work fine for a primitive-typed field like the .Values.service?.type in the first motivating example.
That's all the digging and writing I have time for right now. I hope the above is a useful starting point for someone who wants to develop this from a feature request into a proposal.
[^1]: Things are a little more subtle than that since the reflection system can represent some details that any cannot, but I think this statement is true enough for the sake of the rest of this comment.

Thank you apparentlymart. That is a great summary. You do tell:

the identifier nil in the main Go language does not actually represent a single value of a particular type

Do understand that from my perspective (which hopefully overlaps with the other ones here) is that it's never a problem to have a nil coming out of a ?. sequence. However, if a nil ends up being the result of a {{...}}, then it makes sense to fail.
Ideally, we then either end the sequence with a default value we want to use if none is set or we want it to fail if the value isn't set. That's how people are bringing up the default function from sprig (which is a HUGE misnomer, from 2nd hand experience)
As a side-thought: I read in this sequence of messages that maybe the behavior described of ?. when using . makes most sense to be the behavior implemented. However, to do that, you need to keep extra status or stack information, for logging purposes, which mapping returned nil. For me, that's would be a requirement.
I don't see the need to have a zero for this purpose. If the value doesn't exist, it doesn't exist, it's nil which is a thing in go language itself.
Examples of how the behavior is with this proposal:
Doing a ?. in go template providing a nil always returns nil and never fails. E.g.
nil?.abc <- is nil
nil?.abc?.def <- is nil
exists.notexist <- is nil (and had always been nil)
exists.notexist?.abc <- is nil
exists.notexist.abc <- fails because cannot . operate on nil
I hope I completed apparentlymart's comment with my own perspective.

Having ?. always produce nil is one way to go but it's not obviously correct.  See my comment https://github.com/golang/go/issues/43608#issuecomment-1154338818.  If the template is expecting an int and getting nil, then we have converted a nil-pointer crash into a type-mismatch crash.  Is that what people want?

You are making sense, I'm just saying that you are trading one kind of crash for a different kind of crash.  If the code is going to crash anyhow, what's the point of adding the ?. syntax?

I want to reinforce my point that nil is not actually a value in Go.
func main() {
	v := nil // ERROR: use of untyped nil in assignment
	fmt.Println("It's ", v)
}

The above fails because nil alone doesn't give enough information to decide what type v will have. Instead,
nil assigned to *Foo is a distinct value from nil assigned to *Bar, or nil assigned to []Foo, or nil assigned to map[string]Foo. There is also no value of type string, or any of the numeric primitive types, or of a struct type, that is equal to nil or assignable from nil.
Therefore it isn't really meaningful to say that the template expression result "is nil". The result must be defined as some specific reflect.Value, which means the result must have a specified type and must be a value of that type. Since there is no value of int that is equal to nil, using a nil-like value as the result would imply the result being of some type other than int.

I didn't mention in my first comment that the template system does also include the idea of "no value", which is what access to a non-existing map key returns by default. Internally within the template engine, that's represented as the zero value of reflect.Value, which represents the absence of a value rather than a value.
I see in the evalField function I shared earlier that accessing a field on "no value" returns another "no value":
https://github.com/golang/go/blob/f4e3ec3dbe3b8e04a058d266adf8e048bab563f2/src/text/template/exec.go#L683-L688
...and so I suppose another possible answer is to say that foo?.Bar returns "no value" (the zero value of reflect.Value) if foo is nil, and then any subsequent chained field accesses would presumably be handled by the branch I linked to above and would again return "no value".
Between the current behavior and the two possibilities I've discussed so far I've effectively covered all of the existing available options for how to handle accessing a map key that doesn't exist in the map:

missingkey=default/missingkey=invalid: returns "no value", like what I've just described above.
missingkey=zero: returns the zero value of the map's element type, similar to what I suggested in my original comment.
missingkey=error: fails with an error, matching the template engine's current treatment of field access through a nil pointer

If it's possible to do so, I expect that matching one of these already-available behaviors for accessing non-existent map keys as closely as possible is probably best so that the overall template language stays somewhat consistent.
(@ungerik also noted that there could be a new option for specifying how the template engine ought to treat field access through a nil pointer, similar to the existing option for missing map keys. That is true, but seems like it would be a materially different proposal since it would make this a global decision for the Go code that renders the template rather than a local decision made by the template author for just one field access.)

@ianlancetaylor
Because it becomes useful when you combine with other actions. For example:
E.g.1:
val: {{ a.b?.maybeexist | default 0 }}

E.g.2:
{{ if a.b?.maybeexist }}
set: accept
val: "yes"
{{- end -}}

Does this help?

@apparentlymart I was thinking about nil as (interface{})(nil) when no other can be reasonably deducted. AFAIK, a nil like that does exist and is assignable. However, if there's already that no value which is the zero of reflect.Value, then that works just as well for my use-cases. That can then be used to handle as not being set and replace with a default, make it error or even use in a conditional to execute a custom conditional process based on whether it actually exists or not.

Since I've only been working in theory so far, and that's dangerous 😀, I think probably a good next step would be to confirm whether this is viable by making a temporary edit to the function I've been linking to above so that it uses return zero instead of raising an error when the pointer is nil.
Although that behavior would not exactly match the proposal -- it would redefine the existing . operator rather than introducing a new ?. operator -- it would be enough to experiment with combining that behavior with other features of the language to make sure that it fits well with the existing features. In particular, it would be interesting to see how that downstream default function interacts with an expression that returns "no value".
If you want to experiment with it without temporarily modifying text/template then another option would be to try using an access to a non-existent map key in place of access through a nil pointer, since that would already return "no value" in the existing language. That could then let us see whether that approach is likely to be successful in actually meeting the use-cases that we've been discussing in this proposal.

Yes. Good idea. I don't have a setup on my system to build go but if no one steps forward, I can shift some things around to try finding the time to do that (hopefully, I won't forget about it drowned in my work).


GH-419: Follow-up fix to support unstable builders triggering

GH-434 attempted to support triggering unstable builder with comment-based triggering It had two flaws that are fixed in this follow-up PR:

Needed to unpack the event property
If we are left with no builders after filtering, need to avoid the super() call (otherwise we end up triggering ALL builders O_O)

Well, I trust you, let's see how it goes :-)


Update arrow version

@Swoorup looks like at least this has to be addressed first: apache/arrow-rs#5623

Thanks for pointing that out.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 93.11%. Comparing base (4ba848f) to head (aa7688f).
Report is 2 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main       #8      +/-   ##
==========================================
- Coverage   93.19%   93.11%   -0.09%
==========================================
  Files           9        9
  Lines        1764     1743      -21
==========================================
- Hits         1644     1623      -21
  Misses        120      120

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


python311Packages.ruff-lsp: 0.0.47 -> 0.0.48

Description of changes
Changelog: https://github.com/astral-sh/ruff-lsp/releases/tag/v0.0.48
cc @figsoda @kalekseev

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

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

2 packages built:

ruff-lsp
ruff-lsp.dist

Result of nixpkgs-review pr 274926 run on aarch64-linux 1

2 packages built:

ruff-lsp
ruff-lsp.dist


Cannot set null to DateTimeColumn

I am trying to update my object like this
widget.erpticket = widget.erpticket.copyWith(
close_date: null,
issettobeupdated: true,
);
But when I log
print(widget.erpticket.close_date);
The value is what I had set before
2020-09-01 12:55:39.424250
Yet close_date is nullable
DateTimeColumn get close_date => dateTime().nullable()();
What am I doing wrong? Is this a bug?

@simolus3 pleae advise

This is working as intended, but was a poor design choice I made...
The default value of the close_date parameter in copyWith is null. When receiving a null value, copyWith will assume that the parameter wasn't set and use the old value. You can probably get around this now by converting the erpticket to a companion, updating that, and then converting that back to a row (using mapFromCompanion):
final companion = widget.erpticket.toCompanion(true).copyWith(
  close_date: Value(null),
  issettobeupdated: Value(true),
);
widget.erpticket = database.erptickets.mapFromCompanion(companion);

I'll work on a build option to generate Value<...> parameters in copyWith when the underlying column is nullable. That should fix this problem.

@simolus3 thank you let me try this

@simolus3 I am getting an error
E/flutter ( 6497): [ERROR:flutter/lib/ui/ui_dart_state.cc(157)] Unhandled Exception: type 'DateTime' is not a subtype of type 'int' in type

Can you post the stack trace of that exception?

@simolus3  here

Thanks, I think I know where this is coming from now. This is probably because of https://github.com/simolus3/moor/issues/559, which should have been fixed in version 3.1.0. Can you try upgrading if you're using an older version? The latest moor version is 3.3.1.

Yes I was using version 2.3.1. This has worked. Thank you @simolus3 .Closing


⚠ Bofrost.at has degraded performance

In 81ee8bb, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 2611 ms

Resolved: Bofrost.at performance has improved in 62c5c2b after 6 minutes.


EKF: use int cast for XeY to avoid float casting of variables

The default type for XeY is float

@bkueng changed it to uint64_t

Looks good.
@bkueng How about we introduce a define for this generally in PX4? Something like #define US(a) (long int)(a * 1e6)
It works nice even with fractions of seconds: https://godbolt.org/g/z8F8Se


Compilation issues in version 11.2.0 and above

Basic info:

Node.js version: v8.4.0
jsdom version: 11.2.0 and above

Using JSDOM in my Jest/Enzyme testing suite for a React application via some inspiration from the good folks at Airbnb (http://airbnb.io/enzyme/docs/guides/jsdom.html).
Importing JSDOM versions higher than 11.1.0 (aka 11.2.0 and 11.3.0) causes a compilation issue due to a change to the constructor of XMLHttpRequest in /jsdom/lib/jsdom/living/xmlhttprequest.js at line 99. The breaking commit for me is is https://github.com/tmpvar/jsdom/commit/f6bc2ed38eba4c57af363a844cddf667988d5c01#diff-6e68b31feebe3dc2cbc829a50d51e120. In previous versions of xmlhttprequest.js, super() was called in the constructor of XMLHttpRequest. Without the super() call I get:
  ● Test suite failed to run

    /path/to/my/application/node_modules/jsdom/lib/jsdom/living/xmlhttprequest.js: missing super() call in constructor
         97 |
         98 |   class XMLHttpRequest extends XMLHttpRequestEventTarget.interface {
      >  99 |     constructor() { // eslint-disable-line constructor-super
            |     ^
        100 |       const theThis = Object.create(new.target.prototype);
        101 |       XMLHttpRequestEventTarget.setup(theThis);
        102 |       theThis.upload = XMLHttpRequestUpload.create();

I imagine this may be an issue with my usage rather than the library itself, as I assume you would have corrected this issue in two subsequent releases, but I'm curious as to what I may be doing wrong?
I've reverted back to 11.1.0, but can't stay up to date now.
Minimal reproduction case
//Literally just importing jsdom causes the error in my case.
const { JSDOM } = require("jsdom");

If I put that one line in a file, and run node file.js, no error occurs. This implies to me it's an issue with some other tooling you are using, not with jsdom, since jsdom works fine with Node.js.

From the error message, this seems to be a bug in Babel's class transformation plugin. Bug filed at https://github.com/babel/babel/issues/6370.
I am not sure how Babel interacts with Jest, but either way this is not a bug in jsdom.

thank you guys! patiently waiting on the babel issue to be closed


[WIP] Add a WorkflowDispatcher worker

Add a dedicated worker to run embedded workflows
Depends on:

[ ] https://github.com/ManageIQ/manageiq/pull/22656

Goal of this is to setup a worker with privileges (security context) to create pods.

I was hoping we could avoid creating a new worker, but perhaps it's inevitable.  Main reason is that we would need another kubernetes service account, and we always tried to avoid that leaving that to only the orchestrator and the operator.  Let's discuss before too much time gets put into this solution.  cc @bdunne
(FWIW, I eventually want the orchestrator to get rid of the service account too and we'd only have the operator, but that might be a pipe dream).

We decided to go a different direction with this and make this a more generic automate runner


Onboard roslyn-analyzers repo for area pod boards

We need to start generating fabricbot config for the dotnet/roslyn-analyzers repository for integrating issues/PRs from that repository into the area pod boards.

We concluded that we won't onboard this repo for fabricbot. Instead, we need to port the appropriate tasks to GitHub Actions and subscribe to them from that repo.


fix-demo: misc demo related fixes

I've tried to setup the demo/dev env and encountered a few issues. This PR is to address those issues:

When I ran the setup-vcluster-env.sh script, got the following error:

  --> Creating vcluster control-plane
18:40:36 fatal unknown flag: --switch-context
ERROR: Error occurred, terminating.

switch-context is no longer a valid flag for vcluster create in vcluster version 0.20.1 stable and there are no similar replacement flags. After I removed the flag, the script ran fine and ultimately the demo/dev env setup was successful so for now I think it's safe to remove this flag.

When I ran the start-* scripts, I got the following error:

set: Illegal option -o pipefail

The pipefail option seems to be a bash specific feature. I've added the bash shebang in this PR.
Also added the set x to start-agent-autonomous.sh to be consistent with the other start scripts.

misc demo README fixes for consistency.

It's weird that the --switch-context  is not available in v0.20.1, because it's been introduced in v0.20.0 :thinking:
I just upgraded from v0.20.0 to v0.20.1 to see the switch being gone.

@jannfis if you have some cycles, could you PTAL again? I want to add some ocm-io addon steps to this doc and I want to avoid having to deal with conflicts.

Sure, sorry for the delay @mikeshng. I was wondering about the impact of removing --switch-context without any replacement. I think we had to either switch back context manually, or use --connect=false.
Let me run a quick test.

OK, it seems to still work as expected.


Remove co- based classes from Components

co- classes are defined in console project and can break at any time. We need to remove dependency on them and maintain our own CSS classes for long term stability.

/assign @GowthamShanmugam

/assign @vbnrh


adding support for the $in operator on a list contains regex objects

Fix #334

@mdomke @vmalloc - could you please approve and merge this PR ?
Thanks !

@vmalloc @mdomke Any chance to approve and merge this PR ?
Otherwise - me and @tzachyrm would be happy to take more ownership in this project (as we saw you're looking for maintainers), as we are heavily dependent on it in our work, so if possible - we'd like getting the permissions to approve and merge PRs.


Fix S3 rest api signing

erlcloud_http:make_query_string can now take an extra parameter that informs it how to treat empty query parameters, either perform an empty assignment or no assignment at all
fixes #113

I'm a bit confused as I see two changes. One to make_query_string and one to the value of host that is used. This PR mentions make_query_string, and the issues mentions the host. Are both changes necessary?
Given that the changes are pretty subtle, could you please add code comments so that they won't be mistakenly reverted in the future? Thanks.

Apologies for the lack of clarity, both changes are necessary to get S3 working, root cause is the fact that Amazon signs the request differently in S3 and SQS, in S3 url's are expected to not have '='  (eg. /?acl) for empty arguments while SQS expects so (/?QueuePrefix=), this accounts for the make_query_string changes. While trying to find the issue brought up by @rawn i found out that by reverting the change i still could not get a successful S3 request, further digging revealed the host issue.
Will update the PR momentarily with the comments

@rawn could you please check that this branch fixes the issue you've detected?

I will try to find time for it tomorrow.

Sorry, this branch does not fix s3 for eu-west-1. In fact, no calls work now, all s3 calls throw "Sign atureDoesNotMatch" errors. At least the ones i tried.
Feel free to look at my quick 'hack' in git@github.com:campanja-forks/erlcloud.git.

sorry, my bad, turns out this whole host thing is unnecessary, got mislead in my tests and was actually validating against a v4 eu-central server, i think it should be fine now

@rawn do you have time to confirm that this fixes the issue? Thanks.

I have tried it out and it works. Both S3 calls and SQS calls now work as expected, for my use case.

Great. Thanks for the contribution.

I'm seeing this error, when trying to upload files to eu-central-1 region.
(ErlangError) erlang error: {:aws_error, {:http_error, 400, 'Bad Request', "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<Error>InvalidRequest<Message>The authorization mechanism you have provided is not supported. Please use AWS4-HMAC-SHA256.</Message><RequestId>9A0BEFF7D47D5BBA</RequestId><HostId>G737gwQTlOYHM15y1vOcim6QjqTZv72+k8GcUUM/tp7S7swPRr5CyrWp1+71ovVa1omkSS1TNJ4=</HostId></Error>"}}

I'm using erlcloud_s3:put_object/5. It used to work on eu-west-1 until I moved my bucket to eu-central-1.

from what i gather, eu-central-1 exclusively uses v4 signing which erlcloud does not yet support for s3/sqs