Predict for video with long playback time

Here is what happened.
When predicting a large capacity video, RAM usage reaches 100% and the vscode window is broken.
Here is my environment.

OS : Windows11
RAM : 64GB
GPU : RTX3080
vscode : 1.78.1
python : 3.9.13
super-gradient : 3.1.0
pytorch : 1.13.1+cu117

Video information generated.

size : 2.22GB
frame-width : 3840
frame-height : 2160
Replay time : 00:01:57
fps : 60

I expect it is caused by too much cache in memory.
In YOLOv8, there is a workaround. Example YOLOv8
Is there a workaround in YOLO-NAS
I often use videos with long playback times, so I would very much like to know a workaround!
It's part of my code.

Hi @momonoki3nenn ,
This is a feature that is in our backlog, but meanwhile, you will have to load/write the video manually.
Here is a script that should do the job until it is added to SG.
def process_video(input_file: str, output_file: str, batch_size: int) -> None:
    # Initialize video capture object
    cap = cv2.VideoCapture(input_file)

    # Get video properties
    fps = cap.get(cv2.CAP_PROP_FPS)
    frame_width = int(cap.get(cv2.CAP_PROP_FRAME_WIDTH))
    frame_height = int(cap.get(cv2.CAP_PROP_FRAME_HEIGHT))

    # Create video writer object
    fourcc = cv2.VideoWriter_fourcc(*'mp4v')
    out = cv2.VideoWriter(output_file, fourcc, fps, (frame_width, frame_height))

    while True:

        # Load frames by batch to increase performance
        frames = []
        for _ in range(batch_size):
            ret, frame = cap.read()
            if not ret:
                break
            frames.append(frame)

        if not frames:
            break

        frames_predictions = model.predict(frames)

        for frame_prediction in frames_predictions:
            out.write(frame_prediction.draw())

    # Release video capture and writer objects
    cap.release()
    out.release()

Make sure to set batch_size high enough to increase inference speed. Hoping this helps.

We have implemented memory-efficient predict for video in super-gradients 3.5.0.
So you are welcome to upgrade to a new version of SG which should not have this issue.


feat(method): support method in definition

What this PR does / why we need it:
In the past, definition.Function only support functions. With method package in this pr, you can get the power to make a method be like a function.
// Before nirvana server starting
instance := InitSomeClass()
method.Put(instance)

// In definition:
{
    ...
    Function: method.Get(&SomeClass{}, "SomeMethod"),
    ...
}

Then you don't need to do this:
func (* SomeClass) Definitions()[]definition.Definition {
    return []definition.Definition {
        ...
        Function: this.SomeMethod,
        ...
    }
}

Which issue(s) this PR is related to (optional, link to 3rd issue(s)):
Fixes #
Reference to #

Special notes for your reviewer:
/cc @ddysher

Release note:

NONE

@kdada few comments:

we are constructing a struct instance when registering the function method, what is the implication behind this, i.e.

what if user wants to instantiate the struct with field value, e.g. Function: method.Get(&SomeClass{Some: 'abc'}, "SomeMethod"),, is this a valid use case?
what happens to the object (&SomeClass{}) after registration?
what if user wants to create another instance, do we want them to reuse the object?

you seems to use MakeFunction to wrap the registered function, what is the performance penalty?

It's common to register multiple methods of a class, in current setup, users are supposed to do this multiple times, each time with a new instance of the object?
{
    ...
    Function: method.Get(&SomeClass{}, "SomeMethod1"),
    Function: method.Get(&SomeClass{}, "SomeMethod2"),
    Function: method.Get(&SomeClass{}, "SomeMethod2"),
    ...
}

:point_up_2: @kdada can u provide some pprof results (esp. memory for objects)?  that will make me feel better ...

@ddysher
The method package provides a pattern to Get and Put instances.
 The function has a certain function prototype and an indefinite execution body. Related instance of the function won't be set until someone calls the function. This mechanism ensure that we can separate API definitions and instances.
The first parameter of Get is only for extracting instance type. So a filled object makes no sense.
Put is simple. The method just put an instance into method container. But for a type, there only one instance is valid. That means if you Put many instances with same type, only the last one is used.
Benchmark:
BenchmarkContainer-8     3000000               406 ns/op
BenchmarkDirect-8       10000000               222 ns/op

Function warp has twice consumption than direct call. But it isn't a big deal. Because the overhead of an entire API request is in microsecond.  (PS. I'll write an unsafe calling package to skip the safe check of reflect packge. )

/lgtm

/approve


datetime editor limits

hi all,
Is there a way to allow datetime to be selectable for a given range? For example, I want to ensure only 2 weeks can be selected on the datetime UI.
Many thanks all!

Hi,
Have you tried :
SqlMinMax
https://github.com/volkanceylan/Serenity/wiki/Editors:-Editor-Types

thank you! No idea how I even missed that.


Error when a D project is opened as the root

If you open this repo, fixtures is a sub-folder and it works, but if you open a D project as the root of the project it errors for strange reasons.

stderr 2021-02-24T14:42:44.733 [trace] source\served\extension.d:773:doStartup Started files provider for root RootSuggestion("C:\\Users\\aminy\\Documents\\GitHub\\JavaScript\\atom-ide-d\\spec\\fixtures\\", true)

source\served\extension.d:697:doStartup Initializing instance for root RootSuggestion("C:\\Users\\aminy\\Documents\\GitHub\\JavaScript\\atom-ide-d\\spec\\fixtures", true)

object.Exception@..\..\..\..\AppData\Local\dub\packages\workspace-d-3.6.0-pre.8\workspace-d\source\workspaced\backend.d(564): Instance with cwd 'C:\\Users\\aminy\\Documents\\GitHub\\JavaScript\\atom-ide-d\\spec\\fixtures' already exists!

"[progress] [00001.209] [workspaceStartup] 1 / 2: file:///C%3A/Users/aminy/Documents/GitHub/JavaScript/atom-ide-d/spec/fixtures"

stderr 0x00007FF7DD2F2495 in workspaced.backend.WorkspaceD.addInstance at C:\Users\aminy\AppData\Local\dub\packages\workspace-d-3.6.0-pre.8\workspace-d\source\workspaced\backend.d(565)

stderr 0x00007FF7DD0C35E4 in served.extension.doStartup at C:\Users\aminy\Documents\GitHub\D\serve-d\source\served\extension.d(711)

stderr 0x00007FF7DD0C1127 in served.extension.changedConfig at C:\Users\aminy\Documents\GitHub\D\serve-d\source\served\extension.d(124)

@WebFreak001 Any idea about this?

is the LSP sending didChangeWorkspaceFolders before config changes like at startup? It seems it registers the same folder twice.

ah the issue might actually be that there is a trailing /

I pushed some changes to serve-d, try building them from source to see if that fixes the issue.

Nothing changed.
stderr 2021-02-24T15:08:22.646 [info] source\served\extension.d:667:rootsForProject Root Suggestions: [RootSuggestion("C:\\Users\\aminy\\Documents\\GitHub\\JavaScript\\atom-ide-d\\spec\\fixtures\\", true), RootSuggestion("C:\\Users\\aminy\\Documents\\GitHub\\JavaScript\\atom-ide-d\\spec\\fixtures", true)]

stderr 2021-02-24T15:08:22.785 [info] source\served\extension.d:701:doStartup Initializing instance for root RootSuggestion("C:\\Users\\aminy\\Documents\\GitHub\\JavaScript\\atom-ide-d\\spec\\fixtures", true)

stderr object.Exception@..\..\..\..\AppData\Local\dub\packages\workspace-d-3.6.0-pre.8\workspace-d\source\workspaced\backend.d(564): Instance with cwd 'C:\Users\aminy\Documents\GitHub\JavaScript\atom-ide-d\spec\fixtures' already exists!

When you spawn serve-d, what should be the cwd?

I also get this error when I open serve-d project itself. The limit seems to be set very low by default.

sorry, I forgot Windows uses \ as path separator, try again with master now.

the manyProjectsThreshold needs to be improved on serve-d side anyway as there is lazy loading now, which means it should only complain once you loaded that many projects.

Unfortunately, the error still happens. The log has changed:
[trace] source\served\extension.d:534:doGlobalStartup Starting dlangui

logger.ts:19 D (serve-d) stderr 2021-02-24T15:17:55.500 [trace] source\served\extension.d:536:doGlobalStartup Starting importer

logger.ts:19 D (serve-d) stderr 2021-02-24T15:17:55.500 [trace] source\served\extension.d:538:doGlobalStartup Starting moduleman

logger.ts:19 D (serve-d) stderr 2021-02-24T15:17:55.500 [trace] source\served\extension.d:540:doGlobalStartup Starting snippets

logger.ts:19 D (serve-d) stderr 2021-02-24T15:17:55.501 [trace] source\served\extension.d:681:doStartup Initializing serve-d for file:///C:/Users/aminy/Documents/GitHub/JavaScript/atom-ide-d/spec/fixtures/

logger.ts:19 D (serve-d) stderr 2021-02-24T15:17:55.502 [info] source\served\extension.d:667:rootsForProject Root Suggestions: [RootSuggestion("C:\\Users\\aminy\\Documents\\GitHub\\JavaScript\\atom-ide-d\\spec\\fixtures\\", true), RootSuggestion("C:\\Users\\aminy\\Documents\\GitHub\\JavaScript\\atom-ide-d\\spec\\fixtures", true)]

logger.ts:19 D (serve-d) stderr 2021-02-24T15:17:55.502 [info] source\served\extension.d:701:doStartup Initializing instance for root RootSuggestion("C:\\Users\\aminy\\Documents\\GitHub\\JavaScript\\atom-ide-d\\spec\\fixtures\\", true)

logger.ts:19 D (serve-d) stderr 2021-02-24T15:17:55.502 [trace] source\served\types.d:565:activeInstance Setting active instance to C:\Users\aminy\Documents\GitHub\JavaScript\atom-ide-d\spec\fixtures.

logger.ts:19 D (serve-d) stderr 2021-02-24T15:17:55.502 [trace] source\served\extension.d:728:doStartup Starting dub...

logger.ts:19 D (serve-d) stderr 2021-02-24T15:17:55.642 [trace] source\served\extension.d:750:doStartup Started dub with root dependencies []

logger.ts:19 D (serve-d) stderr 2021-02-24T15:17:55.642 [trace] source\served\extension.d:777:doStartup Started files provider for root RootSuggestion("C:\\Users\\aminy\\Documents\\GitHub\\JavaScript\\atom-ide-d\\spec\\fixtures\\", true)

logger.ts:19 D (serve-d) stderr 2021-02-24T15:17:55.642 [trace] source\served\extension.d:779:doStartup Loaded Components for C:\Users\aminy\Documents\GitHub\JavaScript\atom-ide-d\spec\fixtures: ["dub"]

logger.ts:19 D (serve-d) stderr 2021-02-24T15:17:55.642 [info] source\served\extension.d

