Allow changing options.type when patching options

Right now, if we have a type with:
members:
  options:
    mutable: true
    schema:
      $interface: "ShapeOptions#SameAsInterface"

...and ShapeOptions is defined using the following (as supported by #18):
components:
  interfaces:
    # A "oneOf" interface can be used to generate a TypeScript type union or a
    # Rust enumeration, including the "Post", etc., variants.
    #
    # This is not a superclass! It's a type union, using `|` in TypeScript to
    # allow more than one type. This affects the design in several surprising
    # ways. Among other things, we might have several union types that include
    # different concrete interface types in their union. For example,
    # `ShapeOptions`, `RoundishShapeOptions`, etc.
    #
    # We can only create a `oneOf` union of multiple interfaces if the
    # individual types _all_ use the same discriminator member (see below).
    ShapeOptions:
      description: "Options for a shape."
      oneOf:
        - $interface: "SquareShapeOptions#SameAsInterface"
        - $interface: "RoundShapeOptions#SameAsInterface"

    SquareShapeOptions:
      # The discriminator is a property of `SquareShapeOptions`, even if this
      # type appears without being part of `ShapeOptions`. This is because it
      # affects how the variants of this type get generated.
      discriminatorMemberName: "type"
      members:
        type:
          required: true
          initializable: true
          schema:
            type: string
            const: square
        height:
          required: true
          mutable: true
          schema:
            type: number
        width:
          required: true
          mutable: true
          schema:
            type: number

    RoundShapeOptions:
      discriminatorMemberName: "type"
      members:
        type:
          required: true
          initializable: true
          schema:
            type: string
            const: round
        radius:
          required: true
          mutable: true
          schema:
            type: number

...then it is impossible to send a Merge Patch changing .options from:
{
  "type": "square",
  "height": 10,
  "round": 20
}

...to:
{
  "type": "round",
  "radius": 15
}

This patch necessary for this conversion looks like:
{
  "type": "round",
  "radius": 15,
  "height": null,
  "width": null,
}

We need to be able to pass other keys as null, so we can remove the original square parameters when PATCHing type.
There are several strategies we can use here:

Allow passing any key with "key": null. We could do this using additionalProperties: { schema: { type: "null" } } }. But we need to check with @blakew about whether this breaks our doc tooling.
Only allow height: null and width: null in RoundShapeOptionsMergePatch. But this would require generating a special version of RoundShapeOptionsMergePatch that knows about SquareShapeOptionsMergePatch. Call it "ShapeOptionsRoundShapeOptionsMergePatch". But since oneOf is a type union, not inheritance, we might need several versions of RoundShapeOptionsMergePatch, one for each type union which includes it. So if we have type RoundedShapeOptions = RoundShapeOptions | EllipticalShapeOptions, then we would need RoundedShapeOptionsRoundShapeOptionsMergePatch and RoundedShapeOptionsEllipticalShapeOptionsMergePatch, and so on. This is one of those classic bad ideas that just keeps getting worse.
Like (2), but we bake RoundShapeOptionsMergePatch and SquareShapeOptionsMergePatch directly into ShapeOptionsMergePatch. This would require a lot of code, but we might be able to make it nice?

@hanakslr and @blakew, I'd love your thoughts here.

Just as background, this currently works the way it does because we're deliberately mirroring the way this works in TypeScript. The simple version looks like this:
type ShapeOptions = SquareShapeOptions | RoundShapeOptions;

interface SquareShapeOptions {
  type: "square",
  height: number,
  width: number,
}

interface RoundShapeOptions {
  type: "round",
  radius: number,
}

A more complicated example where RoundShapeOptions is used in multiple type unions:
type ShapeOptions = SquareShapeOptions | RoundShapeOptions | EllipticalShapeOptions;

type RoundishShapeOptions = RoundShapeOptions | EllipticalShapeOptions;

interface SquareShapeOptions {
  type: "square",
  height: number,
  width: number,
}

interface RoundShapeOptions {
  type: "round",
  radius: number,
}

interface EllipticalShapeOptions {
  type: "round",
  major: number,
  minor: number,
}

The key insights here are:

These are type unions, not inheritance.
OpenAPI's decision to put discriminator information on ShapeOptions is caused by a mix of the facts that JSON Schema specifies validation not schemas, and the fact that OpenAPI awkwardly tries to graft schema semantics over JSON Schema and there are tons of corner cases where that doesn't work.

openapi-interfaces basically exists to let us declare TypeScript-style interface types in a higher-level fashion than OpenAPI can support. So in cases where OpenAPI makes things much too hard, our default response is to look at what TypeScript does.

Proposal (1), above, would change our output from:
    RoundShapeOptionsMergePatch:
      type: object
      required:
        - type
      properties:
        radius:
          type: number
        type:
          type: string
          const: round
      additionalProperties: false

    RoundShapeOptionsMergePatch:
      type: object
      required:
        - type
      properties:
        radius:
          type: number
        type:
          type: string
          const: round
      additionalProperties:
        type: "null"

This would allow passing arbitrary other keys, as long as they always contained a null. We'd only generate the special additionalProperties if discriminatorMemberName is present.


fix incorrectly imported bottle websocket package

Credits go to:
@kaminari-katt
@mikessut
Describe the solution and problem
Python 3.12.1 seems to have a problem with importing bottle.ext.websocket. Replacing it with bottle_websocket fixes this.

Also suggested in https://github.com/python-eel/Eel/pull/704


Second Function/Task

Write the second function to print the Truth Table as well as the canonical SoP and PoS.

Forgot to mention I finished this a long time ago.


Turn-around with PCA?

The readme says "Make sure your Default State is set to either Cold & Dark or Turn-Around with APU" but from my experience "Turn-Around with PCA" works fine as well, or am I going to run into any issues using that state as default? If the PCA state isn't fully supported it would be nice to have that implemented.

Oh and by the way, I LOVE this app! Super great work!

I saw now that you mention Turn-Around with GPU under Usage - Pre-Flight as an acceptable startup state.

Yeah was pointed to Chewwy's Stream and saw that is was perceived as Problem.
Well, it isn't 😅
The key Takeaway here is: Don't start with Engines running!
But I can't just write that because: you can start with Engines running - if you don't need any Departure-Services 😉
Fenix2GSX will go directly to it's "Taxi-Out" State and removes the Ground-Equipment as a little QoL Improvement.


updating

Docs Build status updates of commit f0cc947:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs-conceptual/azureadps-2.0/working-with-licenses.md
:warning:Warning

Details

docs-conceptual/azureadps-2.0-preview/working-with-licenses.md
:warning:Warning

Details

azureadps-2.0-preview/AzureAD/AzureADPreview.md
:white_check_mark:Succeeded

azureadps-2.0-preview/AzureAD/Get-AzureADMSAuthorizationPolicy.md
:white_check_mark:Succeeded

azureadps-2.0-preview/AzureAD/Set-AzureADMSAuthorizationPolicy.md
:white_check_mark:Succeeded

docs-conceptual/azureadps-2.0/working-with-licenses.md