logger.ts:19 D (serve-d) stderr :785:doStartup Root RootSuggestion("C:\\Users\\aminy\\Documents\\GitHub\\JavaScript\\atom-ide-d\\spec\\fixtures\\", true) initialized in 140 ms and 477 μs

logger.ts:19 D (serve-d) stderr 2021-02-24T15:17:55.642 [info] source\served\extension.d:701:doStartup Initializing instance for root RootSuggestion("C:\\Users\\aminy\\Documents\\GitHub\\JavaScript\\atom-ide-d\\spec\\fixtures", true)

logger.ts:19 D (serve-d) stderr

logger.ts:19 D (serve-d) stderr object.Exception@..\..\..\..\AppData\Local\dub\packages\workspace-d-3.6.0-pre.8\workspace-d\source\workspaced\backend.d(564): Instance with cwd 'C:\Users\aminy\Documents\GitHub\JavaScript\atom-ide-d\spec\fixtures' already exists!

logger.ts:19 D (serve-d) stderr ----------------

logger.ts:19 D (serve-d) stderr

logger.ts:19 D (serve-d) stderr 0x00007FF764773515 in workspaced.backend.WorkspaceD.addInstance at C:\Users\aminy\AppData\Local\dub\packages\workspace-d-3.6.0-pre.8\workspace-d\source\workspaced\backend.d(565)

logger.ts:19 D (serve-d) stderr 0x00007FF764543774 in served.extension.doStartup at C:\Users\aminy\Documents\GitHub\D\serve-d\source\served\extension.d(715)

logger.ts:19 D (serve-d) stderr 0x00007FF7645412B7 in served.extension.changedConfig at C:\Users\aminy\Documents\GitHub\D\serve-d\source\served\extension.d(124)

logger.ts:19 D (serve-d) stderr 0x00007FF76454B7DD in served.extension.initialize.__lambda4 at C:\Users\aminy\Documents\GitHub\D\serve-d\source\served\extension.d(481)

logger.ts:19 D (serve-d) stderr 0x00007FF7646D2F85 in served.utils.async.parallelMain at C:\Users\aminy\Documents\GitHub\D\serve-d\serverbase\source\served\utils\async.d(51)

logger.ts:19 D (serve-d) stderr 0x00007FF764C28958 in fiber_entryPoint

logger.ts:19 D (serve-d) stderr 0x00007FF764C28F19 in pure nothrow @nogc void core.thread.fiber.Fiber.initStack().trampoline()

This also prevents closing Atom.

try again now, should work this time for sure:tm:

Wheee. It is fixed now. 🎉

Fixed in https://github.com/Pure-D/serve-d/commit/3d47689ca2a65fe89848266dd07efa3325fb230b


Refine rexray volume ls filter

This commit fixes the following issues:

When rexray volume ls was used specifying only a volume ID,
either a volume with a blank name, or a volume matching the same
volume ID would be returned.
When rexray volume ls was used specifying a volume name that
matched multiple volumes, only one volume with a matching volume
name would be returned. In REX-Ray 0.3.0, all volumes that matched
the volume name would be returned.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

Current coverage is 44.55% (diff: 100%)

Merging #540 into master will not change coverage

@@             master       #540   diff @@
==========================================
  Files             2          2
  Lines           193        193
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits             86         86
  Misses          107        107
  Partials          0          0

Powered by Codecov. Last update a28b6b8...09743d8

Hi @akutz, nice find!  I've made the change for optimizing string comparison based on @benbjohnson's article.

nice work @proudh !


{Core} Fix test_open_page_in_browser on WSL

Description
src/azure-cli-core/azure/cli/core/tests/test_util.py::TestUtils::test_open_page_in_browser fails on WSL:
_mock_self = <MagicMock name='open' spec='function' id='139689703216128'>, args = ('http://foo', 2), kwargs = {}
self = <MagicMock name='open' spec='function' id='139689703216128'>
msg = "Expected 'open' to be called once. Called 0 times."

    def assert_called_once_with(_mock_self, *args, **kwargs):
        """assert that the mock was called exactly once and that that call was
        with the specified arguments."""
        self = _mock_self
        if not self.call_count == 1:
            msg = ("Expected '%s' to be called once. Called %s times.%s"
                   % (self._mock_name or 'mock',
                      self.call_count,
                      self._calls_repr()))
>           raise AssertionError(msg)
E           AssertionError: Expected 'open' to be called once. Called 0 times.

env38/lib/python3.8/site-packages/mock/mock.py:925: AssertionError

Now fix it!

Core


Mbasiuk/tdi 39535 netsuite sublist issue master

What is the current behavior? (You can also link to an open issue here)
What is the new behavior?
Add new checkbox for body fields only.
Please check if the PR fulfills these requirements

[x] The commit message follows Talend standard
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features) ?
[ ] The code coverage on new code >75%
[ ] The new code does not introduce new technical issues (sonar / eslint)

What kind of change does this PR introduce?

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

Does this PR introduce a breaking change?

[ ] Yes
[x] No

If this PR contains a breaking change, please describe the impact and migration path for existing applications: ...
Other information:

Pull request test result: success :star:
Sonar results


release 0.3.1

I propose that we release 0.3.1 to distribute the fixes in #141 and #145. I'll do this sometime between Friday and Monday unless I hear objections.

I released 0.3.1. Thanks to all who contributed.


Inference issues due to changes in BandedMatrices.jl

The new CONTAINER type parameter in BandedMatrix has made some formerly-concrete fields now non-concrete. For example:
struct BlockBandedSizes
    block_sizes::BlockSizes{2}
    block_starts::BandedMatrix{Int} # gives index where the blocks start
    block_strides::Vector{Int} # gives stride to next block for J-th column
end

that BandedMatrix{Int} is now actually a BandedMatrix{Int, C} where C, which is causing some inference and performance issues when working with views.
We should either make CONTAINER also a type parameter of BlockBandedSizes or enforce a particular container type (presumably Matrix{T} as it was before). I'm not familiar enough with these packages yet to know which one to prefer. Any suggestions?

Nice catch, I don’t know how I missed that. I’ll hardcode Matrix{T} and retag.
Allowing general backends (Think distributed arrays l) is in the pipeline for thIs package.

Ok, sounds good. Thank you!

Do you have a good test for where the inference breaks, so I can add @inferred to the unit tests?

Sure, how about:
s = BlockBandedMatrices.BlockBandedSizes([1, 2], [1, 2], 0, 0)
f(s) = s.block_starts.data
@inferred(f(s))


👌IMPROVE: Allow auto for grid columns

Codecov Report

Merging #8 (23e0dcf) into main (23c3d9f) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main       #8   +/-   ##
=======================================
  Coverage   88.20%   88.20%
=======================================
  Files          10       10
  Lines         797      797
=======================================
  Hits          703      703
  Misses         94       94

Flag
Coverage Δ

pytests
88.20% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

sphinx_design/grids.py
90.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


Insert xsd code to allow for FID raw data to be stored as binary or in an external file

We should look at what PSI mzML did here. For a comparison look at github nmrML\docs\SchemaDocumentation1D NMR Spectrum Raw Data Representation.docx

By now it has crystallized that we won't have external files.


Linux system call census

MUSL defines ~200 system calls that it may invoke. We need to do a census, to determine which of those calls we are or are not going to implement, which can be shared across HaLVM backends, which need to be backend-specific, which are going to potentially kick out to user-defined backends, etc.
This initial census is being performed in zHALVMCore/musl_syscall_table.txt`.

@acw The .txt file is not associated with an URl. Maybe a markdown / edit mishap.

Initial version complete in f9bd1c6.


refactor: changeset typespec

Resolves the issue explained here: https://github.com/elixir-ecto/ecto/issues/3452.
Just an additional comment: I had this problem using the version 3.4.6 and there is a third key that needs to be changed (repo_changes). But since I'm targeting to master, it doesn't exist on this PR.

Sorry, I have already fixed in master when I saw the issue. :) Next time, feel free to skip the issue and jump straight into the PR. :)


Detailed installation instructions for linux/macos/windows

Docs page preview: https://ansible-navigator--593.org.readthedocs.build/en/593/installation/.

@cidrblock you have your local Git misconfigured and it doesn't attribute commits to your GitHub account.

ty @webknjaz for catching the account issue

@cidrblock do you think you could add RTD check to the branch protection in the repo?

recheck

recheck

recheck

TY all for the suggestions, I think most of the significant one were covered.
For anything else that merits a change, please log an issue or feel free to do a PR.

regarding this: https://github.com/ansible/ansible-navigator/pull/593#discussion_r727213795
all formatting from headings was removed across the board, it looked much cleaner without it


feat(cli): add a way to run command from code

import {Cli} from "@tsed/cli";

Cli.dispatch("init", {
  //... init options
});

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

v3.25.0
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 4.0.0-rc.3 :tada:
The release is available on:

v4.0.0-rc.3
GitHub release

Your semantic-release bot :package::rocket:


Add is_safe logprob to Llamaguard annotation

This adds an extra field is_safe_logprob to Llamaguard's annotations.

looks good. Added a thought on if we might just want to dump the full log probs and do the analysis in post


[Breaking Change] Revert deleting workbooks entity set

This update to the metadata that happened on 20th July 2021 removed the workbooks entity set. This caused the generation of multiple paths due to the expansion of navigation property paths of type driveItem during conversion of the CSDL to OpenAPI by the Microsoft.OpenApi.OData lib. v1.0.8 used by the DevX API. This lead to service unavailability in the API due to memory over-utilisation.
The workbooks entity set needs to be reinstated.
AB#10770

Re-opening this issue as a temporary fix to unblock PowerShell.


[Data] Simple data import from CSV

Simple data import from CSV

Related to: https://github.com/SAP/xsk/issues/72

Issue cloned to https://github.com/eclipse/dirigible/issues/1613

This issue is closed as the project is no longer maintained


Delegate release notes 790xx

Harness Developer Pull Request
Thanks for helping us make the Developer Hub better. The PR will be looked at
by the maintainers.
What Type of PR is This?

[ ] Issue
[ ] Feature
[ ] Maintenance/Chore

If tied to an Issue, list the Issue(s) here:

Issue(s)

House Keeping
Some items to keep track of. Screen shots of changes are optional but would help the maintainers review quicker.

[ ] Tested Locally
[ ] Optional Screen Shoot.

Closing without merging because there will not be a delegate release this week. Delegate has switched to a new release cadence and will now be released every two weeks.


API failures in activity view

No route found for "PUT /api/activities/1": Method Not Allowed (Allow: GET, HEAD)

Klappt nun.


use Amazon SES for Auth0

Let's use Amazon as we will keep open the account for additional services.

Implemented configuring Auth0 to use AWS SES as SMTP provider


[Relay][TIR] Add utility to lower Relay func to TIR prim func

This is very useful for creating a TensorIR program that is otherwise hard to so via manual TVMScript or te compute + create_prim_func.
A good example is a TensorIR program having AllocateConst, since it is not possible to create such modules with embedded constants via TVMScript parsing. AllocateConst has been the source of many issues and I've sent many fixes for them, but it has always been difficult to create test cases for such issues. But if we start from Relay, we can easily create such modules by lowering Relay func to TIR with link-params = True.
This also makes it possible to, say, author a complicated module in PyTorch and directly lower it to TensorIR.
As an example of its use, I added a regression test for the issue described in https://github.com/apache/tvm/pull/13605.
@Hzfengsy @junrushao @csullivan

:wave: Hello @masahi / @csullivan / @echuraev / @junrushao,
Whilst I appreciate this is useful with the use-case demonstrated, I believe it might've needed a bit more time for others to formulate a review as it was up for less than 24 hours before merge?
One of my concerns is that this seems to be creating new public interfaces to the internals of the TECompiler which in the past we've attempted to remove:

https://discuss.tvm.apache.org/t/rfc-relay-tecompiler-rewrite-existing-compile-engine-to-match-updated-compiler-flow/9233
https://github.com/apache/tvm/pull/8775
https://github.com/apache/tvm/pull/9282

This change means we have to maintain an interface which generates a single tir::PrimFunc from a relay::Function where-as it could potentially lead to multiple tir::PrimFunc with a single IRModule as a result. The next line down:
IRModule tir_mod = PrimFuncToIRModule(f.value());

Implies we wanted it in IRModule form anyway, so creating an IRModule with a Function and running LowerTE(mod) seems the best result here?

@Mousius The new function simply composes the existing interface to the TECompiler, LowerTECompute and CreatePrimFunc that converts lowered TE compute to TensorIR. LowerTECompute was introduced after the compile engine refactor you mentioned completed, and made only possible thanks to that refactoring work. So I don't get your concern here.
What I wanted to add is a simple interface that converts one Relay primitive function to the corresponding TIR prim func. Then I realized that backend/task_extraction.cc already has code that does exactly that, so I simply extracted into a reusable function and exposed it to Python. We require the input to be a primitive function, so we never generates multiple TIR prim funcs.

Implies we wanted it in IRModule form anyway, so creating an IRModule with a Function and running LowerTE(mod) seems the best result here?

This is just MetaSchedule storing an IRModule in a task. I didn't change any behavior about task extraction in this PR. What we want is a relay::Function -> tir::PrimFunc interface, IRModule -> IRModule is valid but it wouldn't convey what this new API is meant for.

@Mousius The new function simply composes the existing interface to the TECompiler, LowerTECompute and CreatePrimFunc that converts lowered TE compute to TensorIR. LowerTECompute was introduced after the compile engine refactor you mentioned completed, and made only possible thanks to that refactoring work. So I don't get your concern here.

I find this equally concerning, given this is also exposing more of the internals of the TE Compiler rather than having clear boundaries within the codebase.

What I wanted to add is a simple interface that converts one Relay primitive function to the corresponding TIR prim func. Then I realized that backend/task_extraction.cc already has code that does exactly that, so I simply extracted into a reusable function and exposed it to Python. We require the input to be a primitive function, so we never generates multiple TIR prim funcs.

Exposing it python and as part of the public API means others can access it, which means that we have to support it as a way of using the compiler rather than as an aspect of meta-scheduler. This is similar to the previous methods that we were unable to deprecate in https://github.com/apache/tvm/pull/13606.

This is just a convention of MetaSchedule, storing an IRModule with one prim func as a task. I didn't change any behavior about task extraction in this PR. What we want is a relay::Function -> tir::PrimFunc interface, IRModule -> IRModule is valid but it wouldn't convey what this new API is meant for. LowerTE is also overkill since I don't need to lower schedules and I'm not concerned about external codegen etc.

I don't think LowerTE is overkill in practice, if it doesn't find any external codegen or other things to do it won't take any action - it's a standardised interface between two modules in the codebase, you've already indicated meta schedule is breaking that boundary and that leads us back to the original issues with CompileEngine.


Add an expression for direct access to an enum's discriminant

Third-party derive macros want to be able to use the same direct discriminant access to the enum for which they're implementing a trait that the core derive macro does, which seems entirely reasonable.
To allow that without imposing a new category of major breaking changes on library authors, this proposes a safe built-in way for getting the discriminant as a primitive integer -- not an opaque mem::Discriminant -- for anything on which you can see private fields.
Rendered

As alternative we could have not magical field b.enum#discriminant, but magical "type" enum: enum::discriminant(&b)
let b = Enum::Tuple(true);
assert_eq!(enum::discriminant(&b), 13);

As alternative we could have not magical field b.enum#discriminant, but magical "type"/"trait" enum: enum::discriminant(&b)
let b = Enum::Tuple(true);
assert_eq!(enum::discriminant(&b), 13);

Trait impls are global, so this fails to achieve the goal of this RFC to restrict access to the discriminant to the crate that declared the enum.

It seems the primary reason of this RFC is that .enum#discriminant is pub(in self) so that, as mentioned in rust-lang/rust#106418, it allows author of the enum to reorder any variants without breaking change?
But according to #1105, having a > b in 1.1.0 and a < b in 1.2.0 is not considered a necessary condition of breakage, unless the variant order is explicitly documented:

In general, APIs are expected to provide explicit contracts for their behavior via documentation, and behavior that is not part of this contract is permitted to change in minor revisions.

So I don't see much advantage of this RFC over e.g. allow users to use std::intrinsics::discrimant_value() (e.g. via std::mem::discriminant(&a).value()).

@scottmcm

Well, changing types is still a major breaking change, right?

I'm pretty sure changing #[repr] is a breaking change, with or without discriminant_value. At the very least it makes the following code break if you change from #[repr(u8)] to #[repr(u16)].
#[repr(u8)]
enum Enum {
    A = 1,
}
let _: u8 = unsafe { std::mem::transmute(Enum::A) };

Now, #1105 did say "not all breaking changes are major"[^2], and as you have said "layout is explicitly minor"[^1]. But if we accept breaking transmute I don't see why not accepting breaking PartialOrd of the discriminant values (not even the enum values themselves).
[^1]: though nowhere in #1105 I could find the word "layout"
[^2]: heck changing the result of any const fn-evaluable expression is breaking

(For example, if you have #[derive(...)] enum Foo { A(i32), B(String), C(i32) }

If the enum explicitly derived PartialOrd, it would be the enum author's responsibility to not change the variant order because they are going to change Foo::A(1) < Foo::C(2), let alone discriminant_value(&Foo::A(1)) < discriminant_value(&Foo::C(2)).
Let's focus on the case where PartialOrd is not derived on the enum. I think everyone in rust-lang/rust#106418 agreed that if E derived PartialOrd there is no problem to impl Ord for Discriminant<E>.

Today, None is 0 but Ok is 0, and that means that ControlFlow can't match both, which means that the ? desugaring can't be a NOP for both, only for one of them.
It would be nice to change the discriminants on one of them (probably Result) to be the other way around to simplify that codegen, but I think that's just far more practical without introducing a way for people to depend on the currently-invisible values.

Result already derived PartialOrd, Ok(3) < Err(3), as mentioned in #3058. Yes you could change the implementation to not use derive to "stabilize" the order without relying on the discriminant value.
enum Result2<T, E> {
    Err(E),
    Ok(T),
}

impl<T: PartialOrd, E: PartialOrd> PartialOrd for Result2<T, E> {
    fn partial_cmp(&self, other: &Self) -> Option<Ordering> {
        match (self, other) {
            (Self::Ok(a), Self::Ok(b)) => a.partial_cmp(b),
            (Self::Err(a), Self::Err(b)) => a.partial_cmp(b),
            _ => discriminant_value(other).partial_cmp(&discriminant_value(self)), // reverse order
        }
    }
}

Then reordering Ok / Err is just going to break those people relying on discriminant_value(&Ok(3)) == 0 && discriminant_value(&Err(3)) == 1 which I'd say let them be broken — basically the stance in https://github.com/rust-lang/rust/pull/106418#issuecomment-1954783410.

Anyway I'd expect

If the enum is #[repr(Rust)][^3], then third-party crates must not rely on specific value of the discriminants (other than being distinct), because the enum author is free to reorder the variants
If the enum is #[repr(inttype)][^4], then the discriminant values are guaranteed stable, because the Rust spec guaranteed the pointer-casting method extract that inttype tag. The enum author should not change the discriminant values nor representation type between minor versions. If they reorder the variants, explicit discriminants should be assigned to maintain stability.
Not sure about #[repr(C)], treat it as the same as #[repr(C, c_int)] here?

[^3]: note that Result, Option, ControlFlow are all plain #[repr(Rust)] enums.
[^4]: note that cmp::Ordering is #[repr(i8)]

Well, it's written in other places, like https://doc.rust-lang.org/std/mem/fn.size_of.html's

Thanks. I hope there is a centralized place to look these up :smile: (maybe obi1kenobi/cargo-semver-checks#5?)

But -- less authoritatively -- rustdoc has been doing things like https://github.com/rust-lang/rust/pull/115439 that also suggest some level of consensus that non-Rust reprs aren't necessarily semver guarantees either.

Well I wouldn't count #[repr(transparent)] as non-Rust :sweat_smile:; besides 115439 only hides the attribute when the inner type is private.
IMO if the #[repr] appears in the rustdoc (like https://doc.rust-lang.org/core/cmp/enum.Ordering.html), it is part of the API contract and changing it should be breaking. That said, std::cmp::Ordering only gained #[repr(i8)] at 1.57 by rust-lang/rust#89507[^1], and the values -1, 0, 1 are shown in the doc only since 1.75 due to a rustdoc improvement rust-lang/rust#116142.
That means at least until 1.57 for non-ABI purpose rust-lang/rust did treat #[repr] change as a minor change[^2], and until 1.75 breakage due to changed discriminant value was also not obvious.
(If rust-lang/rust#86772 ever got implemented then <E as AsRepr>::Repr would be another source of breakage)
[^1]: technically not breaking since -1..=1 is within the i8 range it is layout-compatible with the previous #[repr(Rust)]` form
[^2]: cargo-semver-checks v0.6+ do consider them major breaking change though: obi1kenobi/cargo-semver-checks#29

There are extensive docs  on what is and is not semver breaking at https://doc.rust-lang.org/cargo/reference/semver.html.

I'd also like to note that by exploiting the implementation details of Hash it is already possible to extract the discriminant value in safe and stable Rust (without the repr type at compile-time though). Of course we could argue that Discriminant::hash() is not guaranteed to simply call hasher.write_isize().

… Additionally the data passed by most standard library types should not be considered stable between compiler versions.
This means tests shouldn’t probe hard-coded hash values or data fed to a Hasher …

use std::mem::Discriminant;

#[derive(PartialEq, Eq, Debug)]
#[non_exhaustive]
pub enum DiscriminantValue {
    Usize(usize),
    Isize(isize),
    U8(u8),
    I8(i8),
    U16(u16),
    I16(i16),
    U32(u32),
    I32(i32),
    U64(u64),
    I64(i64),
    U128(u128),
    I128(i128),
}