Line 14: [Warning-h1-not-first] Markdown content is not allowed before H1.
Line 15: [Warning-h1-missing] H1 is required. Use a single hash (#) followed by a space to create your top-level heading.

docs-conceptual/azureadps-2.0-preview/working-with-licenses.md

Line 14: [Warning-h1-not-first] Markdown content is not allowed before H1.
Line 15: [Warning-h1-missing] H1 is required. Use a single hash (#) followed by a space to create your top-level heading.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 0188abb:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs-conceptual/azureadps-2.0/working-with-licenses.md
:warning:Warning

Details

docs-conceptual/azureadps-2.0-preview/working-with-licenses.md
:warning:Warning

Details

azureadps-2.0-preview/AzureAD/AzureADPreview.md
:white_check_mark:Succeeded

azureadps-2.0-preview/AzureAD/Get-AzureADMSAuthorizationPolicy.md
:white_check_mark:Succeeded

azureadps-2.0-preview/AzureAD/Set-AzureADMSAuthorizationPolicy.md
:white_check_mark:Succeeded

mapping/groupMapping-2.0-preview.json
:white_check_mark:Succeeded

docs-conceptual/azureadps-2.0/working-with-licenses.md

Line 14: [Warning-h1-not-first] Markdown content is not allowed before H1.
Line 15: [Warning-h1-missing] H1 is required. Use a single hash (#) followed by a space to create your top-level heading.

docs-conceptual/azureadps-2.0-preview/working-with-licenses.md

Line 14: [Warning-h1-not-first] Markdown content is not allowed before H1.
Line 15: [Warning-h1-missing] H1 is required. Use a single hash (#) followed by a space to create your top-level heading.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 105bc2d:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs-conceptual/azureadps-2.0-preview/working-with-licenses.md
:warning:Warning

Details

azureadps-2.0-preview/AzureAD/AzureADPreview.md
:white_check_mark:Succeeded

azureadps-2.0-preview/AzureAD/Get-AzureADMSAuthorizationPolicy.md
:white_check_mark:Succeeded

azureadps-2.0-preview/AzureAD/Set-AzureADMSAuthorizationPolicy.md
:white_check_mark:Succeeded

docs-conceptual/azureadps-2.0/working-with-licenses.md
:white_check_mark:Succeeded

mapping/groupMapping-2.0-preview.json
:white_check_mark:Succeeded

docs-conceptual/azureadps-2.0-preview/working-with-licenses.md

Line 14: [Warning-h1-not-first] Markdown content is not allowed before H1.
Line 15: [Warning-h1-missing] H1 is required. Use a single hash (#) followed by a space to create your top-level heading.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 5ff1740:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

azureadps-2.0-preview/AzureAD/AzureADPreview.md
:white_check_mark:Succeeded

azureadps-2.0-preview/AzureAD/Get-AzureADMSAuthorizationPolicy.md
:white_check_mark:Succeeded

azureadps-2.0-preview/AzureAD/Set-AzureADMSAuthorizationPolicy.md
:white_check_mark:Succeeded

docs-conceptual/azureadps-2.0-preview/working-with-licenses.md
:white_check_mark:Succeeded

docs-conceptual/azureadps-2.0/working-with-licenses.md
:white_check_mark:Succeeded

mapping/groupMapping-2.0-preview.json
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 24b9def:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

azureadps-2.0-preview/AzureAD/AzureADPreview.md
:white_check_mark:Succeeded

docs-conceptual/azureadps-2.0-preview/working-with-licenses.md
:white_check_mark:Succeeded

docs-conceptual/azureadps-2.0/working-with-licenses.md
:white_check_mark:Succeeded

mapping/groupMapping-2.0-preview.json
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


Issuing my query not in a subquery.

When the full query gets arranged by Windshaft, having my query in the subquery named  'cdbq' prevents it from using the correct index.
If I try (via psql) my query, adding the conditions that Windshaft adds, eg. 'AND "location" && ST_MakeEnvelope(....)'  as part of my WHERE clause, it uses the desired index.
Is there any way to do this? Is there any part of the code I could override to do this? I tried grepping through it but couldn't find what I was looking for.
Thanks for this great software!

how do you know it's not using the index? postgres should guess even in a subquery

Hi Javi, I'm using EXPLAIN on pgAdmin, and it shows a seq scan on the one with a subquery, while it shows a Index Scan in the plain-query one.
My sub-query uses a group by on the 'geom' field, that's probably  the cause.

could you post your query?

I think you could avoid the seq scan filtering before using !bbox! special token

Great. Using !bbox! solved it.
Thanks!

Could you share a little bit more about your query?

Yeah, absolutely
SELECT AVG(value) as avgValue,
   ST_MakeEnvelope(
       TRUNC(cast(ST_X(location) as numeric), 3),
       TRUNC(cast(ST_Y(location) as numeric), 3),
       case
           when TRUNC(cast(ST_X(location) as numeric), 3) < 0
           then TRUNC(cast(ST_X(location) as numeric), 3) - 0.001
           else TRUNC(cast(ST_X(location) as numeric), 3) + 0.001
       end,
       case
           when TRUNC(cast(ST_Y(location) as numeric), 3) < 0
           then TRUNC(cast(ST_Y(location) as numeric), 3) - 0.001
           else TRUNC(cast(ST_Y(location) as numeric), 3) + 0.001
       end,
       4326
   ) as grouped_location
FROM mytable
WHERE
location && !bbox!
GROUP BY grouped_location

I'm generating a squared global-grid, and AVGing values of points inside it.
Using !bbox! I can get it to use the index :+1:

thanks !


updates in side bar of admin panel

unable to connect admin pages of side bar with admin navigation

update in function names(admin header and admin nav)


Audit module and test update for SG changes

Codecov Report
Patch coverage: 65.42% and project coverage change: +0.23 :tada:

Comparison is base (c1aaf91) 71.81% compared to head (1224830) 72.05%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@            Coverage Diff             @@
##              dev     #509      +/-   ##
==========================================
+ Coverage   71.81%   72.05%   +0.23%
==========================================
  Files          90       90
  Lines        7700     7746      +46
==========================================
+ Hits         5530     5581      +51
+ Misses       2170     2165       -5

Impacted Files
Coverage Δ

metamist/audit/generic_auditor.py
57.61% <50.40%> (+1.76%)
:arrow_up:

metamist/audit/audithelper.py
57.60% <83.33%> (+17.60%)
:arrow_up:

test/test_generic_auditor.py
88.33% <88.67%> (+2.16%)
:arrow_up:

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Fixed increasing consumer permits after ack dedup operation

Motivation
With the delayed acknowledgment tracker, the deduping logic is used to ignore messages that are being resent from broker after reconnection but for which the application has already acked.
These acks are tracked in client library and sent later in batches (default 100ms).
When we ignore messages as dups for the above logic, we must always increase the available permits, otherwise the count will be off. In cases where the receiver queue size is small, that could lead to a consumer getting stuck, since it will not advertise more permits to the broker.

run java8 tests
run cpp tests

run java8 tests

Merged in 2.3.1 at
7f6d36d


Swiq'ing a capitalized word does not behave as intended

If you swiq a word such as getID or CONSTANT_VARIABLE it will not select the capitalized word, only 1 letter.
Apart from this, this is a fabulous package and should be used in conjuncation with Swackets for optimal Atom sweavolution :tada: :+1:

Thanks, this will be fixed in a future release.


[Feature Request] Real-time Preview Support for Extension Commands

Description
Current Behavior
Currently, third-party extension commands require users to press Enter to execute and see results, even for simple conversions or calculations. This creates unnecessary friction in the user experience.
Desired Behavior
Allow extension developers to implement real-time preview functionality similar to Raycast's built-in Calculator command, where results are shown instantly as users type, without requiring Enter to be pressed.
Use Cases
Currency Conversion
User types: convert 100 USD
Instantly sees: conversions to different currencies
Updates as user modifies the amount
Similar Features
Built-in Calculator command already implements this behavior.

This would hurt the performances of the root search a lot. Unlikely that we'll do it

This would hurt the performances of the root search a lot. Unlikely that we'll do it

Yeah, understand the performance concern. IMO, it can be an option that user can enable it based their own situation.


build(npm): Upgrade to<EMAIL_ADDRESS>

Update to<EMAIL_ADDRESS>Also, bump<EMAIL_ADDRESS>and<EMAIL_ADDRESS>to resolve siblings' peerDependencies requirements

Is this ready for review?
Considering Angular2 is now on beta.8 and will be on beta.9 tomorrow, could you at least push to beta 8? There's not really any features we want but it's always nice to make sure it works without regressions.
On a separate note, please rebase your branch as there are some document changes that should not appear in this PR.
Cheers :D

Hi @hansl,
I've updated to<EMAIL_ADDRESS>All npm scripts were running success locally, however, I can see a build error from Travis CI, can't really reproduce the same error. Any ideas what's going on with this build error?
Build error: Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL.
Other than that, I think this is ready for review. Thanks for the quick reply, really appreciate your help and feedback.
Thanks,
Jay Kan

Okay. Start by smashing your commits into a single one using this guide: http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html. We want to only have a single commit by PR.
We also need you to rebase everything on the latest master. I see you rebased your branch but not your master, so the diff shows changes that are not part of this PR.
Finally, you want to sign the CLA. This is required for any contributions with Google open source projects.
Once these things are done I'll approve it and merge it myself. Thanks for taknig the time for this!

So I've squashed my last 4 commits to one and I've also rebase my master branch as well.
Also, I've signed the CLA yesterday already not sure why I still need one. Please find attached screenshot for my CLA.
Please let me know if there's anything else I need to do, thanks!

The problem is the CLA hasn't been signed for travis (on this PR). That's because you still have 3 commits.
Again, could you properly rebase on top of the master branch of this repo, and rebase your master on the master branch of this repo, to get rid of the 2 commits that are not relevant to this PR. If you need help I'm on gitter right now and can help you do it.

You also have to leave a comment that says I signed it! for the CLA bot to pick it up.

Oh I see what's going on.  You're from an invalid branch state, where the merge commit from @traviskaufman wasn't removed. I had to force push master to fix this, and you apparently fetched the history for this branch while it was in an invalid state.
Could you do this PR again from a clean master?  This could be fixed but for such a simple PR it's just better to redo it.

I'll close this now; just do a new PR for this and I'll LGTM it right away.

Thanks for your quick reply @hansl, I'll do a new PR :)


import error "Calling function 'makeDecorator', function calls are not supported"

Hi all,
I meet some problem with this plugin.
Here is my running environment:

@angular/cli: 1.0.0-rc.1
node: 6.9.4
os: win32 x64
@angular/common: 2.4.9
@angular/compiler: 2.4.9
@angular/core: 2.4.9
@angular/forms: 2.4.9
@angular/http: 2.4.9
@angular/platform-browser: 2.4.9
@angular/platform-browser-dynamic: 2.4.9
@angular/router: 3.4.9
@angular/cli: 1.0.0-rc.1
@angular/compiler-cli: 2.4.9

And  this the error message
Error encountered resolving symbol values statically. Calling function 'makeDecorator', function calls are not supported. Consider replacing the function or lambda with a reference to an exported function, resolving symbol Component in<EMAIL_ADDRESS>resolving symbol Component in<EMAIL_ADDRESS>resolving symbol Component in<EMAIL_ADDRESS>resolving symbol Component in<EMAIL_ADDRESS>resolving symbol Ng2LetterAvatar in C:/Users/xxx/Desktop/WorkingProjects/neutrino/ng2frontend/node_modules/ng2letteravatar/ng2letteravatar.ts, resolving symbol Ng2LetterAvatar in C:/Users/xxx/Desktop/WorkingProjects/neutrino/ng2frontend/node_modules/ng2letteravatar/ng2letteravatar.ts

I'm facing the same error when building for production with angular-cli. ng server works well, but ng build doesn't.

@infinitysky have you found any workaround?

I am getting this issue to:
ERROR in Error encountered resolving symbol values statically. Calling function 'makeParamDecorator', function calls are not supported. Consider replacing the function or lambda with a reference to an exported function, resolving symbol Injectable in<EMAIL_ADDRESS>resolving symbol OpaqueToken in<EMAIL_ADDRESS>resolving symbol OpaqueToken in<EMAIL_ADDRESS>Is this going to get fixed? If not, I am going to have to switch libraries.  Please advise.

@infinitysky @gastonelhordoy @bendg25
This component is moved to ngu-utility module https://github.com/uttesh/ngu-utility and all issues are addressed.


Initial rework of a common RH SSO deployment to support the secured quick starts

DO NOT MERGE.
This is just for review currently. We can talk about merging it after a dev block to discuss the changes.

Out of date.


Crash on launch. "EXCEPTION_ACCESS_VIOLATION" at 0x7FFBB135ECA0 d3d11.dll+012ECA0

Describe the bug
Whenever the game is launched, after the ENB loads, it calls "EXCEPTION_ACCESS_VIOLATION" at 0x7FFBB135ECA0 d3d11.dll+012ECA0
This crash is repetetive, every time I launch the game, same thing happens.
Is it already a known issue?
Not that I believe so, no.
Steps to reproduce

Launch the game through MO2;
Try clicking something in-game post ENB loading.

Environment
// From crashlog:
OS: Microsoft Windows 10 Pro v10.0.19044
CPU: AuthenticAMD AMD Ryzen 5 3600 6-Core Processor
GPU #1: Nvidia TU104 [GeForce RTX 2060]
GPU #2: Microsoft Basic Render Driver
PHYSICAL MEMORY: 13.14 GB/31.94 GB
Contact:
I am not in your discord server due to server limit on my main. Incase you wish to contact me, copy and paste this exact name: mrlei

Additional context
I'll attach the crashlog, as for the CLAS, the one bundled with the MO2 crashes on launch.
Here's the crashlog:
https://pastebin.com/DNW704fW

@ElisPlayz
Please verify you have all the pre-install requirements listed in the read me.
Please also add the MO2.exe and Fallout4.exe as an exception in your antivirus. The Fallout4.exe will be in the MO2 folder within the Stock folder.
more info can be found here: https://docs.google.com/document/d/17FzeIMJ256xE85XdjoPvv_Zi3C5uHeSTQh6wOZugs4c/edit

After reinstalling everything from the pre-install requirements list, Buffout started to point out one specific .dds that calls CreateTexture2D fails with. Here's the full error: https://imgur.com/a/1bW9zHK


Allow testing string sources

Closes #86.
Allows testing files passed to tsd as strings, either programmatically:
import tsd from 'tsd';

const diagnostics = await tsd({
	testFiles: [
		'file1.ts',
		{
			'name': 'file2.ts',
			'text': 'import {expectType} from \'tsd\';\nexpectType<number>(1);',
		},
	],
});

or via the CLI with a concise syntax (file.extension:source):
$ npx tsd --files "foo.ts:$(cat output.txt)"

Type definitions have been updated like so:
type TestFiles = ReadonlyArray<(
	| string
	| {name: string; text: string}
)>;

type SourceFiles = ReadonlyArray<{name: string; text: string}>;

type ParsedTestFiles = {
	globs: readonly string[];
	sourceFiles?: SourceFiles;
};

interface Context {
	cwd: string;
	pkg: PackageJsonWithTsdConfig;
	typingsFile: string;
	testFiles: ParsedTestFiles;
	config: Config;
}

interface Options {
	cwd: string;
	typingsFile?: string;
	testFiles?: TestFiles;
}

Still some items to finish, but opening this PR to get feedback:

[ ] Document feature in readme and CLI help
[ ] Add documentation comments to added functions/types
[ ] Improve names/concepts (e.g. globs vs. sourceFiles, etc.)
[ ] Consolidate repetition of some types
[ ] Make sure that parsing via the CLI is robust
[ ] See if input needs to be escaped

Just a warning. I have very little time to spend on this project. So I will not be able to review non-essential things. I'm just helping out to keep it up to date with TS releases. So if you plan to make a lot of changes, I would recommend reaching out to @SamVerschueren to become a maintainer.


time: obsolete comment in zoneinfo.go

Obsolete comment in src/time/zoneinfo.go
// the start and end times bracketing sec when that zone is in effect,
// the offset in seconds east of UTC (such as -5*60*60), and whether
// the daylight savings is being observed at that time.
func (l *Location) lookup(sec int64) (name string, offset int, isDST bool, start, end int64)

should removed the last one
"and whether the daylight savings is being observed at that time".
Caused by this change:
"remove some unused return parameters" https://cs.opensource.google/go/go/+/8da180f6cac51f6cb8a316b962f797dbaf7ee96f

The isDST return value was added again in https://golang.org/cl/264077, so incidentally the godoc comment is correct again.

As @tklauser pointed out, this works as intended now. Thanks.


USB MIDI doesn't enumerate after warm reboot

USB MIDI not always enumerates after plugging in the DUO. After for example a firmware flashing action, the MIDI port does not enumerate.

Fixed in https://github.com/datomusic/duo-imxrt/commit/b805c3d79bf7ab81755ad175bfe315a980b40d7d


WIP: Stop hiding source of syntax errors

This helps out with #308. It does the following things:

Make the changes noted here
Move babel hook test to CLI (needed after making change above)
Add an API test for nonexistent files

However, there's one issue. The fork.js test that calls a nonexistent file ("rejects on error and streams output") doesn't seem to get a "file does not exist error" (it just gets "error code 1 returned") and worse, a stack of it shows up in the test results. The testing continues fine though, but I am not sure how to contain it or test it.
Originally the test had an .on('uncaughtException') clause but after making the babel.js changes, it is not called at all so I removed it.
Any suggestions and help is appreciated!

worse, a stack of it shows up in the test results.

Yep, that is anticipated. Basically due to some V8 issues, it is impossible to extract the filename and/or line number from caught SyntaxErrors in JavaScript. Node includes a hack that will print that information to stderr, but it relies on native C++ code. This is why we are changing the position of where we start listening for uncaughtException, it allows the error to be handled natively by Node, so we see the correct filename and line-number. Ideally we wouldn't have to do it this way, but we are picking the lesser of two evils.

Seems like my suspicion was right. Node 0.10 gives an error code of 8 on no file fount, while other Node versions give an error code of 0, which is why my test was failing. It's a quick regex change luckily.

looks like you missed 1 t.match

Node 0.10 gives an error code of 8 on no file fount, while other Node versions give an error code of 0

0? Really? I would have expected 1

It looks like it was 1 - that's good. As long as it is non-zero.

Ah yeah sorry I mistyped. Well either way I got that fixed. The AppVeyor builds all passed—not sure why the check isn't there yet.

AppVeyor takes about 20 minutes per commit to complete, you pushed a few commits in rapid succession, so it was way behind. I cancelled all of them. Go ahead and fix that last t.match and push again, and we should be good.

LGTM

Thanks @sotojuan!

I was playing around with/learning about syncing forks and accidentally pushed, so I guess I'll need your LGTM back @jamestalmage. Sorry about that ~_~.

LGTM

Great work @sotojuan :) :cake:

Leonardo says thank you!


add George Adams to maintainers list

[ ] Have you followed the guidelines in our Contributing document?
[ ] Have you checked to ensure there aren't other open Pull Requests for the same change?
[ ] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.
[ ] Have you successfully run brew style with your changes locally?
[ ] Have you successfully run brew typecheck with your changes locally?
[ ] Have you successfully run brew tests with your changes locally?

Review period will end on 2021-10-05 at 19:09:48 UTC.

Thanks, @gdams! And welcome to the Homebrew team!
We have an action that updates these pages for us automatically every few hours. There are a few other documents that need to be updated (i.e. the manage and its corresponding docs site page) and the action handles those as well. I went ahead and triggered a run that opened a PR here: https://github.com/Homebrew/brew/pull/12184 so I'll close this in favor of that one.
(More info, if you're curious, is available in the Homebrew/brew Maintainer Guide)


Make a website that's not github.io so people could use it while in school aka i want to use this while in school but they blocked websites using github.io

Not that much of anything really just want to use this while on my school computer please

Go to this issue: https://github.com/BinBashBanana/webretro/issues/37
Right-click the blue "here" link, click save as, and open the consequent file. As its a file, it should be perfectly fine and never be blocked.

Thank you @HaxsMaster

thanks again


Please remove the contradiction

[Enter feedback here]
Hello :
the document has a contradiction :
At the beginning it says " You can also allow access to on-premises resources like line of business (LOB) apps, file shares, and printers.".
At the end it says " Users won't be able to authenticate to applications that depend on Active Directory authentication"
(that is false, AADJ computers are able to obtain Kerberos TGS from domain controllers to authenticate to legacy app (ok , not all, see below)
Must be correct in something like  " Users might be not able to authenticate to applications that depend on the presence of computer account object in Active Directory : evaluate the legacy app and consider updating to an app that uses modern Auth, if possible".
In my lab I tested successful authentication to legacy app : FileShare, IIS in kerberos mode, Remote Desktop-RestrictedAdmin, MSSQL Management Studio (SQL 2012).
Regards

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

ID: 00ba9775-1242-af4d-a9c0-8979cc5d57dc
Version Independent ID: 5063400b-fe96-79f4-e37f-6c89e26ee9d0
Content: Access on-premises resources from an Azure AD-joined device in Microsoft 365 Business - Microsoft 365 Business
Content Source: microsoft-365/business/access-resources.md
Service: o365-administration
GitHub Login: @Sirkkuw
Microsoft Alias: sirkkuw

@dbona75 Thank you for your feedback. We have made changes to the document via PR#https://github.com/MicrosoftDocs/microsoft-365-docs/pull/4102
Thanks
Sri

@msbemba Thank you very much for the contribution and updating the documentation with PR. @dbona75 Hope this update is helpful for you. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


[PI-1623] : Code Handover | Chatbot | when large file is uploaded for any textual answers the service is terminating

Patch Created in master instead of develop


add kafka schema JSON support

minor nit: formatting of the json data in the tests looks off

yes indeed, but this is how make testfmt likes it to be, if I format it correctly we will get make lint CI errors. I suggest lets keep it as it is and I will create a ticket to fix testfmt JSON formating


Implement media list REST API

There are a lot of new REST APIs for wikipedia present in the REST API docs.
We'll look through them one by one and implement the same. Any one who wants to pick up on any other REST API should ideally open a new issue.
The REST API has a /page/media-list/{title} endpoint which lists the media files used in the page. This is something I would love to have in wikipedia.
Implementation for this should follow the summary or related method flow. Remember to write unit tests for all possible scenarios in your new functions, and try to use types as far as possible.
I'll be happy to help anyone who wants to pick this up.

Taking this up.

Closed via #3


capa-rules release process and versioning guarantees

see issues #551 #552 #555
Here's a proposal for how we should handle breaking changes to capa and its rule syntax. In essence, I think we should maintain major version branches for capa-rules and point users to fetch the rules that match their major version of capa.

We're in a weird spot right now: we can't introduce breaking changes to the master branch until v4 because our documentation points v3 users to checkout rules from master.
Until v4 is released, we should make breaking changes to the v4-dev branch. This is a temporary branch for pending v4 changes. We'll delete it once we release v4. We can make non-breaking changes to master.

When we release v4, we'll create a branch v4 that contains all the changes for that line of releases. We'll sync it from master upon each minor or point release (or more often, doesn't hurt). Once v5 is released, master can no longer be merged into v4; however, we can backport non-breaking changes into the v4 branch after v5 is released.

Over time, we will accumulate branches corresponding to major releases.
release plans
In order to release v4:

[x] create branch v3 from master. This is where any backported changes will go.

we'll point users to pull from this branch when using capa v3.

[ ] merge branch v4-dev into master. Master now contains pending breaking changes.
[ ] delete branch v4-dev to avoid any confusion. All breaking changes are now in master.
[ ] create branch v4 from master. This will contain all changes up until v5 (and backported changes beyond then).

at each minor or patch release of v4, we will merge master into v4
once we hit v5, we will no longer merge master into v4

[ ] cut release in github.
[ ] create branch v5-dev from master. This will contain any pending breaking changes prepared for v5.

During the v4 line of development, non-breaking changes are made to master while breaking changes (for v5) are made to v5-dev.
At a minor or patch release:

[ ] merge master into v4
[ ] cut release in github

Upon reaching v5:

[ ] merge master into v4. Now all pending non-breaking changes are in v4.
[ ] merge v5-dev into master. Master can no longer be merged into v4.
[ ] create branch v5 from master. This will contain all changes up until v6 (and backported changes beyond then).
[ ] cut release in github.
[ ] create branch v6-dev from master. This will contain any pending breaking changes prepared for v6.

considerations

when accepting PRs, double check the target branch:

non-breaking changes go into master. this is the common case for the community submitting rules.
breaking changes go into v4-dev. when capa devs make changes to capa, such as adding new features/logic/blocks or removing old ones, and then update the ruleset, these changes need to go into v4-dev.
its ok to sync master into v4-dev.
capa devs probably want to track v4-dev.

point users to check out rules from the branch that matches their major version, e.g. v4.
do we need to check the capabot logic and how it syncs the submodule in the capa repo?
i think we may want to update the capa-rules submodule away from master when making a new major release? or at least if we ever backport changes into a capa-rules branch.

I may be missing something, but I think this is not needed. We tag capa-rules when releasing capa: https://github.com/mandiant/capa-rules/tags
If we are doing the releases correctly any minor release should be compatible. To be sure, we could also tell users to use the exact same version as that is the one we have tested.
Shouldn't be enough to specify in the documentation to download the correct capa-rules version?

Using tags is probably fine and is less complex for us, so is probably the way to go. Thanks for reminding me to pick the simpler route :-)
So in summary:

continue to develop on master
upon releases, tag as we've been doing, like v3.1.0
update documentation to tell users to pick the latest compatible release (major version)

this puts a bit more burden on users to pick the right version, but our users aren't dumb, and we should trust them
still, it might be nice to have in the documentation a clear table: "if you have capa v3, use tag 3.0.3"
git clone .... --branch <tag> will also work fine

... much simpler.
As @mr-tz mentioned, I think there's still an issue of breaking changes on master. We may still want to consider doing breaking changes on a feature branch like v4-dev. This way we can tag from master. Otherwise, we can't intersperse v3 rule updates with v4 rule development.

Please correct me if I'm wrong but based on the most recent post from @williballenthin our decision is to continue development, including breaking changes, on master. This doesn't play well with our current CI setup for capa-rules as we test using the latest release which won't support any breaking changes that we've added to master. Consider #601 containing rules that are not supported by our most recent release, v4.0.1.
I propose we use a feature branch as discussed above to develop breaking changes. This feature branch should use the latest master branch for testing, not the latest release as the breaking changes won't be supported. Non-breaking changes can be developed in master and master should use the latest release for testing.
This workflow may looking something like:

got breaking changes? branch from v5-dev for development

v5-dev's CI uses capa master branch for testing

got non-breaking changes? branch from master for development

master's CI uses latest capa release for testing, e.g. v4.0.1

In most cases, new rules or rule updates won't use breaking changes that haven't been released yet so users shouldn't see much of a change in their rule dev workflow.
Thoughts?

I think we should keep the master branches of both projects in sync. We always release capa rules together with a capa version. So if there are breaking changes in master in capa, new rules should be adapted to the breaking changes. This way we can release capa knowing everything in capa-rules is alright.
The CI at the moment is using capa master for the linter and last release to run the rules. 😕 I think we should update the test to run the rules with master.

See my proposal in https://github.com/mandiant/capa-rules/pull/621 to change the CI check:

check latest released version is compatible with rules master
for branches into a dev-X branch, only run the linter (based on code master)

This requires Willi's and Mike's proposal to merge into a dev-X branch for rules that are in master but not in the latest release yet.

@Ana06 totally agree it is preferable to keep both master branches in sync. I also think it's worth enabling users the ability to use point releases of capa rules between major releases. For example, if a user merges 10 new rules that work with the latest release but capa rules master contains breaking changes then those rules can't be used until the next major release. This could be a long time depending on the release cycle. Is there a way around this limitation with our current setup?
An extension to the proposals above could be to create a feature branch of capa master containing all breaking changes contained in the next major release. This requires an additional branch but we could keep capa rules v*-dev in sync with capa v*-dev and capa rules master in sync with capa master.

IMO users should use released rules, because they may not know if breaking changes have been introduced and the new rules are not compatible with old releases.
We could release a new version of capa (and capa-rules as they are released together) before merging breaking changes into master. The dev branch allows to merge the breaking changes later, but may generate merge conflicts that give us more work.

After a lot of back and forth, I think we just need to update the CI check at this point. I propose to change the workflow to:

ensure code and rules master are compatible
(optional: ensure the latest release is compatible with the latest respective branch)

Our current workflow:

all the latest code and rules are in master (including unreleased and backwards incompatible features, one could also refer to it as development)

Our users:

use a PyInstaller compiled binary with embedded rules (no issue)
use code master and rules master (no issue)
use pip install flare-capa/PyInstaller binary and rules master (potential issue)

If the new rules are not compatible (breaking change has been introduced) we already point users to the respective branch via the documentation and the command line (per the discussion above).

After a lot of back and forth, I think we just need to update the CI check at this point. I propose to change the workflow to:
* ensure code and rules master are compatible

* (optional: ensure the latest release is compatible with the latest respective branch)

Our current workflow:
* all the latest code and rules are in `master` (including unreleased and backwards incompatible features, one could also refer to it as `development`)

Our users:
* use a PyInstaller compiled binary with embedded rules (no issue)

* use code `master` and rules `master` (no issue)

* use `pip install flare-capa`/PyInstaller binary and rules `master` (potential issue)

If the new rules are not compatible (breaking change has been introduced) we already point users to the respective branch via the documentation and the command line (per the discussion above).

works for me - let's update #621 to reflect this workflow which as I understand means changing CI to run master rules against master code?

i also agree with this proposal On Sep 16, 2022, at 4:15 PM, Mike Hunhoff @.***> wrote:
After a lot of back and forth, I think we just need to update the CI check at this point. I propose to change the workflow to:

ensure code and rules master are compatible

(optional: ensure the latest release is compatible with the latest respective branch)

Our current workflow:

all the latest code and rules are in master (including unreleased and backwards incompatible features, one could also refer to it as development)

Our users:

use a PyInstaller compiled binary with embedded rules (no issue)

use code master and rules master (no issue)

use pip install flare-capa/PyInstaller binary and rules master (potential issue)

If the new rules are not compatible (breaking change has been introduced) we already point users to the respective branch via the documentation and the command line (per the discussion above).
works for me - let's update #621 to reflect this workflow which as I understand means changing CI to run master rules against master code?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

I've updated https://github.com/mandiant/capa-rules/pull/621 accordingly.

We hope this is addressed via rule releases.


Link Broken

Both Angular links are broken :
https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-angular/samples/MSALAngularDemoApp

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

ID: 6508ffd9-e8f0-21b3-fada-d270003da93d
Version Independent ID: 2a888023-46c6-c8b3-f4b4-01487d0e8576
Content: Code samples for Microsoft identity platform
Content Source: articles/active-directory/develop/sample-v2-code.md
Service: active-directory
Sub-service: develop
GitHub Login: @rwike77
Microsoft Alias: ryanwi

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

@RobertoBorges The PR for the fix has been created and it will be merged soon. Thanks again for pointing this out, I am closing the issue based on this update, please let us know if there is something else that we can help you with.

The links are still not working, When is it going to be fixed?


Add autoLowLatencyMode config

It is not always known if a stream is low latency or not (for example, when adding streams from multiple providers). To avoid having to use a responseFilter, a configuration is added to enable low latency automatically.
Related to https://github.com/google/shaka-player/issues/1525

@michellezhuogg This is related to your work in low latency, can you review?

Hello @avelad ,
Thank you! What are the scenarios to use this config? How would it interact with lowLatencyMode config?

@michellezhuogg
Use a default config with:

lowLatencyMode = false
rebufferingGoal = 2
inaccurateManifestTolerance = 0
autoLowLatencyMode = true

In a Live TV app with a mix of providers and mix of low latency
Stream A (low latency), Stream B, Stream C, Stream D (low latency)

set default config
load Stream A
set default config
load Stream B
set default config
load Stream C
set default config
load Stream D

In stream A and D the player automatically chooses the low latency mode, in stream B and C the player takes the conservative values of not low latency
Note: the application does not know which of the previous streams is low latency, but in the streams in which it is available it activates it by default.

@avelad, low latency mode would inhibit response filters for media segments (but not for manifests or license responses), would require the accurate manifests (inaccurateManifestTolerance=0), and would use a low startup/rebuffering goal (rebufferingGoal=0.001) to allow playback to start with less than one segment of content.
Which of these things is a problem for your scenario?  If some of your content is low-latency, could you not just turn on low latency mode?
In fact, for DASH, and even for VOD, lowLatencyMode=true could result in faster startup times even without low-latency features in the manifest.  So the main reason to avoid it is if you need segment response filters.

@joeyparrish
Speaking of LIVE streams.
The scenario is not knowing if the stream is low latency or not.
I always use inaccurateManifestTolerance = 0 by default, but using rebufferingGoal = 0.001 by default on non-low latency streams can be a problem in my case.
For VOD I have no problem.

Any news?

Hello @avelad ,
Sorry for the late reply.

Would you please help us understand better your case and the problem with using rebufferingGoal = 0.001 by default on non-low latency streams?
What will enableLowLatencyMode do?
What happens when:
lowLatencyMode = true && autoLowLatencyMode = false?
lowLatencyMode = true && autoLowLatencyMode = true?

Thank you!

HI @michellezhuogg,

In many cases I need a rebufferingGoal = 1.5 * segmentLenght to avoid new rebuffering
enableLowLatencyMode activate the lowLatencyMode flag if the stream loaded is  a low latency stream.
lowLatencyMode always takes precedence, so if the lowLatencyMode value is activated autoLowLatencyMode has no effect

I have been carefully studying the need for this, and the alternative is to use filters to determine if the manifest is low latency and change the rebufferingGoal setting.
Thanks,

Makes sense to me, and we need better document or comments to explain how lowLatencyMode / autoLowLatencyMode work for other developers.
Thank you!

@michellezhuogg Is there anything else I can do so this PR can be merged?


Change Medic proceedures to be not spells

Use a different limiting factor other than nanites.

you could combine this with issue # 64 medic class feat too weak.


Reusing value inside the helm values file

Is there way to reuse the variable value in helm values ?
For example, i have domain called example.com and i am using it multiple times inside values files.
is it possible to define a variable called domain: example.com and reuse the variable in value file?

Hi @rasberrypie. Have you had a chance to read through the documentation on values yet?
https://helm.sh/docs/chart_best_practices/values/
https://helm.sh/docs/chart_template_guide/values_files/
Let us know if you have further questions after reading through the docs. Thanks!

Hi @rasberrypie. Have you had a chance to read through the documentation on values yet?
https://helm.sh/docs/chart_best_practices/values/
https://helm.sh/docs/chart_template_guide/values_files/
Let us know if you have further questions after reading through the docs. Thanks!

YAML has a concept known as anchors. I would also suggest looking for more information on how to use anchors to reference other variables.

YAML has a concept known as anchors. I would also suggest looking for more information on how to use anchors to reference other variables.

https://helm.sh/docs/howto/charts_tips_and_tricks/#using-the-tpl-function

If you have the following values.yaml:
domain: example.com
subdomain: "sub.{{ .Values.domain }}"
Then inside your templates you should use
host: {{ tpl .Values.subdomain . }}
tip: don't forget the trailing dot!

@sjoerdvandenbos-prodrive That is fine for your own helm charts but if you are using an upstream helm chart, which is the majority of the use cases, this doesn't work.
I would say the number one problem I find with helm is not being able to pass a value in values.yaml to an upstream chart because the original chart author did not use tpl.


Max Function for Max-Width

Hi, I had a request,
can I add max function to this repository?
div {
    max-width: max(50vw, 300px);
}

to show if document width less than 300px the max width of div be 300px else the max width of div will be 50vw.
Thank you

Hi is this issue still open can you assign to me


haskell.packages.lts-6_7.glib is broken

Tested in NixOS 16.09.
Building glib-<IP_ADDRESS>...
Preprocessing library glib-<IP_ADDRESS>...
In file included from /nix/store/idwrh4bm5s4lnnb03d1j2b2rqg9x42h6-glibc-2.24-dev/include/stdio.h:938:0,
                 from dist/build/System/Glib/StoreValue_hsc_utils.c:3:
/nix/store/idwrh4bm5s4lnnb03d1j2b2rqg9x42h6-glibc-2.24-dev/include/bits/stdio2.h: In function ‘sprintf’:
/nix/store/idwrh4bm5s4lnnb03d1j2b2rqg9x42h6-glibc-2.24-dev/include/bits/stdio2.h:33:10: error: invalid use of ‘__builtin_va_arg_pack ()’
   return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
          ^
/nix/store/idwrh4bm5s4lnnb03d1j2b2rqg9x42h6-glibc-2.24-dev/include/bits/stdio2.h: In function ‘snprintf’:
/nix/store/idwrh4bm5s4lnnb03d1j2b2rqg9x42h6-glibc-2.24-dev/include/bits/stdio2.h:64:10: error: invalid use of ‘__builtin_va_arg_pack ()’
   return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
          ^
/nix/store/idwrh4bm5s4lnnb03d1j2b2rqg9x42h6-glibc-2.24-dev/include/bits/stdio2.h: In function ‘fprintf’:
/nix/store/idwrh4bm5s4lnnb03d1j2b2rqg9x42h6-glibc-2.24-dev/include/bits/stdio2.h:97:10: error: invalid use of ‘__builtin_va_arg_pack ()’
   return __fprintf_chk (__stream, __USE_FORTIFY_LEVEL - 1, __fmt,
          ^
/nix/store/idwrh4bm5s4lnnb03d1j2b2rqg9x42h6-glibc-2.24-dev/include/bits/stdio2.h: In function ‘printf’:
/nix/store/idwrh4bm5s4lnnb03d1j2b2rqg9x42h6-glibc-2.24-dev/include/bits/stdio2.h:104:10: error: invalid use of ‘__builtin_va_arg_pack ()’
   return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack ());
          ^
/nix/store/idwrh4bm5s4lnnb03d1j2b2rqg9x42h6-glibc-2.24-dev/include/bits/stdio2.h: In function ‘dprintf’:
/nix/store/idwrh4bm5s4lnnb03d1j2b2rqg9x42h6-glibc-2.24-dev/include/bits/stdio2.h:141:10: error: invalid use of ‘__builtin_va_arg_pack ()’
   return __dprintf_chk (__fd, __USE_FORTIFY_LEVEL - 1, __fmt,
          ^
compiling dist/build/System/Glib/StoreValue_hsc_utils.c failed (exit code 1)
command was: /nix/store/vkrfglhfmmnk84qidvvxb7pq3wf1mcn2-gcc-wrapper-5.4.0/bin/gcc -c dist/build/System/Glib/StoreValue_hsc_utils.c -o dist/build/System/Glib/StoreValue_hsc_utils.o -fno-stack-protector -D__GLASGOW_HASKELL__=710 -Dlinux_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 -Dlinux_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -Idist/build/autogen -Idist/build -ISystem/Glib -I/nix/store/pircys69fa58vzmkwqxqm7h0jqj0rb6s-glib-2.48.2-dev/include -I/nix/store/mn9kqag3d24v6q41x747zd7n5qnalch7-zlib-1.2.8-dev/include -I/nix/store/5shnxb86qdg44dvbb3mbsvp63jkj4pm5-libffi-3.2.1-dev/include -I/nix/store/idwrh4bm5s4lnnb03d1j2b2rqg9x42h6-glibc-2.24-dev/include -I/nix/store/pircys69fa58vzmkwqxqm7h0jqj0rb6s-glib-2.48.2-dev/include/glib-2.0 -I/nix/store/jjllibpjpidb4r1amgc3q1760f3iwxqk-glib-2.48.2/lib/glib-2.0/include -U__BLOCKS__ -D__attribute__(A)= -DUSE_GCLOSURE_SIGNALS_IMPL -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -I/nix/store/hdfx4k7gmxrxrgxdcs7pc9qr2s83wsab-ghc-7.10.3/lib/ghc-7.10.3/bytes_6VWy06pWzJq9evDvK2d4w6/include -I/nix/store/hdfx4k7gmxrxrgxdcs7pc9qr2s83wsab-ghc-7.10.3/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/include -I/nix/store/xxkh28p76k1z1h3wzjwd5is1b94pwmas-gmp-6.1.1-dev/include -I/nix/store/hdfx4k7gmxrxrgxdcs7pc9qr2s83wsab-ghc-7.10.3/lib/ghc-7.10.3/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I/nix/store/hdfx4k7gmxrxrgxdcs7pc9qr2s83wsab-ghc-7.10.3/lib/ghc-7.10.3/include -I/nix/store/hdfx4k7gmxrxrgxdcs7pc9qr2s83wsab-ghc-7.10.3/lib/ghc-7.10.3/include/
Failed to remove file dist/build/System/Glib/StoreValue_hsc_utils.o; error= dist/build/System/Glib/StoreValue_hsc_utils.o: removeLink: does not exist (No such file or directory)
builder for ‘/nix/store/kilg7zxz35cxkgxws0hnajl9ghd86qfi-glib-<IP_ADDRESS>.drv’ failed with exit code 1
error: build of ‘/nix/store/kilg7zxz35cxkgxws0hnajl9ghd86qfi-glib-<IP_ADDRESS>.drv’ failed

I haven't tested many other versions yet, but LTS 7.0 does work.

I am running into this problem. Does anyone recall what the fix was?


refactor: Only log when dev mode

Blocked until Vite stops replacing process.env.* variables in library mode

Postponed until #213 can be done.


Change to using doubles in XR classes

Change to using doubles in our XR classes. Ran into some issues with GD Extensions but it seems like a sensible change anyway.

@reduz we think we fixed the issue in godot-cpp that breaks floats, but I think we should still make this change. Are you okay with me merging this?

@akien-mga that's a difficult one. Doubles may be overkill in this situation but seeing we're mostly dealing with plugins and with GD extensions plugins convert everything to doubles anyway (well parameters and return values at least) there is little to be gained using floats.
I don't have any solid ideas here, but it seems to me we should be using real_t where there is a definite performance or memory benefit when using float so we can reserve the use of double for high end hardware.

Thanks!

Not sure if we could find a convenient way to document when things are float or double by design, and when they can be configured with real_t.

In terms of doing calculations for XR, real_t makes the most sense. However, if it's easier to bind to GDExtension using doubles then it makes sense to use doubles with those external APIs, especially if it ends up being converted to Variant anyway.


bump xbox stable

RE-CHECK!

Automated adapter checker
ioBroker.xbox

:thumbsup: No errors found
Add comment "RE-CHECK!" to start check anew


Deploy Portfolio to GitHub Pages

Description:
This pull request includes the deployment of my portfolio project to GitHub Pages. The portfolio showcases my skills, projects, and experience, and is now accessible online.
Changes included in this PR:
Deployment of the portfolio project to GitHub Pages.
Update of the README file to include a link to the live demo of the portfolio.
The live version of the portfolio can be accessed at: https://cvilla09.github.io/Portfolio/
Please review and provide any feedback or suggestions. Thank you!

Hello reviewer! 👋

I'm submitting this pull request for the review of my portfolio project, which has now been deployed using GitHub Pages. However, I would like to bring your attention to an issue that I encountered with the webhint linter.
I kindly request your feedback and guidance on how to address these webhint linter errors effectively. If you have any information on how to solve them or any updates from Microverse regarding this issue, it would be greatly appreciated.
Thank you in advance for your time and assistance. I'm looking forward to your valuable feedback! 🙏


[LUIS]  Composite entities are not returned by published model, but children are?

System Information

SDK Language: Node.js
SDK Version:3
Development Environment: localhost

Issue Description
I have several LUIS instances that use composite entities. Occasionally, LUIS will not return any composite entities but it returns their children. Oddly enough, it works while trained, but even if you publish the trained model, it still doesn't return the composite entity itself.
Code Example
None, this is only interfacing LUIS.
Steps to Reproduce the Issue

Build LUIS instance that uses composite entries.
Train LUIS, such that composite entities work on the web debugger.
Publish LUIS, try the composite entity detection.

Expected Behavior
Entities should be tagged appropriately, like in training.
Actual Results
The composite entities are not tagged.

Note that this sometimes works, and sometimes doesn't. For instance, now it works on the published version but not on the trained version.

Can you provide some screen captures of the behavior that you're seeing? Additionally, can you provide the JSON model for your LUIS app?

I can't add the JSON for the Luis model, but here is a screenshot: http://i.imgur.com/DB8nCDL.png
Clearly, it uses the same model for the trained one and the published one (see the times posted).

@MathBunny Your composite entity is supposed to encompass your Security and FixedIncomeSecurityType entities? Just to check via a different route, have you tried plugging in your utterances directly against your LUIS endpoints?

No, the Filter Item (composite) is supposed to encompass the Argument. However, the published model just labels the Argument, but does not show that it's part of the composite. In the trained it does it correctly.

The curly braces around [$Argument ] mean that the Argument entity is wrapped inside of a composite entity. If you press Ctrl+E, you'll be able to shift between the labels. The default label will show the entities except for the composite entities. The first Ctrl+E will show the composite entities only, and the next Ctrl+E will show the tokens (actual words).
If you want to select the view manually, you can access a dropdown menu over the right side of that training window (over the scores). Below is a screencap of what the menu looks like:

The view doesn't matter. I showed you in the screenshot that one shows the entity prediction as being argument and filter, and another is just argument. The published model doesn't show me the composition type.
This isn't a matter of view, I get that, but if you look at the tooltip it clearly outlines the difference.

My problem is that while the trained model and the published model are the exact same, they're returning different results.

My mistake @MathBunny, @DeniseMak do you have any idea why this might be happening?

@MathBunny if you train your model with more utterances eventually the red underline (and tooltip) should go away as the two models (your trained and published model) become more aligned.
As to why the models aren't providing the same predictions when you train and publish the app within the span of a few seconds I can't say. I'll send an inquiry to the LUIS team and see if they've received any previous reports about this issue.

Okay. Shouldn't the trained model and the published model be the exact same? That's the confusing part. Since if someone doesn't change it since it was trained it should return the same results.

Closing this issue and I'll update this thread when I get more info. If you've trained and trained the models but are still running into this problem, feel free to reopen this issue.

@MathBunny can you type into the labeling component (the area when you're inside an intent and entering new utterances) one of the queries that show a difference in prediction in the training screen and provide a screen capture of what the results are?

It works fine in the training screen, it only fails in the testing screen (and when requests are made to it).

Before you used the testing tool, was this utterance already labeled and part of your model?

Yes

More info on this: This happens even if it isn't labelled. Sometimes I have the exact phrase as an utterance in the intent, sometimes not, it doesn't change anything. :/

:/ I'll pass this onto the LUIS dev team and see if we have any answers or need additional information. Sorry about the hassle.

Sorry, I don't have access to the project anymore (it was an internship project). I'll try my best to answer questions though. Thanks!

@MathBunny do you by chance know if your former advisors/bosses might be interested in receiving additional assistance? What could be done is to add someone from the LUIS team as a collaborator to the LUIS app and provide them with the utterances throwing discrepancies. It would allow us to start investigate their app.


Redefine the role of NA

Hi, this is an amazing project! Here is an idea that might go a bit against your new na type, so feel free to close if out of scope.
Vapour might be an opportunity to more precisely define the scope of NA by (only) having it represent unknown values. In R, NA moonlights as a value that signifies absence, much like NULL. I think this is quite unfortunate because the interpretation is very different – a real but unknown value versus one that is known not to exist. For example:
# Real but unknown
c(1, 3, NA, 10)
#> [1]  1  3 NA 10

# Known not to exist
letters[27]
#> [1] NA

Created on 2024-09-16 with reprex v2.1.1
Eliminating the second case would have obvious benefits, but doing so while keeping the first case would also disambiguate the interpretation of NA as an unknown value.
Maybe your na is more like NULL, but I think native representation of unknown values is a great asset of R. It makes sense to model uncertainty about data in the language. However, this requires missing value placeholders to have the same type as the known values in the same (atomic) vector.
Somewhat related to https://github.com/vapourlang/vapour/issues/12 – if NA is part of an atomic vector, it is an unknown value of the same type as that vector. Therefore, if this part is meant to work as in R (which it might not be), an ideal type inference scheme would be orthogonal to a vector containing NA or not.

Thank you for the kind words!
Vapour is very young and will fall short of a lot of things. What you describe there is something I admittedly did not consider.
I don't think a superset of a language could really handle that in the manner you describe but I might be wrong, or I just misunderstand your comment which could be true too.
The first vector you define you defined with
let x: int | na = (1, 3, NA, 10)

The transpile code would work as expected where indeed NAdefines a "known" missing value.
I honestly think the na and null types in Vapour are fine.
However on your second point it is indeed something the language should aim to tackle. Vapour can't prevent such case in the resulting R code but could prevent writing code that results in the error.
The only thing that comes to mind right now would be to define the length (or max length) of a type, like we define "array of size x" in other languages. Vapour could then check that we do not try to access a value outside of the specified range.
It would make for quite a change in the syntax but may be worth it.
This might link to #60 where we'd probably need to generate sensible default values for native types which is doable, e.g.: Go.
However I'm not sure how practical this would be given we rarely know the length of vectors, lists, etc. at build time. When using letters we do but when reading data from a database or elsewhere we seldom do.
If you have any ideas I'm totally open.
Your point raises another problem I had not foreseen though, technically every time we access an item at a certain index we actually expects different types.
E.g.: Vapour will not flag anything wrong with the code below
let x: int = (1, 2, 3)

x = x[4]

But technically every time we access something like this we should expect either NA or NULL
let vec: int = (1, 2, 3)
let vec2: int | na = vec[4]

type lst: list { int | na }

let theList: lst = lst(1, NA , 2)
let theList2: lst | na = theList[4]

With the current type logic and syntax we should write the above and it definitely isn't right.

Thanks for your thoughtful response.
It makes perfect sense that a superset of R might not be the right place to solve the issues I was trying to get at (see below, "More on NA in R") because it will need to accommodate existing R code.
One possible way to sneak in improvements to transpiled R code might be adding attributes and defining their behavior, as in the following. Yet again that might not fit a language superset, it would add runtime overhead, and this particular code is obviously just a rough sketch.
x <- 1:5

# Problematic
x[10]
#> [1] NA

`[.vapour_object` <- function(x, index) {
    if (is.numeric(index) && index > length(x)) {
        stop(paste0(
            "Index out of bounds. The index is ",
            index,
            " but the object to be subset only has length ",
            length(x),
            "."
        ))
    }
}

x <- structure(1:5, class = c("vapour_object", "integer"))

# Better
x[10]
#> Error in `[.vapour_object`(x, 10): Index out of bounds. The index is 10 but the object to be subset only has length 5.

# Equivalent to the above definition of `x`
x <- 1:5
class(x) <- c("vapour_object", class(x))

x[10]
#> Error in `[.vapour_object`(x, 10): Index out of bounds. The index is 10 but the object to be subset only has length 5.

Created on 2024-09-17 with reprex v2.1.1
More on NA in R
To clarify, I thought it would be ideal for a language like R to use NA only as an "explicit missing value", as in c(1, 3, NA, 10), and not as a nullish value, as returned by letters[27]. The first case is an unknown presence (we don't know which number NA conceptually represents), but the second is a known absence (we do know that there is no 27th letter).
Some languages complain at runtime that something is amiss when indexing out of bounds. Python throws an error, and Rust panics. I think this kind of behavior is better per se because it's much more safe and clear. Subsequent code might not be prepared to handle NA.
However, using NA as a return value of letters[27] is arguably even worse than using NULL would be instead because it creates needless ambiguity when encountering NA: is it an empirically unknown value because, e.g., we could not measure the third value in the series of tests represented by c(1, 3, NA, 10); or is it the result of a programming issue like indexing out of bounds?
As I understand your example with int | na, Vapour defines na as an alternative to the other types. Yet what is great about NA in R is that it is baked into the definition of all the basic atomic vector types. For example, any logical value could be TRUE, FALSE, or NA. This type actually implements Kleene's three-valued logic, so NA is inherent in the type definition.
Note that the type is called "logical", not "Boolean"; it never implemented two-valued logic to begin with, and there is no separate Boolean type. The inherence of NA enables users to encode a lack of knowledge about certain values – the main purpose of NA.

Apologies if I expressed myself poorly but I understood your point originally, I understand the distinction between NULL and NA.
I think @jonocarroll nails it in #67, NA essentially should not be a type, it's a just value that should be accepted in many places. Indeed in R it isn't a type come to think of it, it's a value of a type: NA_character_, NA_integer_, ... Not confident if this is what Jonathan says or my interpretation, feel free to correct me :)
null though should probably remain a type.

@jonocarroll If (1:3)[4] silently returns NA, this can easily lead to problems at runtime. I think throwing an error or a warning would be more desirable in principle, but it's unclear whether a superset of R is the right place for introducing this.
Entirely agree that an option type would be awesome!

But type-wise it's correct. I suspect it's impossible to introduce a BoundsError at the Vapour level because of runtime things like
x <- 1:10
y <- read.csv("data.csv")
z <- x[nrow(y)]

Type-wise, all of that checks out, but whether or not the external data has a sufficient number of rows is extremely runtime-dependent.


Minor Typing error: bodyFrameRef to bofyFrameRef

It's so minor, but wanted to let you know.

I think this repository is sadly no longer maintained.


refactor(VNode): use symbol instead of _isVNode key

Just as #114, but for VNode. Use a new Symbol as _isVNode value. I can make such changes for e.g. _isVue too if it's needed.

Using conditional expression converts the unique symbol to a symbol. I guess you can revert the name change.

@znck what do you mean by name change?

ahh, I see, that broke everything

Using symbols for object type detection is definitely more robust but it introduces unnecessary cross-package dependencies. One solve, I see is to create a package for these symbols.
Let’s wait for inputs from Evan.

@yyx990803 could you please take another look on this? We can move that symbol to @vue/shared package to avoid cross-imports. Sorry for taking your time.

@sh7dm code in @vue/shared are inlined into final builds and thus the symbol is not guaranteed to be unique anymore.

okay, thank you for explaining!

@yyx990803 I discovered that there's a Symbol.for function, which could help us with global symbols. What do you think about it?

Symbol.for doesn't provide the same level of encapsulation as normal Symbols. Suppose we use Symbol.for('isVNode'), then the user can do this:
const myVNode = {
  [Symbol.for('isVNode')]: true
}

So it's not fundamentally different from _isVNode: true.

Prefixing serces that purpose: Symbol.for('Vue.isVNode') will resolve that problem

in production we don't name the symbols.
In my opinion there's not much benefit of using symbols in _isVNode since the reason of using Symbol is to prevent access to the property, something the Symbol.for('isVNode') won't do it.


Combine initial and subsequent templates

It should no longer be needed to create two templates for an API.

Any update on this? I'm having trouble deploying versions. This is because the path property is defined in both initial and subsequent templates. Therefore I cannot deploy two or more versions with the same path/suffix. It fails with the following error: API with specified URL path '' already exists.. I tried deploying just the subsequent templates and that worked.

Believe this to be fixed.  If you are still having trouble deploying multiple versions because of the same suffix, please open a new issue with the required information.


Website

The HLS file option on de main website refers to http://www.streambox.fr/playlists/test_001/stream.m3u8

Non https:// so loading will always fail
404 link so the video will not work.

Following are open and available test tag:
https://bitdash-a.akamaihd.net/content/MI201109210084_1/m3u8s/f08e80da-bf1d-4e3d-8899-f0f6155f6efa.m3u8
https://bitdash-a.akamaihd.net/content/sintel/hls/playlist.m3u8
https://mnmedias.api.telequebec.tv/m3u8/29880.m3u8
See..
Dash script is also using https:// instead of https://

@jaapmarcus sorry but your explanations look a little bit confused ..
and url http://www.streambox.fr/playlists/test_001/stream.m3u8  gives a 404 .

https://www.mediaelementjs.com
Is running https:// so  all non https:// links will fail due to security reasons..
The main page need a few edit mainly checked if all extrenal media sources are still working.

url http://www.streambox.fr/playlists/test_001/stream.m3u8 gives a 404 .

True also due to reason explained above it will also not work due to ssl restrictions.

hmm oki ! let's put @johndyer in the loop :)

I think John just fixed it

Failed to load resource: The certificate for this server is invalid. You might be connecting to a server that is pretending to be “www.streambox.fr”, which could put your confidential information at risk.
https://www.streambox.fr/playlists/test_001/stream.m3u8 has invalid SSL certificate this on need to be replaced with one of the examples given below..
https://bitdash-a.akamaihd.net/content/MI201109210084_1/m3u8s/f08e80da-bf1d-4e3d-8899-f0f6155f6efa.m3u8
https://bitdash-a.akamaihd.net/content/sintel/hls/playlist.m3u8
https://mnmedias.api.telequebec.tv/m3u8/29880.m3u8

@jaapmarcus John updated https://github.com/mediaelement/mediaelement/blob/gh-pages/index.html, please confirm that it's fixed

Yes it working HLS is working fine.
However
MP4and

Returns an 404
don't know why because
https://github.com/mediaelement/mediaelement/tree/gh-pages/dist Does exists

There seems to be a bug with in 4.2.7 updating the player to 4.2.14 solves the issue.
4.2.7 gives the following error
Unhandled Promise Rejection: TypeError: m.getDebug().setLogToBrowserConsole is not a function. (In 'm.getDebug().setLogToBrowserConsole(t.dash.debug)', 'm.getDebug().setLogToBrowserConsole' is undefined)
4.2.14 gives none...

There seems to be a bug with in 4.2.7 updating the player to 4.2.14 solves the issue.
4.2.7 gives the following error
Unhandled Promise Rejection: TypeError: m.getDebug().setLogToBrowserConsole is not a function. (In 'm.getDebug().setLogToBrowserConsole(t.dash.debug)', 'm.getDebug().setLogToBrowserConsole' is undefined)
4.2.14 gives none...

https://github.com/mediaelement/mediaelement/commit/77938cb5a79fbb0797ee03db17bb02af3aupgraded to 4.2.14 e47b92  :-)

Yeah why not upgrade it...

Hi @jaapmarcus  this error still exists even right now, I tested ur demo on front page and tested mine
i get the same error

Media elements player js version : 4.2.15

Test page work over here fine with the use of Android


ngInfiniteScroll can't be used in ng-view

I'm using $routeProvider to change between 2 views and it seems that ngInfiniteScrol placed in templateUrl do not get executed.
Is it possible to use it in the html file that will be used as templateUrl ?

I just tried to add this to my app and noticed the same thing...
In my template:
<div class="row searchResultsContainer" ng-hide="oc.orgList.results.length == 0" infinite-scroll="getMyStuff()">
In my controller:
`getMyStuff(): void {
const that: OrgController = this;
this.$rootScope.loading = true;
    that.itemsPromise = this.orgService.loadOrgList(this.$rootScope.search.text, this.$scope.gridOptions.currentPage, this.$scope.gridOptions.pageItems)
        .then((paginatedResults: PaginatedResults<IOrg>) => {
            for (var i = 0; i < paginatedResults.pageSize; i++) {
                that.orgList.results.push(paginatedResults[i].data);
            }
            that.$rootScope.loading = false;
            this.$scope.gridOptions.currentPage++;
        }
        );
}`

When I scroll the page, it doesnt hit my breakpoint at all. :(


build github.com/fiatjaf/satdress: cannot find module for path embed

After:
debian@merak-4:~/bin/satdress$ go build
Error:
build github.com/fiatjaf/satdress: cannot find module for path embed
From:
package main

import (
	"crypto/hmac"
	"crypto/sha256"
	_ "embed"
	"encoding/hex"
	"encoding/json"

Any tips?

when I try to build I get this error:
build github.com/fiatjaf/satdress: cannot load embed: malformed module path "embed": missing dot in first path element

You need Go version 1.16.


publish<EMAIL_ADDRESS>

Requested by: @buenaflor
Merge target: (default)
Quick links:

View changes
View check runs

Assign the accepted label to this issue to approve the release.
Leave a comment containing #retract under this issue to retract the release (original issuer only).
Targets

[ ] pub-dev
[ ] github
[ ] registry

Targets marked with a checkbox have already been executed.  Administrators can manually tick a checkbox to force craft to skip it.

Note: do not approve just now, this is scheduled to be released on Monday


Filtering Attributes not working

Anyone else having the issue with the "when a row is modified" select attributes
Even though I have it populated with the field I want to trigger it on, it still runs for other instances

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

ID: 94c84a31-4f63-6ee1-ad15-096cae44cb41
Version Independent ID: de8cf5bc-b78b-a88e-696f-7755e3ce22f0
Content: Trigger flows when a row is added, modified, or deleted - Power Automate
Content Source: articles/dataverse/create-update-delete-trigger.md
Service: power-automate
GitHub Login: @MSFTMan
Microsoft Alias: Deonhe

Is the column specified in select filter being updated when the row is being created or modified? To check this, you can enable auditing for the record and confirm if the specific column is in the request. Currently the trigger will run anytime the selected column is included in a create/modify request, even if the value has not changed.

@DavidMendes94 per the response from @radioblazer, this is a know issue. The product team is aware of it and is evaluating how to address it. Thank you.

Has this issue been resolved as yet. I am trying the same thing myself. Trying to generate an email when a custom field is set to a value. Tried several things but the error is still displaying


Improve tap detection

Improves the algorithm by checking for a moment of low acceleration before allowing another tap to be registered. It also fixes a logic bug and gives a config option to allow IMUs with a faulty accelerometer but a good gyro to not break this feature.
edit: also fixes a bug with Vive emulation not saving and allows for up to ten taps to be the quantity before a reset

nya_a conflict plz resolve 🥺

Don't merge it yet its still acting strange


Download button does not do anything until PDF is fully-loaded

For the longest time I thought this was some sort of magically-disappearing unreproducible bug, where I'd have to click several times on the download arrow to get the embedded PDFs on Blackboard.com (my university lecture notes) to actually bring up Firefox's download prompt.
Now, though, I realise it's just that the button will do nothing until the PDF has finished downloading. It would be more helpful if it either worked immediately, or the button was greyed out/replaced with a spinner until the document finished loading.

This is strange, because technically it should have been fixed some time ago by PR #4455, but I'm still able reproduce it with version 1.2.131 of the addon.
I'm wondering if that patch is missing some of the necessary machinery in PdfStreamConverter.jsm (or perhaps firefoxcom.js), in order for this to work correctly!?

I'm also able to reproduce this. I agree that this has worked before, so it must have regressed somewhere.

This behaviour in the addon/built-in version, where the download button appears unresponsive until the file has finished loading, is caused by using asyncFetchChannel. That function relies on NetUtil.fetchAsync, which according to the docs won't run the callback until the channel has finished loading.
The dependency on NetUtil.asyncFetch was added in PR #1786, which I suppose is where this broke.
After doing some quick testing, it seems to me that a simple solution would be to not use asyncFetchChannel when the download method (in PdfStreamConverter) is called without passing in a blobUrl, and rather just trigger the download directly then.
/cc @brendandahl, @yurydelendik Does the above sound like an acceptable solution to you?

See also: https://bugzilla.mozilla.org/show_bug.cgi?id=920702

I've tried implementing the suggestion in https://github.com/mozilla/pdf.js/issues/6660#issuecomment-199234593 (see https://gist.github.com/Snuffleupagus/e6ef3303439c10d52968), and in some quick testing it does appear to work.
I'm not sure if that is close enough to a proper solution to warrant a PR though, since my knowledge of the addon code isn't that great.
Another way to "solve" this issue could also be, as suggested above, to disable the download button until loading is complete. But that might not be a much better UX than the current behaviour though.

Given that all of the relevant code now lives in mozilla-central, let's close this as a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=920702

Maybe you should link this issue on the bugzilla, so that people can see the comments here about what the problem may be?


Simplify TemplatesPanel to use a single associated list

Rather than have two lists -- and risk their indexes go out of sync -- use a single list of tuples. That way, the key/values can never go out of sync.

I have rebased to resolve merge conflicts.

Makes sense. I'm a bit hesitant here since performance and code stability has been problematic in this area, but let's merge this and see. It might even improve performance since it only seems to scan the list of seen layers once.


Enabling arm support

Enable ARM support
Changes proposed in this pull request:

This PR enables support to ARM/v7, ARM64 architecture.
Fix https://github.com/goofball222/unifi/issues/20
Adopts Moby/BuildKit to enable multi-architecture OCI image building.
Enables automatic building by using GitHub Actions.

This fix only works with the Debian image since the Linux Alpine image uses a multi-stage build that takes as a source an amd64 image. I'd time I will send another PR fixing that and adding more tests (Linters basically) to the different Dockerfiles.
@goofball222

Handled via GitHub action builds.
Debian image: linux/amd64
Alpine image: linux/amd64, linux/arm64, linux/arm/v7
Ubuntu image: linux/amd64,linux/arm64
Limited by MongoDB packages on what architectures are available for Debian and Ubuntu.


perf: Change return type of custom protocol handler from Vec<u8> to Cow<'static, [u8]>, closes #796

What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Docs
[ ] New Binding issue #___
[ ] Code style update
[ ] Refactor
[ ] Build-related changes
[ ] Other, please describe:

Does this PR introduce a breaking change?

[ ] Yes, and the changes were approved in issue #796
[ ] No

Checklist

[x] When resolving issues, they are referenced in the PR's title (e.g fix: remove a typo, closes #___, #___)
[x] A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.
[x] I have added a convincing reason for adding this feature, if necessary

Other information
I confirmed this change using the custom protocol example on the following platforms:

Windows 10
macOS 11.7
Ubuntu 22.04

I don't have Android and iOS development environment so I could not confirm this patch on it.

for android, you can just install rustup target add aarch64-linux-android and then run cargo check --target aarch64-linux-android to make sure it compiles fine.

for android, you can just install rustup target add aarch64-linux-android and then run cargo check --target aarch64-linux-android to make sure it compiles fine.

Ah, I didn't know that checking non-host target is so easy with cargo. Thank you. I'll check the compile errors and your review points tonight.

@amrbashir I fixed Android build and resolved review comments. I apologize that I could not take time to work on this yesterday.


Picocli

Better mix of features and better for testing graal nativeImage

./okcurl --completionScript "a" will generate a bash tab completion script

@swankjesse Thoughts on this?  It mainly helps as a testbed for confirming graal compatibility for OkHttp.  That is useful for me, I ended up porting a CLI client to python requests and I'd prefer to stay within a single codebase.


[Patcher] Update gruntwork-io/terraform-aws-service-catalog/networking/vpc

Updated the gruntwork-io/terraform-aws-service-catalog/networking/vpc dependency using Patcher.
Update summary
successful_updates:
    - file_path: /Users/marina/go/src/github.com/gruntwork-io/patcher-action/infrastructure-live/dev/eu-central-1/networking/vpc/terragrunt.hcl
      updated_modules:
        - repo: terraform-aws-service-catalog
          module: networking/vpc
          previous_version: v0.95.0
          updated_version: v0.95.1
          patches_applied:
            count: 0

Testing PR from #3. Closing it!


Design Proposal: support HSM with attestation for ca issuer and self signed issuer

Preview: https://github.com/irisdingbj/cert-manager/blob/hsm/design/20210823.hsm.md

@JoshVanL Thanks for the review comments! We want to enhance two kinds of issuers for cert-manager: CA and SelfSigned. So it is not a new kind of issuers. The HSM crd and controller proposed in this proposal is used to bootstrap the whole HSM environment and will be used in our enhanced SelfSigned issuer and CA issuers.  Let's talk about how these two issuers will be enhanced one by one.

SelfSigned issuer:

This issuer can be used to bootstrap a CA issuer actually. So admin can create a SelftSigned Issuer and a Certificate. With these two custom resources, a Secret will be created which holds private key and cert.  CA issuer can then use this secret to sign certs for users.
In this case, the private key is saved in clear text in the secret -- this is the area we want to enhance:
KeyManager controller will be enhanced to generate private key from HSM and save key handler info into the temp secret.
RequestManager controller will be enhanced to retrive private via key handler info from HSM and sign cert.
Issuing controller will be enhanved to save private key handler info into secret.
For CA issuers:
This isser needs to  reference a secret which hold private key and cert and sign the incoming certificateSigningRequest back.  It will be enhanced to support retrive private key via handler info as the private key will be saved into HSM.
An annotation  cert-manager.io/hsm :true will used as an indicator to tell our CA issuers and self signed issuers whether we will generate/save/retrieve private keys via HSM. This makes sure no influence if no HSM controller and cr defined for our original workflow.

/cc @kailun-qin

/cc @kailun-qin

@irisdingbj, a HSM Issuer is fundamentally different to how the SelfSigned and CA Issuers work, and as such, should be different resource types.

This issuer can be used to bootstrap a CA issuer actually. So admin can create a SelftSigned Issuer and a Certificate. With these two custom resources, a Secret will be created which holds private key and cert. CA issuer can then use this secret to sign certs for users.

This can be done with a new HSMBootstrap type resource. This operation is different to what the selfisigned issuer does which is self sign a CertificateRequest using a private key that is stored in a Secret. We should not overload the design of that Issuer.
Is using a Certificate resource even required here for bootstrapping a HSM?

In this case, the private key is saved in clear text in the secret -- this is the area we want to enhance:
KeyManager controller will be enhanced to generate private key from HSM and save key handler info into the temp secret.
RequestManager controller will be enhanced to retrive private via key handler info from HSM and sign cert.
Issuing controller will be enhanved to save private key handler info into secret

Whilst we could decide what the design would be and decide if we want to merge this functionality to core in future, this can do done out of tree today. A separate bootstrap resource would not need to touch the Certificate flow, and is not clear to me why the Certificate resource is required here.

This isser needs to reference a secret which hold private key and cert and sign the incoming certificateSigningRequest back. It will be enhanced to support retrive private key via handler info as the private key will be saved into HSM.
An annotation cert-manager.io/hsm :true will used as an indicator to tell our CA issuers and self signed issuers whether we will generate/save/retrieve private keys via HSM. This makes sure no influence if no HSM controller and cr defined for our original workflow.

This can be done as a separate external Issuer :slightly_smiling_face:

As mentioned, the cert-manager project isn't taking any more Issuers at this time and instead gives support for developers to create their own external issuers. Can I suggest taking a look at the other external issuer implementations for some prior art? Google-CAS is one which has been developed recently and is successfully used.

@JoshVanL @jakexks @SgtCoDFish @maelvls and other cert-manager devs, we updated the proposal a little bit according to our discussion last time. PTAL, Thanks!

Thanks @irisdingbj for updating the proposal with the diagram :smile:
Taking a look, I am becoming more convinced that there is nothing here that can't be done via the external issuer mechanism.
For the optional HSM "bootstrap" part, a separate CRD can be used, rather than a CertificateRequest:
apiVersion: cert-manager.intel.com/v1alpha1
kind: HSMCABootstrap
metadata:
  name: my-ca
spec:
  pkcs11: "token=....."
  commonName: "foo.example.com"
....
  secretName: my-ca-key-handler

apiVersion: v1
kind: Secret
metadata:
  name: my-ca
  namespace: cert-manager
data:
  hsm-key-handler: key-handler-info

The actual external issuer which would use a key handler reference would look like:
apiVersion: cert-manager.intel.com/v1alpha1
kind: HSM
metadata:
  name: my-ca
spec:
  keyHandler:
    name: my-ca
    key: hsm-key-handler

A request would then look like:
apiVersion: cert-manager.io/v1
kind: CertificateRequest
metadata:
  name: my-request
  namespace: sandbox
spec:
  request: xxx
  issuerRef:
    name: my-ca
    kind: HSM
    group: cert-manager.intel.com

This design document was not accepted because, like @JoshVanL explained, this functionality can be implemented by using our external-issuer mechanism. Changing the in-tree issuers will add too much complexity to these issuers.
More info about external issuers: https://cert-manager.io/docs/configuration/external/

@irisdingbj - Have you tried this approach? I'm in the same situation and wondering if HSM using the external-issuer worked for you.

Thanks @irisdingbj for updating the proposal with the diagram 😄
Taking a look, I am becoming more convinced that there is nothing here that can't be done via the external issuer mechanism.
For the optional HSM "bootstrap" part, a separate CRD can be used, rather than a CertificateRequest:
apiVersion: cert-manager.intel.com/v1alpha1
kind: HSMCABootstrap
metadata:
  name: my-ca
spec:
  pkcs11: "token=....."
  commonName: "foo.example.com"
....
  secretName: my-ca-key-handler

apiVersion: v1
kind: Secret
metadata:
  name: my-ca
  namespace: cert-manager
data:
  hsm-key-handler: key-handler-info

The actual external issuer which would use a key handler reference would look like:
apiVersion: cert-manager.intel.com/v1alpha1
kind: HSM
metadata:
  name: my-ca
spec:
  keyHandler:
    name: my-ca
    key: hsm-key-handler

A request would then look like:
apiVersion: cert-manager.io/v1
kind: CertificateRequest
metadata:
  name: my-request
  namespace: sandbox
spec:
  request: xxx
  issuerRef:
    name: my-ca
    kind: HSM
    group: cert-manager.intel.com

@irisdingbj - Have you tried this approach? I'm in the same situation and wondering if HSM using the external-issuer worked for you.

Thanks @irisdingbj for updating the proposal with the diagram 😄
Taking a look, I am becoming more convinced that there is nothing here that can't be done via the external issuer mechanism.
For the optional HSM "bootstrap" part, a separate CRD can be used, rather than a CertificateRequest:
apiVersion: cert-manager.intel.com/v1alpha1
kind: HSMCABootstrap
metadata:
  name: my-ca
spec:
  pkcs11: "token=....."
  commonName: "foo.example.com"
....
  secretName: my-ca-key-handler

apiVersion: v1
kind: Secret
metadata:
  name: my-ca
  namespace: cert-manager
data:
  hsm-key-handler: key-handler-info

The actual external issuer which would use a key handler reference would look like:
apiVersion: cert-manager.intel.com/v1alpha1
kind: HSM
metadata:
  name: my-ca
spec:
  keyHandler:
    name: my-ca
    key: hsm-key-handler

A request would then look like:
apiVersion: cert-manager.io/v1
kind: CertificateRequest
metadata:
  name: my-request
  namespace: sandbox
spec:
  request: xxx
  issuerRef:
    name: my-ca
    kind: HSM
    group: cert-manager.intel.com

Yep, we have already implemented as an external issuer, you can check details in https://github.com/intel/trusted-certificate-issuer.


Request: Make label: false remove the entire legend element for collections

Based off my StackOverflow: https://stackoverflow.com/questions/56728460/how-do-i-hide-the-form-title-that-appears-inside-a-legend-tag-when-generating-ch
The behavior I'd like: for label: false to completely remove the legend element. label: '' correctly sets the text to an empty string but it leaves behind the legend element, which has padding. Unless there's syntax I don't know about, label: false removing the legend element seems like natural and useful behavior.

Poking around I found that using legend_tag: false does the job, probably missing documentation.

In the principle of least surprise I would expect the same to happen when using label: false, maybe we can do a translation of that or if that's not what we want, at least a warning/error when using label: false when using f.association.

legend_tag: false works but still it is missing in the documentation.

hey guys I just found this and its still nowhere to be found in the documentation lol
sorry to necro


[suggestion] locate/locatebiome

For locate/locatebiome.

Wonderful mod!
I'm playing 1.16.5 and I think that's necessary.

It should already work for the locate command? It definitely did last I tried it...

Weird, suddenly locatebiome can work, but locate still can't be used.


GitHub action messing up on the weirdest error when trying to publish

Tests work as intended, but for some reason publishing doesn't and I've done a bunch of tries.

Created a discussion: https://github.com/orgs/community/discussions/118669


[WIP] FIX: set keras style to False

Closes #203
Though I don't think this is the right thing to do from my understanding of keras_style:
https://www.tensorflow.org/api_docs/python/tf/layers/experimental/keras_style_scope

I don't think that's the correct fix. Basically the change in https://github.com/tensorflow/tensorflow/commit/9df99aafc3480638cd8d2bf6a0caeab111b68302 is trying to prevent build() to contain any logic of actual tensor calculation, which should happen within call().
IMHO, the right fix is to move those tensor ops to call() instead of putting them in build().

By looking at the implementation of WeightNormalization, i feel the implementation is quite anti-pattern, eg the wrapper will adding/editing the weights for the wrapped layer, I feel those created/updated weights should just tie to wrapper itself.
I will try to do fix for this today.