impl<E> From<Discriminant<E>> for DiscriminantValue {
    fn from(v: Discriminant<E>) -> Self {
        use std::hash::{Hash, Hasher};

        struct DiscriminantValueExtractor(DiscriminantValue);

        impl Hasher for DiscriminantValueExtractor {
            fn write(&mut self, _: &[u8]) {
                unreachable!("don't use this as an actual Hasher ;)");
            }
            fn finish(&self) -> u64 {
                unreachable!("don't use this as an actual Hasher ;)")
            }

            fn write_u8(&mut self, i: u8) { self.0 = DiscriminantValue::U8(i); }
            fn write_u16(&mut self, i: u16) { self.0 = DiscriminantValue::U16(i); }
            fn write_u32(&mut self, i: u32) { self.0 = DiscriminantValue::U32(i); }
            fn write_u64(&mut self, i: u64) { self.0 = DiscriminantValue::U64(i); }
            fn write_u128(&mut self, i: u128) { self.0 = DiscriminantValue::U128(i); }
            fn write_usize(&mut self, i: usize) { self.0 = DiscriminantValue::Usize(i); }
            fn write_i8(&mut self, i: i8) { self.0 = DiscriminantValue::I8(i); }
            fn write_i16(&mut self, i: i16) { self.0 = DiscriminantValue::I16(i); }
            fn write_i32(&mut self, i: i32) { self.0 = DiscriminantValue::I32(i); }
            fn write_i64(&mut self, i: i64) { self.0 = DiscriminantValue::I64(i); }
            fn write_i128(&mut self, i: i128) { self.0 = DiscriminantValue::I128(i); }
            fn write_isize(&mut self, i: isize) { self.0 = DiscriminantValue::Isize(i); }
        }

        let mut extractor = DiscriminantValueExtractor(DiscriminantValue::Isize(0));
        v.hash(&mut extractor);
        extractor.0
    }
}

//------------------------------

enum Option1<T> {
    None,
    Some(T),
}

enum Option2<T> {
    Some(T),
    None,
}

fn main() {
    use std::mem::discriminant;

    let v1 = discriminant(&Option1::Some(&4));
    let v2 = discriminant(&Option2::Some(&5));

    let dv1 = DiscriminantValue::from(v1);
    let dv2 = DiscriminantValue::from(v2);

    assert_eq!(dv1, DiscriminantValue::Isize(1));
    assert_eq!(dv2, DiscriminantValue::Isize(0));
}

IMO if the #[repr] appears in the rustdoc (like https://doc.rust-lang.org/core/cmp/enum.Ordering.html), it is part of the API contract and changing it should be breaking. That said, std::cmp::Ordering only gained #[repr(i8)] at 1.57 by https://github.com/rust-lang/rust/pull/895071, and the values -1, 0, 1 are shown in the doc only since 1.75 due to a rustdoc improvement https://github.com/rust-lang/rust/pull/116142.

I don't think rustdoc changes like that are subject to FCP by the team(s) that governs semver (t-lang would be involved I assume?), so I don't think rustdoc can be used as a guideline here. In fact rustdoc printing #[repr] even though they were not considered stable guarantees was an open issue for many years that finally got fixed recently. I would say using rustdoc as the arbiter here is a common misconception but not backed by an actual decision process.

@RalfJung Thanks. Perhaps #1105 should container to pointer to https://doc.rust-lang.org/cargo/reference/semver.html.

I suggest the Lexing section should say how enum#discriminant would be represented as a proc_macro::TokenTree.

No lexing section needed, enum#discriminant is a single "identifier" token following #3101.

rfc3101 says that enum#discriminant is, at present, a lexing-time error, and not any kind of token at all.
The statement that enum#discriminant is treated as an Ident for the purposes of proc-macro input is what I would like to see written in the RFC.
(Clearly it's not an identifier for the purposes of the grammar in general, as that would defeat the point.)
There's also a question of how proc-macros can create such a token. Presumably there would be something parallel to Ident::new_raw().

@mattheww  I'd suppose just Ident::new("enum#discriminant", span).

Then let's write that in the RFC rather than leaving it for people to suppose.
(To be clear, I'm not suggesting any of this will cause trouble, I just want it to be written down.)

I'll note in passing that this is the second language feature that "could've been a library" but for privacy -- the other that I'm thinking of being Jack Wrenn's safe transmute proposal. It seems like a fairly common thing that we want to have access to some information scoped to "those who have privileged visibility".
I'm not against this syntax in particular but I do think this should be a clue for future prioritization -- something like scoped impls, or some way to reify privacy, would be helpful to ensure Rust lives up to its value of being Extensible.

something like scoped impls, or some way to reify privacy

We do have restrictions (approved RFC 3323, tracking issue) which we should be able to leverage in some way or another once they're implemented (rust-lang/rust#106074).

Saw this on TWIR and was wondering if this should be done together with having a “discriminant type” as a “secret enum” declared for all enums that is just the tag and no body, then perhaps a special trait can be used to retrieve the type or the value(FooEnum::Discriminant?).

We discussed this in the lang design meeting on 2024-07-10.  Some takeaways:
One is that we decided to go with tag rather than discriminant for this and other language work.  We were persuaded by its conciseness.  While the word "discriminant" has been used in documentation and in the standard library, this is the first time we'd be adding a language feature that has to name the concept.  Given that the existing mem::discriminant API is kind of unfortunate, and unloved in enough other ways, we didn't feel we needed to put much weight on that as precedent.  We also noted that much of the language of RFC 2195 had also preferred tag.
Two is that we all seemed happy with some kind of postfix syntax here as opposed to e.g. a special macro (like offset_of!).  One reason for this is our expectation of using this kind of syntax for more things and pushing further in this direction.  (Some of us would probably be unhappy with this choice if this were the only thing for which we ever used this kind of syntax.)
Three is that we didn't feel strongly that namespacing this with enum was necessary.  We discussed how that may be more namespacing than needed, and that seemed the general mood.  It seems unlikely we're going to collide identifiers here, and we already know due to type checking that we're dealing with an enum after all; we don't need to risk entering the vicinity of Hungarian notation.
Four, we had a good discussion about whether to go with .#tag or .tag.  There are good reasons for both.  The former can be used more widely, and that seemed to be where we landed as the place to start with this proposal.  We discussed how #ident is not a single token (as it wasn't reserved under RFC 3101), but that's OK, as we can just have the compiler treat this sequence of tokens the right way after lexing.
Five, we talked about how to provide this for variant paths in addition to just values.  We noted that fieldless variants could be treated as values, so one could say E::Variant.#tag, but that for variants with fields, that wouldn't work, and we may want to provide something like E::Variant::#tag.  We talked about whether these should be lowercase, for consistency and using our kind of special privilege as language designers (as with e.g. u8), or whether these should be capitalized to correspond to how they might be viewed as associated constants or associated types (depending on the feature).
Six, we talked about the various ways we might want rustdoc to visualize this, and how that would help to rapidly raise awareness of and familiarity with this feature.

The use of "tag" as apparently a synonym for "discriminant" is unfortunate insofar as "tag" exists as a term in the compiler and it is not equivalent to "discriminant" there. It refers to how the discriminant is encoded in memory.

Four, we had a good discussion about whether to go with .#tag or .tag.

one big problem with the .#tag syntax is that it isn't usable in the very popular quote! macro since it would try to interpolate a tag variable at that point.
e.g. https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=41c8d00dd76a2a296cacaa125334bc92

@traviscross I think we have concluded from https://github.com/rust-lang/rfcs/pull/3607#discussion_r1561335884 that this RFC is producing the discriminant, not the tag.
#2195 is irrelevant here, it controls the maximum size of the tag which for now is also determine the maximum of discriminant value. So they can be interchangeable in #[repr].
But for this RFC the ._#thing must be a concrete value, which the "tag" (in-memory value) and "discriminant" (0, 1, 2, ...) very often have distinct values after layout optimization.

though, just .tag by itself may also conflict with a reasonable extension of enum pattern types, where you can directly access fields of single-variant pattern types without needing to match, e.g.:
pub enum MyEnum {
    A {
        tag: u8,
        b: i32,
    },
    B,
}

fn f(v: MyEnum is MyEnum::A) {
    println!("{}, {}", v.tag, v.b); // direct field access, since we statically know which variant we have
}

Two is that we all seemed happy with some kind of postfix syntax here as opposed to e.g. a special macro (like offset_of!).

What about a postfix macro? So it would look something like:
Enum::Variant::discriminent!() or maybe Enum.discriminant!(Variant).

Four, we had a good discussion about whether to go with .#tag or .tag.

one big problem with the .#tag syntax is that it isn't usable in the very popular quote! macro since it would try to interpolate a tag variable at that point. (.enum#tag, .tag, or .anything#tag don't have that problem since they don't have a separate # token) e.g. https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=41c8d00dd76a2a296cacaa125334bc92

this seems like not-a-problem if we finally decide to ship https://github.com/rust-lang/rust/issues/54722 since it uses a different unquoting.

@programmerjake I don't think we should have dotted access to enum fields unless those fields are explicitly declared as a common field at the top level of the enum. In which case, we could say that you can't declare a common field named "tag". (Whether we should is another question.)


Correction for raw affiliation TRAME UR-UPJV 4284 / CRAVO, 17 rue James de Rothschild, 60200 Compiègne, France

Correction needed for raw affiliation TRAME UR-UPJV 4284 / CRAVO, 17 rue James de Rothschild, 60200 Compiègne, France
raw_affiliation_name: TRAME UR-UPJV 4284 / CRAVO, 17 rue James de Rothschild, 60200 Compiègne, France
new_rors: 01gyxrk03
previous_rors:
works_examples: W4323309373
contact: 9c109ad53a7ed64b67352b9bfd69949f:cd415d1a5fe80b9be26bc4cf197bedb7 @ u-picardie.fr

This issue was accepted and ingested by the OpenAlex team on 2024-10-10. The new affiliations should be visible within the next 7 days.


Support Google Fonts with a    space

Google says: add a + for spaces, eg. Open+Sans
This doesn't work for me.

:tada: This issue has been resolved in version 1.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Blog post about cage recursion and how we resolved that

After this PR is merged and new version of EO is released it would be nice to write a blog post about this case.
@levBagryansky WDYT?

@maxonfjvipon I agree

@levBagryansky I think it's time to make a blog post


Docker Tag 5.12 does not provide version 5.12.11

If I use docker tag 5.12 I will get version 5.12.5 of the controller and not 5.12.11. Tag 5.12-testing is working fine.

Don't care about... my mistake. Missing imagepullpolicy was the issue.


General Issue: Restructuring the Terms pages

Suggestion
For each FDO, there are 3 resource pages, the terms page, the quick reference guide and the core resources. the terms page and the guide are very close to each other in terms of the information they present. This structure is taken from the DwC documentation, it differs however in certain ways, that are a bit of a disadvantage.
In the guide, the terms are structured a bit more user friendly. All of the properties are sorted by their class, even if this means that reused properties occur multiple times on that page. On the terms page, the terms show a bit more information.
When the URI of a term in DwC is resolved, it is redirected to the terms page, which is sorted alphabetically. DwC doesn't have any reuses of properties between classes. The ones that are, are sorted in their own group called "Record level". Which is why they don't encounter a problem that exists for openDS.
The openDS terms don't resolve yet and I am not sure, what the planned strategy is for when they resolve, but at the moment they could not link to the correct definition, as the entries on the terms page are still dependent on the class where they are used. Compare for example MaterialEntity:organisationName and DigitalSpecimen:organisationName, both having the same URI, but different documentation here, in regards to the "Belongs to Class" segment.
We feel that the terms pages need to be restructured, so that each term only occurs once. The terms could be sorted alphabetically and if reused by different classes, it should list them as "Belongs to Class(es):" . The anchor links at the section Index By Term Name should only include the term name and not the class, just as the DwC documentation does.

Hi David,
Thanks for creating this ticket.
I understand what you mean, but there are some reasons why we did follow this approach.
The first is that we followed the setup used by LatimerCore on their terms page https://ltc.tdwg.org/, setup by Ben Norton.
This has been ratified, and we felt it has a clear and reusable structure.
If you look at their terms pages it has the same issue as you describe for DiSSCo, for example there is:

https://ltc.tdwg.org/terms/index.html#ContactDetail_hasIdentifier
https://ltc.tdwg.org/terms/index.html#EcologicalContext_hasIdentifier
https://ltc.tdwg.org/terms/index.html#ChronometricAge_hasIdentifier
The term ltc:hasIdentifier is used in several classes and is therefore replicated several times on the terms pages.
Of course, this doesn't mean that this might not be want to change it, but it does mean that at least the structure should be recognisable and has been accepted by TDWG.

Another argument to replicate terms is to easily give the user a complete overview of all terms in an object without having to move back and forward between different pages or part of a page.
We wanted to keep things simple and together, grouped around the class it is a part of.
If we would deduplicate the structure we would need to create additional pages for the nested objects (Agent, Identifier, etc...) resulting in even more pages.
Then, if you want a complete overview of the Digital Specimen you would have to flip between pages, check the “Belongs to Class(es)” and construct the object.
As these are pages for human use (schemas.dissco.tech is for machines) we felt we should keep it as simple as possible.
However, that does not mean that this isn't a valid point, and we would have to see how this works out when we create the openDS terms.
Let's see this as a first version, on which we iterate and improve.
Kind regards,
Sam


jenkins pull request does work properly

I have Jenkins setup for a scala/sbt project on github.
Everything seem to be working fine, except that the build for Pull Requests (from forks) does not seem to work compile the changes in the PR. Like it seems like it only compiles the master branch in the main repository. Even if you have syntax bug in your PR, it would still pass the jenkins test.
Anyone has faced this problem before? Any advice / suggestions?

please provide your settings for job

And please confirm that you are using this plugin and not ghprb-plugin  :)

@Ianwen could you be a little specific what settings youI need to report?
@KostyaSha  Here is what I have installed. Am I using the right one?

you are using not this plugin.ghpb is other plugin

Do you recommend just using this and removing ghprb-plugin?

Also, is the plugin listed in jenkins plugins? If not, where can I find the installation guidelines?

this (experimental) and ghprb doesn't conflict. This plugin available under http://jenkins-ci.org/content/experimental-plugins-update-center or you can just upload hpi in advanced section your jenkins plugin manager http://mirrors.jenkins-ci.org/plugins/github-pullrequest/0.0.1-beta13/ (note correct depent plugins should be installed)


modal loading iframe on iOS - animated gif won't play

Loading a page as an iFrame into bootstrap 3 modal window.
Animated Gif on page does not play on iOS (9) devices.
Works on Android.
Problem persists on these iOS browsers: Safari, Chrome and FF.

@beyoyo2 Please post a JS Bin or JS Fiddle that demonstrates the problem.

Hey there!
We're automatically closing this issue since the original poster (or another commenter) hasn't yet responded to the question or request made to them 14 days ago. We therefore assume that the user has lost interest or resolved the problem on their own. Closed issues that remain inactive for a long period may get automatically locked.
Don't worry though; if this is in error, let us know with a comment and we'll be happy to reopen the issue.
Thanks!
(Please note that this is an automated comment.)


usb-c: Add sink VIF policies to device tree, update the GenVIF script

A VIF node is added to device tree to hold VIF specifications and USB sink VIF policies are added to usb-c-connector node as properties.
The GenVIF script is updated to start parsing from VIF node.
The exisiting USB-C Sink sample project is updated to include examples of new changes in device tree.
The XML output is validated against schema
https://compliance.usb.org/cv/VendorInfoFile/Schemas/Current/VendorInfoFile.xsd Changes to XML namespaces is done according to validation
Signed-off-by: Madhurima Paruchuri<EMAIL_ADDRESS>

@gmarull @tejlmand hey I think the comments have been addressed, any chance you could give this another round of review?

I was trying to push upstream rebase first and commit(my changes) next. As part of it I made soft reset of last commit, when I pushed it, this pull request is closed.  I am trying to reopen it. Meanwhile this commit has latest changes which I was trying to push here to resolve comments : https://github.com/zephyrproject-rtos/zephyr/compare/main...madhurimaparuchuri:zephyr:gvif

The related commit is added back to this PR, but the commit looks like a whole new change now. Sorry for messing the PR, it's unintentional.

@gmarull could you revisit this?


As an author, other authors cannot modify my shared to friends post.

3/10

3/10

5

4/10

4

### Avg 3.8

Avg 3.8


Windows build: use same SQLITE_xxx build options as for non-Windows builds

I don't believe there is any good reason not to use the same for all builds...

Checklist

[X] Used a personal fork of the feedstock to propose changes
[X] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

@conda-forge-admin, please rerender

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

Hi! This is the friendly automated conda-forge-webservice.
I tried to rerender for you, but it looks like there was nothing to do.
This message was generated by GitHub actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/11543852614.

All CI checks passed


[CT-425] [Bug] Dbt seed null values inconsistent across Snowflake and BigQuery

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
null in seed data is loaded as a string of null instead of actual null in BigQuery. Only empty field is loaded as null. However, it's not the same for Snowflake, null is loaded as an actual null in Snowflake.
With the seed data under the Steps to Reproduce section, the following is the query result from BigQuery:
{  "favorite_color": "blue",  "id": "1",  "first_name": "NULL",  "email": "null",  "ip_address": "<IP_ADDRESS>",  "updated_at": "2008-09-12T19:08:31",  "ephemeral_copy": "1000"}
{  "favorite_color": "blue",  "id": "2",  "first_name": "None",  "email": null,  "ip_address": "<IP_ADDRESS>",  "updated_at": "1978-05-09T04:15:14",  "ephemeral_copy": "2000"}
{  "favorite_color": "green",  "id": "99",  "first_name": "-",  "email"<EMAIL_ADDRESS> "ip_address": "<IP_ADDRESS>",  "updated_at": "1991-11-14T12:33:55",  "ephemeral_copy": "3000"}
{  "favorite_color": "green",  "id": "100",  "first_name": "Frank",  "email"<EMAIL_ADDRESS> "ip_address": "<IP_ADDRESS>",  "updated_at": "2010-06-12T23:55:39",  "ephemeral_copy": "4000"}

Expected Behavior
I expect the loading of null from seed data to be consistent between BigQuery and Snowflake. An empty field or/and null should be loaded as actual null in both Snowflake and BigQuery.
Steps To Reproduce
dbt seed --target foo-target --select following-seed-data.csv
Seed data:
favorite_color,id,first_name,email,ip_address,updated_at,ephemeral_copy
blue,1,NULL,null,<IP_ADDRESS>,2008-09-12 19:08:31,1000
blue,2,None,,<IP_ADDRESS>,1978-05-09 04:15:14,2000
green,99,-,pjohnson2q@umn.edu,<IP_ADDRESS>,1991-11-14 12:33:55,3000
green,100,Frank,fgreene2r@blogspot.com,<IP_ADDRESS>,2010-06-12 23:55:39,4000

Relevant log output
No response
Environment
**The output of `dbt --version`:**

dbt --version
installed version: 1.0.4
   latest version: 1.0.4

Up to date!

Plugins:
  - bigquery: 1.0.0 - Up to date!

and
installed version: 0.20.1
   latest version: 1.0.0

Your version of dbt is out of date! You can find instructions for upgrading here:
https://docs.getdbt.com/docs/installation

Plugins:
  - bigquery: 0.20.1
  - snowflake: 0.20.1
  - redshift: 0.20.1
  - postgres: 0.20.1

The operating system you're using: macOS
The output of python --version:  Python 3.8.10
What database are you using dbt with?
snowflake, bigquery
Additional Context
No response

@tebesfinwo Thanks for opening! You're totally right.
On almost all databases, dbt uses agate to actually load CSVs into the database, as well as attempting to infer their column types. The relevant code is in dbt.clients.agate_helper.build_type_tester, which sets the strings "null", "" to be interpreted as SQL null. That "type tester" is used when we actually load the seed contents, using from_csv. Finally, the seed contents are piped through the seed materialization insert statement via SQL bindings. As I understand it, that's the step in which CSV string "null" is converted to SQL null.
In dbt-bigquery, we still use agate to infer column types, but not to do the actual data loading—that happens via a BigQuery Client method, load_table_from_file. That's good—when the database gives us a dedicated method, we should use it—but it means that null overrides don't happen in quite the same way. Thankfully, it looks like there is a way to provide custom "null values" is via LoadJobConfig.null_marker: docs, docs
Meaning that this code:
https://github.com/dbt-labs/dbt-bigquery/blob/8ef193a7ebe477f6fbbb01f8996851838f6bd441/dbt/adapters/bigquery/impl.py#L620-L625
With one extra line:
        load_config.null_marker = ("null", "")

Has the effect of turning "null" into real SQL null—though it leaves uppercase "NULL" as such, and it looks like it messes up "":
{  "favorite_color": "blue",  "id": "1",  "first_name": "NULL",  "email": null,  "ip_address": "<IP_ADDRESS>",  "updated_at": "2008-09-12T19:08:31",  "ephemeral_copy": "1000"}
{  "favorite_color": "blue",  "id": "2",  "first_name": "None",  "email": "",  "ip_address": "<IP_ADDRESS>",  "updated_at": "1978-05-09T04:15:14",  "ephemeral_copy": "2000"}
{  "favorite_color": "green",  "id": "99",  "first_name": "-",  "email"<EMAIL_ADDRESS> "ip_address": "<IP_ADDRESS>",  "updated_at": "1991-11-14T12:33:55",  "ephemeral_copy": "3000"}
{  "favorite_color": "green",  "id": "100",  "first_name": "Frank",  "email"<EMAIL_ADDRESS> "ip_address": "<IP_ADDRESS>",  "updated_at": "2010-06-12T23:55:39",  "ephemeral_copy": "4000"}

With some tweaking, I'm sure it could get where it needs to go.
I think it makes sense to keep the default consistent across databases. This could be a one-line change (plus a test), in the dbt-bigquery repo, where I'll transfer the issue now. Is that something you or another community member might be interested in contributing?


factorial of given number

Description
get a number from the user and print the factorial of the number
Domain
CPP
Type of Contribution
Others
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of LearnCPP.

/assign

/assign

/assign

/assign


Display user statistics in the dashboard

Scholarsphere 3 displays the user's statistics in terms for total views and downloads, number of works depositor, and collections created. We should display similar statistics as well, either in the new dashboard, or someplace else.

Related to #468


Restarting a map prevents LevelEnded events from triggering

If I need to restart the map, I start the map over from the menu and avoid the Restart button in-game in order to have LevelEnded events trigger properly. If I use the Restart button, all LevelEnded events fail to trigger until I re-enter the map from the menu.
(forgot to clip this happening, sorry)

Hello, thanks for the issue, could you include Game version & Mod version please?

BS 1.26.0, BS+ 5.0.3

It was related to the BeatSaber level restart mechanic. Fixed and pending next update deployment


Table not respecting Global Scope after "X per page" change

Package
filament/tables
Package Version
v2.9.13
Laravel Version
v8.81.0
Livewire Version
v2.10.1
PHP Version
php 8.1.0
Bug description
I'm using a Laravel Global Scope to restrict users to only seeing their own records, not other users' records.
When I first go to a Filament resource table, it only lists records for the logged in user, which means the table is respecting the global scope.
But when I then change from eg 10 records to page to eg 25 records per page, it suddenly shows me records from every user, which means it's no longer respecting the global scope.
Steps to reproduce
1 - Create a Global Scope that restricts records. For example:
class JustMyFamilyScope implements Scope
{
    public function apply(Builder $builder, Model $model)
    {
        return $builder->where('family_id', '=', Auth::user()->family_id);
    }
}

2 - Add that Global Scope to a Laravel model, eg
    protected static function booted()
    {
        static::addGlobalScope(new JustMyFamilyScope);
    }

5 - Ensure there are some records for that model that the logged in user CAN see with that scope, and some that the user CANNOT see. In my example - ensure some records have family_id that matches the logged in user's family_id, and some records where it does not match.
4 - Create a Filament resource for that Laravel model, including a table.
5 - View that table in a browser. You'll only see the records for that user, as expected. In this example, we see only the 17 shops for this family.

6 - Change the number of records on the page, eg from 10 to 25. You'll suddenly see all records for all users, which means the Global Scope is no longer being used. In this example we see all 42 shops, even though most of them are for other families.

Relevant log output
No response

Hey, this is weird. Does it work if you apply your global scope inside your Resource's getEloquentQuery()?
https://filamentadmin.com/docs/2.x/admin/resources#disabling-global-scopes

Hi @danharrin
I added this to my ShopResource class, but it didn't make any difference - the problem still happened. :-(
    public static function getEloquentQuery(): Builder
    {
        return parent::getEloquentQuery()->withGlobalScope('family', JustMyFamilyScope::Class);
    }

In case it's useful, my repo is on GitHub.

Also, you can see this in a test environment if you'd like to, staging.morplees.com/shops username<EMAIL_ADDRESS>and password issue-1360
(By the way, I'm aware it's not usually good practice to put a password on a public forum, but in this case it's a password that I've never used (and will never use) anywhere else, and it's a test environment with no production data, and that user account will disappear as soon as I seed the database again.)

Also, you can log in to a test environment if you'd like to, username<EMAIL_ADDRESS>and password issue-1360
(By the way, I'm aware it's not usually good practice to put a password on a public forum, but in this case it's a password that I've never used (and will never use) anywhere else, and it's a test environment with no production data, and that user account will disappear as soon as I seed the database again.)

Update - after a bit more testing, I've discovered that it's ANY change to the page that triggers the problem. So it's like this:

User does Initial page load.
Everything is perfect. GlobalScope is respected; only records for the user's family appear.
User makes a Livewire change, eg change the 'records per page' dropdown or change the sort order or something.
Data updates via Livewire, but data is now wrong. GlobalScope is NOT respected, all records for all families appear.

This makes me wonder if perhaps it's a Livewire bug not a Filament bug...

Could you perhaps try and replicate it with pure Livewire? Pass your records in at render() (as a parameter to the view() method), loop through the records using @foreach, then wire:click a button, and see if the records are still using the global scope?

will dig the issue and let you know what is actually causing the issue.

hey @BrendanTWhite  can you provide me a Repo with minimal reproduction

Hi @ManojKiranAppathurai , thanks for your kind offer. Yes I will create a minimal repo, but I won't be able to get to that for 12 or 24 hours.

Hi @ManojKiranAppathurai (and cc to @danharrin )
I'm closing this issue, as I've found the problem and it isn't a bug in Filament (and it's not really a bug in Livewire either).
The problem was in my scope file. For example:
class DotComScope implements Scope
{
    public function apply(Builder $builder, Model $model)
    {
        if (Auth::hasUser()) {
            return $builder->where('email', 'LIKE', '%.com');
        } else {
            return $builder;
        }
    }
}

And the problem is that the initial load was a regular HTTP call, with the Auth user set, and so the scope restriction was used. But subsequent changes were Livewire updates, which are API calls, and apparently they don't set Auth user in the same way in API calls.
I've put together a minimal repo at https://github.com/BrendanTWhite/issue-1360 if you're interested in taking a look.
Anyway, this issue can be closed. I'll find some other way to tweak the scope to only take effect when the user is logged in.
Thanks,
Brendan.

Just for the record, I ended up changing my scope to:
    public function apply(Builder $builder, Model $model)
    {
        if(session()->has('family_id')) {
            $builder->where('family_id', '=', session(key: 'family_id'));
        }
    }

... as per Kevin McKee’s Single Database multi-tenancy talk - and this seems to be working perfectly, assuming you remembered to set the session variable at login and remove it again at logout.

Just for anyone having the same problem: this has solved it for me (in case you applied the scope in a middleware)
https://laravel-livewire.com/docs/2.x/security#persistent-middleware


Overriding ghcWithPackages doesn't seem to work anymore

I used to override nix-shell derivations in my config.nix to add things like hlint, cabal-install, etc. to shell environments for my projects. I did it like this:
{
  haskellPackageOverrides = self: super: {
    ghcWithPackages = p: super.ghcWithPackages (f: p f ++ [ f.cabal-install f.hlint f.ghcid ]);
  };
}

This no longer affects shell environments and I can't figure out why.
cc @peti, I think you've worked a lot on the Haskell builder

The override should work, but it's possible that the environment you're entering doesn't even use ghcWithPackages. To know for sure, I'd need the exact command line you're calling to enter the shell environment.

Please let me know if this problem still exists.


Replacement error: enum cudaMemcpyKind kind -> hipMemcpyKindyKind kind

Fixed.
SHA-1: eddd021
[Solution] [Workaround]
Offset calculation for enum VarDecl as param decl, declared with enum type specifier.
[Result]
enum cudaMemcpyKind kind -> enum hipMemcpyKind kind
[ToDo]
Test on terminal qualifiers (const, etc).


Fix operation id by using proper conceal

This should be a solution for the https://github.com/RGB-WG/rgb-wallet/issues/36 issue. Please test it in your projects by adding
[patch.crates-io]
rgb-core = { git = "https://github.com/RGB-WG/rgb-core", branch = "fix/op-conceal" }

to your workspace-level Cargo.toml files
(of course you need to start with new stash and issuing new contracts, otherwise it won't work)

I tried reproduce the same tests I made here with this patch, but I receive the same error:
Error: absent information about bundle for operation 299dbb918982b15d302d20c988b6f2ad56279f988089a45a79cb44b5816e5951.
It may happen due to RGB library bug, or indicate internal inventory inconsistency and compromised inventory data storage.

I have the solution, but it requires some work.
In client-side-validation we have two main encodings: strict (strict_encoding crate) and commitment (CommitEncode, CommitmentId and commit_encode::Strategy traits from commit_verify crate).
The difference is that strict encodes data for persistence, and commitment just to hasher, producing hashes/commitments to the data.
For now commit-encode uses one of two strategies: either strict encoding, just writing to the hasher, or conceal-strict, where a conceal is first called and than a new structure with concealed data is written to the hasher. It is required to make sure that the commitment id does't differ between revealed and concealed variants - and the reason of the original issue was the use of strict strategy instead of conceal-strict strategy.
However, the new panic you've got is the fact that it is impossible to fully conceal fungible state since we do not have bulletproofs yet (which are required for the conceal procedure). So I have to abandon conceal-strict strategy and do a proper commitment encoding for all concealable data which do not rely on conceal procedure (since for instance we must not commit to bulletproofs, thus no need to produce them here, unlike a normal conceal). This means quite a lot of code to write (second encoding for most of RGB consensus data).
I will use a derivation macros for that, and for that need to create commit_encode_derive crate. Hoping to complete the task by Monday.

For now commit-encode uses one of two strategies: either strict encoding, just writing to the hasher, or conceal-strict, where a conceal is first called and than a new structure with concealed data is written to the hasher. It is required to make sure that the commitment id does't differ between revealed and concealed variants - and the reason of the original issue was the use of strict strategy instead of conceal-strict strategy.

Ok, sure. Thanks for explanation.

I will use a derivation macros for that, and for that need to create commit_encode_derive crate. Hoping to complete the task by Monday.

OK, Do you have anything I can help with?

OK, Do you have anything I can help with?

Not at this moment :( But later of course with making sure everything works as planned.

BTW, @dr-orlovsky, the conceal-strict strategy sounds like a keyed hash. Blake3 has support for this built-in. It is seeded by 128 bits, however.
https://docs.rs/blake3/latest/blake3/fn.keyed_hash.html
Very clever to separate hashing from serialization, btw!

It is not keyed or hashed per se. The keyed hashing is performed by CommitmentId calling CommitEncode which may use that strategy. CommitEncode works with any io::Write


Validation front-end design updates

This PR addresses three outcomes of Florence's design usability research into the Validation service with O&O.
Test Steps:

Ensure tests pass
Ensure the proper tables are displayed for the proper types of changes requested (errors and warnings)
Ensure consistency in banner placement (under the filename)
Ensure error messaging links to helpful resources (programmers guide, LIVD table doc)

Changes

Combines error and warning tables into single component with enumerated title for differentiation
No longer renders green banner when warnings are present
Banner content updates
Table header and column updates

Checklist
Testing

[x] Tested locally?
[ ] Ran ./prime test or ./gradlew testSmoke against local Docker ReportStream container?
[x] (For Changes to /frontend-react/...) Ran npm run lint:write?
[x] Added tests?

Process

[ ] Are there licensing issues with any new dependencies introduced?
[ ] Includes a summary of what a code reviewer should test/verify?
[ ] Updated the release notes?
[ ] Database changes are submitted as a separate PR?
[ ] DevOps team has been notified if PR requires ops support?

Linked Issues

Fixes #7124
Fixes #7125
Fixes #7126
Fixes #7127

To Be Done
Create GitHub issues to track the work remaining, if any

#issue

Specific Security-related subjects a reviewer should pay specific attention to

Does this PR introduce new endpoints?

new endpoint A
new endpoint B

Does this PR include changes in authentication and/or authorization of existing endpoints?
Does this change introduce new dependencies that need vetting?
Does this change require changes to our infrastructure?
Does logging contain sensitive data?
Does this PR include or remove any sensitive information itself?

If you answered 'yes' to any of the questions above, conduct a detailed Review that addresses at least:

What are the potential security threats and mitigations? Please list the STRIDE threats and how they are mitigated

Spoofing (faking authenticity)

Threat T, which could be achieved by A, is mitigated by M

Tampering (influence or sabotage the integrity of information, data, or system)
Repudiation (the ability to dispute the origin or originator of an action)
Information disclosure (data made available to entities who should not have it)
Denial of service (make a resource unavailable)
Elevation of Privilege (reduce restrictions that apply or gain privileges one should not have)

Have you ensured logging does not contain sensitive data?
Have you received any additional approvals needed for this change?

@TomNUSDS @fmccaf1 Went ahead and updated it for the external link in this PR. Definitely should make sure we have this set up for all external links


Postfix snippets from Luasnip are not expanded correctly

Make sure you have done the following

[X] I have updated to the latest version of blink.cmp
[X] I have read the README

Bug Description
When selecting postfix snippet it appears after TS "context".

Relevant configuration
snippets = {
      expand = function(snippet)
        require('luasnip').lsp_expand(snippet)
      end,
      active = function(filter)
        if filter and filter.direction then
          return require('luasnip').jumpable(filter.direction)
        end
        return require('luasnip').in_snippet()
      end,
      jump = function(direction) require('luasnip').jump(direction) end,
    },

neovim version
NVIM v0.10.2 Build type: Release LuaJIT 2.1.1727870382 Run "nvim -V1 -v" for more info
blink.cmp version: branch, tag, or commit
v0.7.6

I've found the solution for postfix snippets defined in Luasnip:
{
            ["<C-f>"] = {
                function(cmp)
                    vim.schedule(function()
                        local ls = require "luasnip"
                        if ls.expandable() then
                            ls.expand()
                        else
                            cmp.select_and_accept()
                        end
                    end)
                end
        }

<C-f> is used to expand a snippet. Wrap the entire thing in vim.schedule and postfix snippets are expanded correctly.

I would like to select elements without any additional keymaps.
I did similar workaround already, but it is annoying that I need to remember it.

I'm not sure what you mean. Do you mind giving an example?

Sorry I though you suggested new keymap just for it. I tried your solution and it seems working partially.
Still after selection of entry and pressing keymap behaviour is the same. Snipped is not being correctly expanded.

Can you please dump your entire blink.cmp config?

return {
  'saghen/blink.cmp',
  lazy = false, -- lazy loading handled internally

  version = 'v0.*',
  opts = {
    keymap = {
      preset = 'super-tab',
      ['<CR>'] = { 'accept', 'fallback' },
      -- fix attempt
      ['<C-g>'] = { function(cmp)
        vim.schedule(function()
          local ls = require "luasnip"
          if ls.expandable() then
            ls.expand()
          else
            cmp.select_and_accept()
          end
        end)
      end },

      ['<S-Tab>'] = { 'select_prev', 'fallback' },
      ['<Tab>'] = { 'select_next', 'fallback' },
      ['<C-n>'] = {
        function(cmp)
          if cmp.snippet_active() then
            return cmp.accept()
          else
            return cmp.select_and_accept()
          end
        end,
        'snippet_forward',
        'fallback'
      },
      ['<C-p>'] = { 'snippet_backward', 'fallback' },
    },

    completion = {
      trigger = {
        show_in_snippet = false
      },
      list = {
        selection = "auto_insert"
      }
    },

    documentation = {
      auto_show = false,
    },

    appearance = {
      use_nvim_cmp_as_default = true,
      nerd_font_variant = 'mono'
    },

    sources = {
      completion = {
        enabled_providers = function(ctx)
           -- providers func body
        end
      },
      providers = {
      -- non related providers
      },

    snippets = {
      expand = function(snippet)
          require('luasnip').lsp_expand(snippet)
      end,
      active = function(filter)
        if filter and filter.direction then
          return require('luasnip').jumpable(filter.direction)
        end
        return require('luasnip').in_snippet()
      end,
      jump = function(direction) require('luasnip').jump(direction) end,
    },
  },

  opts_extend = { "sources.completion.enabled_providers" }
}

I would recommend updating to the latest version first. Here's the updated config:
--- @type LazySpec
return {
    "saghen/blink.cmp",
    dependencies = "L3MON4D3/LuaSnip",
    lazy = false, -- lazy loading handled internally

    -- version = 'v0.*',
    ---@module 'blink.cmp'
    ---@type blink.cmp.Config
    opts = {
        keymap = {
            preset = "super-tab",
            ["<CR>"] = { "accept", "fallback" },
            -- fix attempt
            ["<C-g>"] = {
                function(cmp)
                    vim.schedule(function()
                        local ls = require "luasnip"
                        if ls.expandable() then
                            ls.expand()
                        else
                            cmp.select_and_accept()
                        end
                    end)
                end,
            },

            ["<S-Tab>"] = { "select_prev", "fallback" },
            ["<Tab>"] = { "select_next", "fallback" },
            ["<C-n>"] = {
                function(cmp)
                    if cmp.snippet_active() then
                        return cmp.accept()
                    else
                        return cmp.select_and_accept()
                    end
                end,
                "snippet_forward",
                "fallback",
            },
            ["<C-p>"] = { "snippet_backward", "fallback" },
        },

        completion = {
            trigger = {
                show_in_snippet = false,
            },
            list = {
                selection = "auto_insert",
            },
        },

        documentation = {
            auto_show = false,
        },

        appearance = {
            use_nvim_cmp_as_default = true,
            nerd_font_variant = "mono",
        },

        sources = {
            completion = {
                default = { "lsp", "buffer", "path", "luasnip" },
            },
            providers = {
                -- non related providers
            },

            snippets = {
                expand = function(snippet)
                    require("luasnip").lsp_expand(snippet)
                end,
                active = function(filter)
                    if filter and filter.direction then
                        return require("luasnip").jumpable(filter.direction)
                    end
                    return require("luasnip").in_snippet()
                end,
                jump = function(direction)
                    require("luasnip").jump(direction)
                end,
            },
        },

        opts_extend = { "sources.default" },
    },
}

I made blink.cmp depend on luasnip and commented out the explicitly specified version.
After updating the config, I would recommend that you delete blink through Lazy by running :Lazy, selecting blink and pressing x. Then blink will appear at the top under 'Not installed'. Hover your cursor over blink.cmp then press i to install and then it should work. If it doesn't, I would recommend installing from source by adding build = "cargo build --release" to instruct Lazy to build blink.cmp from source. Let me know how it goes!

For <CR> I have the following defined, which expands snippets as expected on my setup:
            ["<cr>"] = {
                function(cmp)
                    if cmp.is_visible() then return cmp.accept() end
                end,
                "fallback",
            },

When completion.list.selection is set to auto_select then additional dot is being added before snippet while picking option. It might be the reason why it is not working correctly in general.

When on manual or preselect mode the normal accept works partially, leaving the dot at the end of capture.

I'm not experiencing those issues at all, so unfortunately I'm unable to provide hints there.


No UWP support of Shell

This fact should be jumbotroned in the docs.
To me Shell doesn't exist so long it doesn't support UWP. It's disappointing to see how Xamarin.Forms, a Microsoft product, contributes to the fading of UWP.

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

ID: f64762a5-78e3-5c1e-b8b3-9572d66110f5
Version Independent ID: bb324623-2127-a5a3-d620-ebf314dfbf1a
Content: Xamarin.Forms Shell - Xamarin
Content Source: docs/xamarin-forms/app-fundamentals/shell/index.md
Product: xamarin
Technology: xamarin-forms
GitHub Login: @davidbritch
Microsoft Alias: dabritch

Hi @weitzhandler
It's already mentioned in the Introduction doc, nearly the top of the page.
If you want to make your views known, you should contact the engineering team or @davidortinau

FYI There is an issue open for UWP support.
https://github.com/xamarin/Xamarin.Forms/issues/5593


⚠ Bofrost.lu has degraded performance

In d229f05, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 952 ms

Resolved: Bofrost.lu performance has improved in 02268b8 after 15 minutes.


Ubuntu 22.04 container env Ansible provisioner fails; it seems ssh rsa won't be supported in the combination of Ubuntu 22.04 and Ansible provisioner

Describe the bug
Tried to run the latest packer plugin v3.0.0 under ubuntu 22.04 docker container, and got the failure with the ansible provisioner
To Reproduce
Steps to reproduce the behavior:
run packer plugin with ansible provisioner under ubuntu 22.04
Expected behavior
Ansible provisioner should not fail; Since Packer plugin creates SSH key, there should be some workaround in Packer Plugin or Ansible provisioner.
Screenshots
│     ibmcloud-vpc.ubuntu-focal: TASK [Gathering Facts] *********************************************************
│ ==> ibmcloud-vpc.ubuntu-focal: failed to handshake
│     ibmcloud-vpc.ubuntu-focal: fatal: [default]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: Unable to negotiate with <IP_ADDRESS> port 40097: no matching host key type found. Their offer: ssh-rsa", "unreachable": true}
│     ibmcloud-vpc.ubuntu-focal:

Please refer the AskUbuntu Q&A: https://askubuntu.com/questions/1409105/ubuntu-22-04-ssh-the-rsa-key-isnt-working-since-upgrading-from-20-04
There seems some workarounds ...

could workaround packer template for Ansible provisioner as mentioned in https://github.com/hashicorp/packer-plugin-ansible/issues/6#issuecomment-1044515290 :
  provisioner "ansible" {
    playbook_file = var.ansible_file
    ansible_env_vars = [
      "ANSIBLE_SSH_ARGS='-oHostKeyAlgorithms=+ssh-rsa -oPubkeyAcceptedKeyTypes=ssh-rsa'",
      "ANSIBLE_HOST_KEY_CHECKING=False"
    ]
  }

Another workaround can be adding the last two lines for the global ssh_config
ubuntu@d469a0e5c748:/iaas-tfp/02-packer-ubuntu-22.04$ cat /etc/ssh/ssh_config

# This is the ssh client system-wide configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options.  For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

Include /etc/ssh/ssh_config.d/*.conf

Host *
.
.
.
    PubkeyAcceptedKeyTypes +ssh-rsa
    HostKeyAlgorithms +ssh-rsa

It seems the issue can be seen only when the packer is running from a docker container ... if the packer is running from a VM, then it seems fine. I suspect there's something extra config to allow rsa key in sshd config.

I guess that the similar issue should have been observed in Fedora since they removed rsa option earlier...
It seems Hashicorp updated to support multiple option of ssh key type and bits : https://pkg.go.dev/github.com/hashicorp/packer-plugin-sdk/communicator#SSHTemporaryKeyPair

An informative thread : https://github.com/hashicorp/packer/issues/11733
AWS, GCP, and the other competitors have plugin level workaround: https://github.com/hashicorp/packer/issues/11733#issuecomment-1106564658
"temporary_key_pair_type": "ed25519",

Otherwise we have to enable ssh rsa globally.

The same error can also be produced on Mac. Took me a while to understand that the error needs to be fixed on the Mac side, not the image that is to be build.
I used the solution to add:
Host *
    PubkeyAcceptedKeyTypes +ssh-rsa
    HostKeyAlgorithms +ssh-rsa

to my local ~/.ssh/config file.

Works with ubuntu 22.4 along with an ansible provisioner is working fine.
@syyang-in-cloud, Could you comment if we still getting into this ?

@BShrivastav , we will still get the issue until IBMCLOUD supports multiple key types. I would like to keep this issue open until then, so that people from public can add the workaround and realize when they can remove that.
Thanks!

@BShrivastav , we will still get the issue until IBMCLOUD supports multiple key types. I would like to keep this issue open until then, so that people from public can add the workaround and realize when they can remove that.
Thanks!

@BShrivastav , we will still get the issue until IBMCLOUD supports multiple key types. I would like to keep this issue open until then, so that people from public can add the workaround and realize when they can remove that.
Thanks!

Works with ubuntu 22.4 along with an ansible provisioner is working fine. @syyang-in-cloud, Could you comment if we still getting into this ?

@BShrivastav , we will still get the issue until IBMCLOUD supports multiple key types. I would like to keep this issue open until then, so that people from public can add the workaround and realize when they can remove that.
Thanks!


Feature request: Print stdout/stderr before throwing

If I'm running a command with .quiet() or .stdout("piped").stderr("piped") and it fails, I just get an error like this:
error: Uncaught (in promise) Error: Exited with code: 1
            throw new Error(`Exited with code: ${code}`);

This makes it a bit of a pain to debug commands that start to fail for some reason.
I'm about to write a function for myself to

run the command with .noThrow()
check its result.
If the result != 0, print out its stdout/stderr
Then throw an error about the return code.

But it would be nice if this were built-in!
My preference would be for this to be on by default in cases where stderr/stdout are being suppressed.  But that might have performance implications for .quiet() which I'm guessing just sends outputs to /dev/null.  So maybe opt-in?  .debugThrow()? showThrow()?

Let me know if you'd be open to a PR here (and if you have preferences w/ the approach). I'd be interested in writing this up.

I'm not sure at the moment that another method should be added for this that's built in because I think how it should be handled is probably specific to the scenario. For example, the output of stderr might be quite large or the script might only show useful information on stdout for some reason. Also, since the output is piped, it might have been consumed by something else already.
Perhaps when the error is thrown it should also include the CommandChild and using that error someone could get the output on failure. Overall, it's a good suggestion, but it might be good to sit on this one for a bit.

when I get an error with dax, I usually just add $.setPrintCommand(true); at the top of the file, currently that's the best workaround available

I came up with the following to work around this. It works decently well, although you lose out on the text, json, etc. helpers on CommandBuilder since they essentially spawn internally. Would be nice if this was somehow built in to dax.
Usage:
const result = await exec($`some-command`);
const json = result.stdoutJson;

Implementation:
export async function exec(
  commandBuilder: CommandBuilder,
  captureOutput = true,
): Promise<CommandResult> {
  if (captureOutput) {
    commandBuilder = commandBuilder
      .noThrow()
      .quiet()
      .captureCombined();
  }

  const output = await commandBuilder.spawn();

  if (output.code !== 0) {
    const outputText = captureOutput
      ? output.combined
        .split('\n')
        .map((l) => `${' '.repeat(4)}${l}`)
        .join('\n')
      : '';

    throw new Error(`Failed to execute command\n${outputText}`);
  }

  return output;
}


run analyzer fails on run with cache

When I try to run the  run_analyzer on a run that configured to run with run_cache (no matter if there were cache hits or not) it fails with the following error:
File "omics/cli/run_analyzer/main.py", line 460, in
resources = get_run_resources(logs, runs[0])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "omics/cli/run_analyzer/main.py", line 257, in get_run_resources
return sorted(resources, key=lambda x: x.get("creationTime"))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '<' not supported between instances of 'NoneType' and 'str'
example to such run: arn:aws:omics:us-east-1:891377049375:run/9748207
I run the command without any flag:
python -m omics.cli.run_analyzer 9748207

Thanks for reporting this. Looks like this line of code needs to provide a default time if the creationTime doesn't exist so that the results can be sorted.
https://github.com/awslabs/amazon-omics-tools/blob/main/omics/cli/run_analyzer/__main__.py#L257C5-L257C66
I think in other parts of the code we have used the arbitrary default date of 1970-01-01

@avigailmo can you try the fix in #78 and let me know if that works for you?

@avigailmo can you try the fix in #78 and let me know if that works for you?

My try failed due the the engine issue I've raised: because the workflow doesn't exist anymore
I tried to set the engine to "WDL" hardcoded
then I got this for the run that ran with cache:

File "", line 198, in _run_module_as_main
File "", line 88, in _run_code
File "/Users/avigailmoldovan/dev/amazon-omics-tools/omics/cli/run_analyzer/main.py", line 579, in
"cpus": metrics["recommendedCpus"],
~~~~~~~^^^^^^^^^^^^^^^^^^^
KeyError: 'recommendedCpus'

yes, these's manifest log
will send it to you by email


Corrections required in Run to a Breakpoint section.

Step 6. The Startup Project needs to be FleetManagement, not FleetManagementMigrated. In addition, the FMRental_Upcoming Display Menu item needs to be set as the Startup Object.
Step 7. Needs to refer to the FleetManagement project, not FleetManagementMigrated project.
Step 11. It needs to state "The Current Rentals page will already be open in a new browser window". Sub-steps a, b, c, and d need to be deleted. Step d, which would now be a, should simply say "In the action pane, click Edit".

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

ID: d1906ec8-f80b-4e27-7320-57c68664e482
Version Independent ID: ab8d0951-67fe-3064-0f29-2524774e5b3c
Content: Build and debug projects - Finance & Operations | Dynamics 365 | #MSDyn365FO
Content Source: articles/dev-itpro/dev-tools/build-debug-project.md
Service: dynamics-ax-platform
GitHub Login: @pvillads
Microsoft Alias: pvillads

Bug 288970 has been logged to track this issue.

@tomhig, thanks for making us aware of this! I've fixed the issue, and an updated version of the page will be published soon.


Run script with sudo permission

@nrayapati ,
Sorry to bother you again
seems there is an issue with the script while running with sudo permission.
https://github.com/nrayapati/ssh-deploy-library/blob/c9f3059f90e50a3c62ba3a25e482458bfc6be975/vars/sshDeploy.groovy#L176
for command with sudo is working well but it's giving error for script.
case "scripts":
            sshScript remote: remote, script: command, sudo: isSudo

even I tried with def isSudo = true
Please have a look
Thanks in advance

It is not supported by plugin. https://github.com/jenkinsci/ssh-steps-plugin/blob/master/README.adoc#sshscript

I see, in original doc also it's not mentioned.
https://gradle-ssh-plugin.github.io/docs/#_execute_a_script
curious to know is there any other way where we can make it possible from below link
https://github.com/jenkinsci/ssh-steps-plugin/blob/84dbd0c90d37afa979f0f23c9396e99d1447f3b1/src/main/groovy/org/jenkinsci/plugins/sshsteps/SSHService.groovy#L193

Unfortunately we can't add sudo support for script as it is being streamed as a file. But you can achieve the same by sending (put) the script on to the box and use execute it as a sudo command.

I got it, I think this is the only way.
Thank you so much


Support replies in RespV3 format

Atm, all replies are sent back in the RESPv2 protocol.
We need to support RESPv3 as well

/assign


tools: Add a test for whether user has failed to run tools/update-locked-requirements after updating dependencies.

Fixes: #6324.

@timabbott I am unable to understand why this test produces a diff on master. I will try to debug this tomorrow but if you get a chance to look at this and throw some light that would be very helpful.

I see mypy errors, not a diff on master, when reading the Travis failures...

Oops I was running tests in a different order before creating the PR but while creating the PR changed the test order which caused the mypy errors to print out before the new test ran. Can you check out the following build or better try out in local dev by executing tools/tests/test-locked-requirements?

@timabbott The theory that we discussed was indeed correct. I made the required changes and it is working fine now.

@timabbott Updated.

This implementation looks great, but it's too slow.  I'm going to merge, but with this disabled in CI.  See https://github.com/zulip/zulip/issues/6969 for the follow-up issue to make this perform well enough.  I think my second idea in that PR (only running it if something has changed in requirements.txt since the last Travis run) shouldn't be too hard to do with caching in Travis...


Indigo renamed hwi switch gazebo plugin

requires https://github.com/ipa320/cob_gazebo_plugins/pull/6
includes #287 for completeness

visual review: OK

visual review: OK


Why was Maude removed?

It was the best wave rectifier in 0.6.2 - the most efficient. I used it all the time.

And here I thought nobody used it. I can bring it back in the next update. Cheers!

Added to 1.0.1 release!


Replace jsonServer.rewriter data with routes.json

The following
{
    '/quiz/:slug': '/quiz?slug=:slug'
}

in
server.use(jsonServer.rewriter({
    '/quiz/:slug': '/quiz?slug=:slug'
}))

should be replaced by the routes.json file.
An attempt was made to use path.join(__dirname, 'routes.json'), as the first argument to jsonServer.rewriter but this did not work.

@pfwd Can work with this one


dendrite: 0.13.3 -> 0.13.4

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for dendrite is: A second-generation Matrix homeserver written in Go
meta.homepage for dendrite is: https://matrix-org.github.io/dendrite
meta.changelog for dendrite is: https://github.com/matrix-org/dendrite/releases/tag/v0.13.4
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.13.4 in filename of file in /nix/store/mgadk0yx9fq1y64pxhnh98ix8blyka9l-matrix-dendrite-0.13.4

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
dendrite

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/mgadk0yx9fq1y64pxhnh98ix8blyka9l-matrix-dendrite-0.13.4 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A dendrite https://github.com/r-ryantm/nixpkgs/archive/1252a65d4e19b094db92baf06609073bbf76fbc4.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/1252a65d4e19b094db92baf06609073bbf76fbc4#dendrite

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/mgadk0yx9fq1y64pxhnh98ix8blyka9l-matrix-dendrite-0.13.4
ls -la /nix/store/mgadk0yx9fq1y64pxhnh98ix8blyka9l-matrix-dendrite-0.13.4/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

dendrite

Maintainer pings
cc @Ma27 @fadenb @mguentner @Ralith @dali99 @sumnerevans @NickCao for testing.

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

1 package built:

dendrite