JS Numeric types are wrapped if passed as object.

I've tried to implement fix for #349 - as was discussed, boxed numeric types are also boxed from Raw JS types in JavaScript.
This PR is still not ready for merging, but @kg, I'd like to discuss it with you and probably will need your help.

With this change dynamic work with numeric types was broken. Please look on DynamicBinaryOperators test for example. As dynamic variables are objects, integers are wrapped. I've not found how can I avoid this behavior, as I have no information that I'm processing translated dynamic CallSite in my WrapLiterals visitors - that information was stripped on function translation
Second problem is VerbatimVariablesExistingArray test. Integers inside object[] are wrapped, so probable Verbatim.Expression should unwrap them. On other side, it may not be a problem at all as can be solved inside expression by end user.

Then, not all problems are solved:

We still need resolve type based on it's information in translation-time if it is unwrapped - as you suggested in first comment to #349.
Type of expressions like (byte)12 incorrectly treated as Int32 - this information is lost inside ILBlockTranslator.Translate_Box method. Should discuss how we can solve it.

Also this PR will help us with calling numeric types interface methods.

Thanks for doing this. It looks like a good starting point. I'd like to rename Wrap to Box and UnWrap to UnBox. That will make it clear what's intended to happen here.
Ideally to match the semantics of .NET boxing/unboxing, we just introduce the idea of a box with a given type, and it becomes possible to box/unbox any given value type at runtime. (As an optimization, boxing a struct could just yield the struct, since structs are already references in JS. But we'd need to make sure it does a copy.) So instead of doing new T() and setting a special __Value__ property (from a JS perspective there are problems with this), we'd do roughly new BoxedValue<T>(v).
In this model, T.$Cast(b) where b is a boxed T would just work, so in many cases you could use that in order to handle object arguments. In cases where you have an object you want to unbox to a specific type without doing value conversions, I think we'd want to introduce T.$Unbox(b) which does a fast typecheck on the box and extracts a value from it. This could properly handle cases where no box is being used (like structs).
I'm... not sure JSIL.UnWrap should exist at all. I think they indicate the code in question is doing something it shouldn't, or doesn't have a clear sense of what it actually wants out of the type system.

I'm not sure that we really want mix .Net boxing and Raw JS-types wrapping. They looks very same, but their usage is different.
We don't want wrap any structure type - if we already created on JS side custom type for structure, it is fully enough and should not be wrapped (at least I don't see why may we need it).
At the same type, we may want wrap non-structure types in future - such as string and arrays (as otherwise we lost their type info).
Fortunately, all struct types that we want to wrap are immutable.
I don't understand what you mean when write new BoxedValue<T>(v) in JS-side.
If we will introduce some new special JS-side from for wrapped JS-types, it will not resolve one of this PR task - we need some solution to simplify call of interface methods on such structures (or I just don't understand how it will work :) ).
I'm fully agree that each JSIL.UnWrap usage indicates some issue in our code, but it is helpful now where we do something bypassing our type system (as in Format function in JSIL.Bootstrap.Text.js) or when method should be able to work with both forms of type (implementation of Int32/Float/Char/etc methods). Probable we need find some other solution and get rid of JSIL.UnWrap.

@kg, are you suggesting implement boxing for any structure type when we see box il-command?

Right now we ignore box/unbox operations, which is a mistake. I think it should be possible to replace every case where we need to identify the type of a value at runtime with boxing or compile-time type information. Overload resolution is solved by storing the compile-time type info, for example. The other piece of the puzzle is type information for local types. But I think that's fixable too.
So I believe if we implemented box correctly such that any time a primitive is converted to object, it gets boxed... that should fix almost everything in this area we care about. The rest of the issues are probably JSIL bugs that change .NET semantics.
I need to think more about this though.

In .Net, boxing is operation, that converts value-type to reference-type.
On JS side all types are already reference and value-type semantic is emulated. So, we don't need convert anything explicitly (on other side, it may simplify struct-emulation logic and resolve some problems in it).
Right now we have problems with type detection (and method invocations) on small number of types, that we store in native JS-types: ? T[] ?, ? string ?, bool, char, sbyte, byte, short, ushort, int, uint, float, double, decimal.
I'm pretty sure that local variable type resolution could be simple resolved with proxies (will try to do it to prove).
If you want to translate all box/unbox, this logic should be moved from FunctionTransformPipeline step to IlBlockTranslator. I afraid to do it, as it may break sensitive struct-emulation logic and a lot of other pipelines steps, that I don't know good enough. :(
#349 that I've tried to solve here is blocking me of moving from JSIL BCL class implementations to fully translated BCL with preserving only minimal subset of JS classes inside Libraries folder. Ideally, their will be special parameter - UseJsilBclImplementation, that will prevent (if false) from loading most JSIL.Bootstrap.* (some of JSIL.Bootstrap.* files should be split for it).

Can you call out some specific BCL methods affected by this (or provide them as tests) so I can make sure I fix it one way or another?

Expression.Constant(0d, typeof(double))

Looks like I once again partially blocked by this problem. Now I have problem when try cast Numeric type to IConvertible.
Even when I implemented IConvertible members, cast/is operation will still fail - as raw JS type has no __ThisTypeId__.
Let's discuss once more Boxing/Wrapping solutions and problems that they solve:
Wrap

Applicable only to types (both struct/classes) that translated as JS native types (Numbers, String/Char, array?)
Wrapped when source is passed as object/interface type, story original type information

Box

Applicable to all structs when they passed as object/interface
Store information about source object type. Do we really need it for non-raw JS objects? What problems will it solve?
How it will work for generics with type constraint (as there will be no box command in IL), i.e.:

using System;

public static class Program
{
    public unsafe static void Main(string[] args)
    {
        Console.WriteLine(Sampe(10));
    }

    private static short Sampe<T>(T input) where T : IConvertible
    {
        return input.ToInt16(null);
    }
}

At the same time, using new BoxedValue<T>(v) in JS instead of Value field  may work in Wrap solution also.

I think we only care about types that are translated as JS native types. So: numbers, char, string, array. We need to maintain the JS protocols, though, which is a real problem. I think our only choice there is to not wrap strings or arrays. For arrays, we can probably attach type information to them with a weakmap or a custom named property (the latter works alright in engines now, I believe). For strings I think we will stick with JS String and just have to deal with the fact that they don't ever have referential equality. (Though maybe str[i] works on new String in JS? I've never tried.)
So I think the path forward looks mostly like what you have here with wrapping. We have a generic 'box' type, maybe just an improvement on the one currently used for ref/out vars, and it is used to store boxed numeric types (including char). We switch char over to a numeric type.
The box type will need to get smarter: toString and valueOf on it will need to be implemented appropriately, such that 'hello' + (new Box<char>(33)) produces 'hello!'. I think that's probably not too hard to do, though. Most (all?) of the code JSILc generates won't rely on that property, but we want to make sure JS interop scenarios don't end up totally hosed. There will definitely be issues where JS grabs an unboxed numeric type out of a field and passes it back into C#, but I think that will just be a place where JS needs to obey protocols when dealing with JSIL data structures (maybe in special cases we can have an attribute that forces fields to always be boxed so it's safe for JS to touch them.)

@kg, looks like we already have "JSIL.BoxedVariable", but I'm not fully understand when and what for we use it.

It's a ref cell for ref/out parameters.

I'm working on new version based on our discussion. Looks like I will complete it today. One still open question is performance. Here is UnsafeIntPerformanceComparison test. As TestInlineAccess use Verbatium, int passed as argument was boxed (it could be easily fixed with creating several generic Verbatium methods with 1-10 args). Let's look on performance in Chrome (in IE and Firefox it is nearly same):
Original version:
    var pBuffer = JSIL.PinAndGetPointer($thisType.Buffer);
    var offsetInElements = pBuffer.offsetInBytes >>> pBuffer.shift;

    for (var i = 0; i < 1048576; i = ((i + 1) | 0)) {
      pBuffer.view[(offsetInElements + i) | 0] = (i % 255) | 0;
    }

Box version:
    var pBuffer = JSIL.PinAndGetPointer($thisType.Buffer);
    var offsetInElements = pBuffer.offsetInBytes >>> pBuffer.shift;

    for (var i = 0; i < 1048576; i = ((i + 1) | 0)) {
      pBuffer.view[(offsetInElements + $T00().$Box(i)) | 0] = ($T00().$Box(i) % 255) | 0;
    }

Original version:  00505.00ms
Box version: 186131.00ms
It's awful. According to profile, all time was spent for only arithmetic operation - $Box and valueOf has taken very small part of it.
And now strange thing. If I put breakpoint in this function before cycle and execute same cycle from Developer console, it takes about 2000ms for original version and 12000ms for box version. Looks like there are some problems inside optimization :(
May be it is not very big problem - as we should not use boxed form a lot, but it really strange.

It's fine if TestInlineAccess isn't fast anymore, it's just a hack. That is
a tricky downside to boxing though, and could affect other
performance-sensitive code.
On 8 October 2015 at 15:10, Igor Kiselev<EMAIL_ADDRESS>wrote:

I'm working on new version based on our discussion. Looks like I will
complete it today. One still open question is performance. Here is
UnsafeIntPerformanceComparison test. As TestInlineAccess use Verbatium,
int passed as argument was boxed (it could be easily fixed with creating
several generic Verbatium methods with 1-10 args). Let's look on
performance in Chrome (in IE and Firefox it is nearly same):
Original version:
var pBuffer = JSIL.PinAndGetPointer($thisType.Buffer);
var offsetInElements = pBuffer.offsetInBytes >>> pBuffer.shift;

for (var i = 0; i < 1048576; i = ((i + 1) | 0)) {
  pBuffer.view[(offsetInElements + i) | 0] = (i % 255) | 0;
}

Box version:
var pBuffer = JSIL.PinAndGetPointer($thisType.Buffer);
var offsetInElements = pBuffer.offsetInBytes >>> pBuffer.shift;

for (var i = 0; i < 1048576; i = ((i + 1) | 0)) {
  pBuffer.view[(offsetInElements + $T00().$Box(i)) | 0] = ($T00().$Box(i) % 255) | 0;
}

Original version: 00505.00ms
Box version: 186131.00ms
It's awful. According to profile, all time was spent for only arithmetic
operation - $Box and valueOf has taken very small part of it.
And now strange thing. If I put breakpoint in this function before cycle
and execute same cycle from Developer console, it takes about 2000ms for
original version and 12000ms for box version. Looks like there are some
problems inside optimization :(
May be it is not very big problem - as we should not use boxed form a lot,
but it really strange.
—
Reply to this email directly or view it on GitHub
https://github.com/sq/JSIL/pull/773#issuecomment-146700836.

I'm much more curious why it works 15 times faster from developer console. It really looks like a bug in JavaScript optimizer. Probably we need to file some tickets :)


Add URL location for s3 wallet store

Hello!
Currently, if I use s3 wallet store, I can't control a bucket name/location via dirk. We can pass only password to go-eth2-wallet-store-s3 library. This library itself also can't point to a predefined bucket, it determines the name of the bucket via AWS_ACCESS_KEY_ID hash.
I see this problem with that approach:

We need to add permission s3:CreateBucket with Resource:* to dirk SA (or we need to precalculate hash for AWS_ACCESS_KEY), or change that after bucket was created
We can't rotate AWS_ACCESS_KEY_ID or use metadata service for getting that because if it will be changed we will create a new empty bucket (so we need manually copy all data from old bucket to a new one)

It would be a good if:

We already have location field in store structure (which is used for file system type store), and we can use that to point out an endpoint for aws-s3-sdk
If we could use the location field for that, we would be able to control not only bucket name, but also the whole URL (endpoint in AWS SDK), so we would be able to use any s3-compatible services as s3 store.

Can you provide some examples of URLs as location that could be used in place of the region and auto-generation of bucket names, for both S3 and another S3-compatible store, so that I can take a look at this?  Thanks.

Yeah, S3 protocol is based upon REST API, so generally all S3-compatible storage has path like https:/[bucket].[endpoint]/[path] (AWS and GCS in interoperability mode) or https:/[endpoint]/[bucket]/[path] (MinIO, path style).
AWS S3 SDK constructing URL by itself, where the first style is default one but the second style could be constructed with WithS3ForcePathStyle
Default endpoints:

AWS S3: https://s3.amazonaws.com
GCS: https://storage.googleapis.com
MinIO: could be anything in both formats due to reverse proxy

Currently AWS SDK requires region anyway, so we need to configure 4 params:

Endpoint
Region
Bucket name
Path (folder where to store all data)

While testing aws-sdk I understand, that encode that in one string (for example, like https://[bucket].s3.[region].amazonaws.com is not a good thing because a lot of assumptions, mess with classic sdk variant and split/join actions...
So maybe just add all these parameters in dirk config in majordomo style:
s3:
  endpoint: <endpoint>
  region: <region>
  bucket: <bucket>

stores:
- name: Remote
  type: s3
  location: s3://<path>

If config haven't s3 section or/and location in stores, dirk could use current approach, but if it exists - use a new one where dirk will use a existing bucket. Endpoint/region may be an optional with AWS defaults (like right now).
But ideally I want to have a lot of s3 storages, so maybe do like that:
s3:
  aws:
    endpoint: <endpoint>
    region: <region>
    bucket: <bucket>
  <any template>:
   ...
stores:
- name: Remote AWS
  type: s3
  location: s3://<path>
  template: aws
- name: Remote
  type: s3
  location: s3://<path>
  template: <template>

Initial work for this features is at https://github.com/wealdtech/go-eth2-wallet-store-s3/pull/1 please can you review this and, if possible, test it by taking a local copy and modifying the tests in TestStoreAccount in the account_test.go file to see if this works correctly in all of your required situations?

Yeah, I will try to test that tomorrow, leave a message about that here. Thank you!

Just checked it with AWS S3 and Google Cloud Storage (both with precreated bucket and not) - it works perfect!
With GCS I also can manage bucket type (multregions, regions and so on) via region parameter, so it's cool!

Just checked it with AWS S3 and Google Cloud Storage (both with precreated bucket and not) - it works perfect!
With GCS I also can manage bucket type (multregions, regions and so on) via region parameter, so it's cool!

This has been merged in its repository, however will take a while to work its way through to Dirk itself as there are various other changes going on as well.  I will leave this open until then.

The code for this now exists in #35 please take a look and ideally run it locally to see if it meets your requirements.


Add types to exports/./import to support Typescript Node16

Before this Typescript would fail to resolve the types for the package when configured to use module: "Node16" (new in Typescript 4.7).
main.ts:1:26 - error TS7016: Could not find a declaration file for module '@js-temporal/polyfill'.
Repro available at https://github.com/jonasb/typescript-error-repro/tree/typescript-4.7-esm-node16-js-temporal

Thanks for the PR, and for creating a repro.
Looking around the community, this seems like it's unfortunately intentional (https://github.com/microsoft/TypeScript/issues/46334#issuecomment-981876926 implies that if there is an exports object that a types key is now required in the exports object instead of falling back to the top-level types). Seems similar to https://github.com/framer/motion/issues/1543.
I patched your PR and tested against a couple small test projects and they seem to compile/run just fine, so I think this is fine to merge.

I hit  Could not find a declaration file for module '@js-temporal/polyfill' today and this change fixes the error. When will this be published to npm?

I've been in the middle of merging a bunch of upstream fixes, but that might take longer to release so I'll put together a patch release with this fix sometime in the next day or so.

@jonasb  it seems this might not have fixed things, based on the report in #177 ? Can you verify that this PR did fix things for your repro?

I can confirm it's fixed for my use case.


Modify np.testing.assert_almost_equal() called in test_simulate_rando…

…m_unitary() to take 'decimal=6'
Fixes: https://github.com/quantumlib/Cirq/issues/1425

The bot is busy working its way through other merges (the windows builds are painfully slow). It will merge to master when needed, to avoid bogging down Travis-CI.


Card Text Not Persisting

When I save text into a card and then re-load the page, the cards are still there, but they are blank.
I've tested this with the github hosted version and running the code on OSX.  I've tested from Safari, Firefox, and Chrome.

I am looking at this issue now. I couldn't figure out what is happening yet.
I tried to use old versions of the code, change firebase app, still couldn't find.
Will keep you posted here about my progress...

Apparently it's an issue with backface-visibility that it is not working well on chrome. I disabled the card animation for now so it should work fine. I will work more on this later.

I pulled the latest commit from master and I'm still seeing the issue locally.  Am I missing something there?

Never mind, I see the other branch.  Working locally now.

Yeah master is still breaking, I will try to fix it this week

What branch should I be using?

gh-pages


Upgrade to cryptography ~= 44.0

cryptography 44 removes a bunch of ABCs that we currently use, so this will be a non-trivial bump.
xref https://github.com/sigstore/sigstore-python/issues/1231 (this is not related directly to the breakage there, since the TSA changes haven't landed in a release yet).

I've updated dependabot's PR https://github.com/trailofbits/rfc3161-client/pull/75/files but I think we are already good because we don't use any of the removed APIs.

#75


[AppService] Command changes for ASE v3 GA

Description
For ASEv3 GA, there are some changes, most noticeably that External ASE is now supported, and the need for private endpoint for inbound traffic is removed and now using an Azure Load Balancer like ASEv2.
ase create-inbound-services will now only create a Private DNS Zone thus the --skip-dns is not relevant. The API for getting inbound IP for ASEv3 is in azure-mgmt-web 3.0.0 and require an SDK upgrade before this can be supported.
Testing Guide
az appservice ase create --kind asev3 ...
History Notes

[AppService] az appservice ase create: Support for ASEv3 External

This checklist is used to make sure that common guidelines for a pull request are followed.

[x] The PR title and description has followed the guideline in Submitting Pull Requests.

[x] I adhere to the Command Guidelines.

[x] I adhere to the Error Handling Guidelines.

AppService

Could you add some tests to these changes?

Hi @zhoxing-ms, I have addressed your comments. Thank you for looking into the changes.


VersionedSignedProposal.assertMessagePresent() does not check phase0 or altair

We believe this function https://github.com/attestantio/go-eth2-client/blob/5a33417f219e12762e182e3844efd521299f4d5a/api/versionedsignedproposal.go#L248C10-L248C55 shall allow phase0 and altair messages. Right now this returns ErrUnsupportedVersion for such proposals, which seems wrong.
cc @mcdee

Discussed offline.


[SDK review] Add ability for an Admin to confirm the meeting scheduled

We are waiting on this issue once we have more information on the flow the admins want for the SDK Review

This is no longer needed. We are going with the approach on https://github.com/Azure/azure-sdk-tools/issues/4671


Move to MavenCentral or JetBrains Space

Currently, kotlinx-uuid is released on Bintray, which will be closed on May 01.

@cy6erGn0m Did you remove this artifact from JCenter? Suddenly, all requests are forbidden.

@cy6erGn0m Did you remove this artifact from JCenter? Suddenly, all requests are forbidden.
Edit: Bintray is on maintenance, https://status.bintray.com.

No, didn't. Actually, jcenter is going to stop working at some point so we need to think of migrating to somewhere

Any updates?

@andreypfau You could use my fork: https://github.com/hfhbd/kotlinx-uuid


Warning for "missing width" for images with Next 12

With Next 12, we see a lot of warnings in the console for missing width of the images.

This issue is because of the next-sanity-image plugin we are using and they have an open issue about this in the repository

Upgraded to v3.1.8 which should fix this issue, but I'm still seeing the warnings. Will investigate further to see if there is something in our implementation.

I can't figure out the problem in this, it seems like there are issues with at least:

Topic page hero image
Image component (both full-width and not full-width)
Quote image

While it doesn't seem to happen with at least:

Teaser image
Promotion card image (news and topic)

There is no clear difference between how these images are implemented, but the results are consistent so there is clearly something going on there. Doesn't seem to be a problem with a specific document either, because the same happens when creating a new topic page.

There's no warnings if we create an image without the option callback with Sanity ImageUrlBuilder. When the options object is added, even with the most basic example from the docs, the warnings show up.
I have asked Sanity for some input on this and they will look into this

Opened another issue in the plugin lib
https://github.com/bundlesandbatches/next-sanity-image/issues/31
It was not that easy to just fix this at our end.

So... Dead silence. I'll spend some time just to see if we can remove this lib all together

Too much work for now to remove the lib IMHO. I have suffixed with at width, it shouldn't actually affect the image pipeline of Sanity but still makes Next.js happy. Let's see if it's updated in the library at some point, but closing this for now. OK @SvSven ?

I can't see the warning in either the browser console or the server console, so looks to be fixed by this 👍


Document OpenShift service certificates for Operator deployments

MinIO Operator on OpenShift may require manual configuration of TLS cert management via the OpenShift service-ca Operator. (For deployments that are not done through Red Hat OperatorHub.)
Document the needed envvars, volumes, and volumeMounts to enable service-ca and avoid the need to manually renew certs.
Note: This presumes kustomize, additional research/testing required to determine configuration for Helm chart deployments.
Staged
http://<IP_ADDRESS>:9000/staging/DOCS-991/openshift/operations/installation.html#procedure
See also: https://github.com/minio/wiki/wiki/Besides-MINIO_OPERATOR_RUNTIME-what-else-is-needed-in-Operator%3F
Fixes https://github.com/minio/docs/issues/991 (remaining item for v5.0.8)

I know this is a draft, but I loved the way it looks in the web page provided at: http://<IP_ADDRESS>:9000/staging/DOCS-991/openshift/operations/installation.html#configure-tls-certificates
This to me looks good!


[Bug]

Describe the bug
def swagger_auto_scheme(doc_scheme, content_type='application/json', gen_app_headers=True):
def inner(func):
openapi.summary('111111111111111111111111')(func)
openapi.body(content=BaseResponse)(func)
return func
return inner
@swagger_auto_scheme(test)
async def test(request):
pass
Adding body overrides summary and is normal if not added

I want to put the body method in my own decorator, it doesn't seem to work, I don't know why

Please use markdown's features to format your code. I am putting a guess here -- this is done by putting a line ```python before the code and a line ``` after it:
def swagger_auto_scheme(doc_scheme, content_type='application/json', gen_app_headers=True):
    def inner(func):
        openapi.summary('111111111111111111111111')(func)
        openapi.body(content=BaseResponse)(func)
        return func
    return inner

@swagger_auto_scheme(test)
async def test(request):
    pass

This code looks confusing -- you seem to be both defining a function named test and using something imported named test.

@hu0514 what exactly is openapi? Where are you importing it from? Please include all the imports with your code sample and fill in ALL the fields in the bug report template, such as expected behaviour and explaining how that's different to what's happening.


Will #Vault7 permit flashing ATT Galaxy Notes?

ATT has a lot of bootlocked phones. The Wikileaks #Vault7 release has instructions to bypass this in the Cadmium document.

Cadmium is an exploit targeting a vulnerability in the Exynos Android bootloader which enables the persistent booting of an unsigned Android boot image. This document will cover the details of the Exynos bootloader vulnerability, how Cadmium exploits this vulnerability, and how one can port Cadmium to different devices/firmwares.

Will Heimdall be able to make use of this?
https://security.stackexchange.com/questions/153225/does-cadmium-in-vault7-enable-custom-roms-on-all-atts-samsung-phones

Short answer, no.
This sounds like a discussion for a forum, not an issue tracker.


Unable to understand environment of post-receive

Gitea version (or commit ref): 5f4210a

Description
(I'm knowingly breaking the template reporting style, as this issue is a feature/documentation one which doesn't depend on specific backend versions or setup. Sorry!)
Here's what I'm trying to do: I'm a user of a Gitea instance hosted by the organisation where I work. As a normal user, I don't have access to the backend or the server running Gitea. I would like to setup a repository in Gitea, which is automatically mirrored to GitHub through a post-receive hook.
What I'm not understanding, or missing, is information about what the environment looks like in post-receive hook, and how I can set it up to include a private SSH key to access GitHub. Setting up the mirror and triggering the update of the mirror manually is not a problem, when I do so from my own terminal, so I have the right credentials for GitHub available.
But on the Gitea side, when the post-receive triggers, it doesn't, naturally, have my credentials to
GitHub and thus fails miserably. I've looked and looked, but I can't find a way in Gitea to include anything in the environment of the post-receive hook which would help me here.

You should create private token and use https auth to push to github, it is not recommended practice to store ssh private keys on the server

Also for questions please use Gitea Forum (https://discourse.gitea.io/)

Cool, didn't know about discourse, @lafriks. Will move followups question there.


tarexport: check symlink error when saving layer

Noticed this when reviewing #28926. Anything could happen when symlinking.
cc @tonistiigi

LGTM


multiline matches with CR (^M) characters

Describe the bug
I think only the title of git commit messages should be considered, but when the commit contains mixed CR/LF for some reason, extraction of commit title would be broken, resulting into multi-line messages (with CR) printed in the release note.
To reproduce
git clone https://github.com/neovim/neovim
git cliff -c c.toml 72a6643b1~1..ca5de93

c.toml:
[git]
conventional_commits = true
filter_unconventional = false
filter_commits = false
commit_parsers = [
    { message = "^.*", group = "Others" },
]

[changelog]
body = """
{% for group, commits in commits | group_by(attribute="group") %}
    ### {{ group | upper_first }}
    {% for commit in commits%}\
       - <<< {{ commit.id }} >>> {{ commit.message | upper_first }}
    {% endfor %}\
{% endfor %}\n
"""

Output:

### Others
- <<< 72a6643b1380cdf6f1153d70eeaffb90bdca30d6 >>> Docs #24061

- nvim requires rpc responses in reverse order. https://github.com/neovim/neovim/issues/19932
- NVIM_APPNAME: UIs normally should NOT set this.^M
^M
ref #23520^M
fix #24050^M
fix #23660^M
fix #23353^M
fix #23337^M
fix #22213^M
fix #19161^M
fix #18088^M
fix #20693
- <<< ca5de9306c00d07cce1daef1f0038c937098bc66 >>> Inlay hints #23984

A strange commit 72a6643b1380cdf6f1153d70eeaffb90bdca30d6 has a commit message where CR and LF is mixed.
Expected behavior
Only the first line is considered. Maybe we should normalize CR, LF into LF.
Screenshots / Logs
N/A
Software information

Operating system: macos
Rust version: 1.70
Project version: 1.4.0

Additional context
This repro is a simplification of https://github.com/neovim/neovim/pull/26818 where git cliff --config scripts/cliff.toml v0.9.0..HEAD produces some strange multi-line release note items.

Hello, thanks for reporting this!
This is because the commit in question is not conventional and it is not filtered out. That is why git-cliff uses that commit in the changelog as-is.
To skip those commits:
filter_unconventional = true

If you only want the first line to appear in the changelog:
- <<< {{ commit.id }} >>> {{ commit.message | split(pat="\n") | first | upper_first | trim }}

You can also use commit preprocessors/postprocessors to process the commit/changelog.
When it comes to the actual question, I agree that we should normalize CR, LF into LF. That can be also done with pre-processors though. I'm not sure if git-cliff should manipulate the commit message internally in this case.

Q: Is the regex ^foo matched against each of the lines or against the very first few characters only? I thought it should be latter, but I don't still understand why this multiline string appears. Other commits also have a body that follow the title, but they won't appear. What makes the difference?

Q: Is the regex ^foo matched against each of the lines or against the very first few characters only?

It is matched for the first line since it is not configured as multi line. I also think that it should support multiline but I'm not sure how to achieve that with serde_regex:
	/// Regex for matching the commit message.
	#[serde(with = "serde_regex", default)]
	pub message:       Option<Regex>,

Feel free to open a tracking issue about this!

Other commits also have a body that follow the title, but they won't appear. What makes the difference?

feat(lsp): inlay hints #23984 is a conventional commit so only the "Inlay hints #23984" parts makes it into the changelog. You can use commit.body to access the rest of the commit message.
docs #24061....... is not conventional so the entirety of the commit appears in the changelog.

I hope this answers your question 🐻


verify azure cmd doc updates

Description
What this PR does / why we need it:
This updates docs/examples/ratify-verify-azure-cmd.md  to work with the latest ratify changes as well as notation RC1.

updates the notation version to RC1
cleans up formatting and installs for consistency
updates SBOM artifact type to org.example.sbom.v0
fixes config policy in the Demo 2 by removing org.example.sbom.v0
updates verification certs in config to path ~/.config/notation/truststore for consistency (previously, it specified different paths for each demo)

NOTES:

This doc currently instructs the user to use Ratify v1.0.0-beta.2 as RC1 has not been released yet. We should update this when RC1 is released

When https://github.com/deislabs/ratify/pull/536 gets merged we should update this doc to use the sbom-tool and update the media type of the sbom accordingly.

Type of change
Please delete options that are not relevant.

[X] Documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Please also list any relevant details for your test configuration

Manual testing. Ran through the doc from scratch and it works as expected

thanks for making the doc update. Notation rc.2 seems coming soon, I wonder if you want to wait for it.

thanks for making the doc update. Notation rc.2 seems coming soon, I wonder if you want to wait for it.

No problem if you want to wait. I am also happy to come back with a follow up PR once Notation rc.2 lands.

thanks for making the doc update. Notation rc.2 seems coming soon, I wonder if you want to wait for it.

No problem if you want to wait. I am also happy to come back with a follow up PR once Notation rc.2 lands. Just curious do you know what date Notation rc.2 will be released?

RC.2 might be delayed to Feb. 6. I feel it's OK to merge it now since we're not urgent to bump up notation to RC.2.

@joshuaphelpsms could you merge latest changes from main?

@joshuaphelpsms could you merge latest changes from main?

@akashsinghal Just merged


AutoSizeColumn not working

I am using this article
https://www.codeproject.com/Articles/1241654/Export-to-Excel-using-NPOI-Csharp-and-WEB-API
Code is almost same in dotnetcore, and I can compare and _sheet.AutoSizeColumn is not working at all.

Same problem here. Method call makes some adjustments of column width, but column value text is still covered by adjacent columns.

See https://github.com/dotnetcore/NPOI/issues/77#issuecomment-428994994

Any updates on this?

@alex-vance You may want to check if it's fixed in the upstream repo (tonyqus/npoi) since netstandard support was released. AFAIK it hasn't been touched here.


New Taxon Name Task - Relationship Soft Validation

When exercising with homonyms we created a New Taxon Name: Jivarus viridis by Braun, 2008. This name already existed for another species, Jivarus viridis Ronderos, 1979. So,from the J. viridis Braun, 2008, we create the relationship with J. viridis Ronderos, 1979, primary homonym.
Then we create a new name for the Braun species, Jivarus elegans Pocco, 2015.
From Braun`s viridis species we create the relationship with this new name, replaced by Jivarus elegans Pocco, 2015.

And we Edit the relationship of Poccos name with Brauns one. Nomen novum for Jivarus viridis Braun, 2008.
In the Soft Validation for this name, for Relationship appears the message: **Jivarus elegans Pocco, 2015 and Jivarus viridis Braun, 2008 are not similar enough to be homonyms. **

But as they are not homonyms we wonder what is the Taxon Works program interpretation.

If required please provide answer in taxonworks_doc.

I will check it, looks like a bug.
Although, nomen novum relaitionship is not required, Replaced by relationship should resolve the names correctly.


Commit hook to bump db version on write [4/n]

The db version global always points to the next db version.
This means that all triggers can use the current value for their writes and on transaction commit, we'll bump the cached db version in preparation for the next write.
dbversion is an atomic int and threadsafe.
test plan:
sqlite> select cfsql_dbversion();
-9223372036854775806
sqlite> create table foo (a);
sqlite> select cfsql_dbversion();
-9223372036854775805
sqlite> insert into foo values (1);
sqlite> select cfsql_dbversion();
-9223372036854775804

likely superseded by #12


Loading data should really strip spaces and handle quotes properly.

This test demonstrates the problem:

@pytest.mark.skip("This is annoying.  it's easy for CSVs to have quotes and spaces, but the combination is bad.")
def test_load_quoted_values(tmpdir):
    source = tmpdir / 'quoted_values.csv'
    with open(source, 'w') as f:
        # Importantly, Active is quoted AND has a space before it.
        f.write("""id,name,status\n1,"Jean-Luc Picard", "Active"\n""")
    phase= Phase()
    phase.load(source)
    # If values are not stripped of space and converted, status = ' "Active"'
    assert phase.row_data[0]['status'] == "Active"

If this isn't fixed, it's all too easy to have a bug in the pipeline.  I encountered this in the employees.csv and employees pipeline work, where paidPer = ' "Year"' instead of 'Year', so the code failed to calculate salary correctly.

Likely fixed as part of #78

This is now addrssed where Phase does column name canonicalization.
Also I'm leaving the test in the io/csv test section because if this ever changes
we'd like to know.


Snapshot release

Issue: https://github.com/atlassian/changesets/issues/327
Implementation:
$ yarn changeset pre snapshot <tag>

I don't understand what pre means. Why cannot it be called changeset snapshot --tag <tag>? I guess it would make sense to even include publish in there, to make it clear that a publish will happen: changeset publish-snapshot --tag <tag>

pre means pre-release. The reason it's called changeset pre snapshot is that it's a snapshot pre-release.

It seems to me as well that including "publish" somewhere in the command would make it easier to understand for newcomers, even at the cost of some added verbosity.

Okay, let's make it changeset publish-snapshot <tag>

Thanks for the feedback everyone. :)
Tasks that I am completing now:

[ ] Update the command to changeset publish-snapshot <tag>. https://github.com/atlassian/changesets/pull/359#issuecomment-627022902
[ ] Add a flag no-publish passing which will only make the changes in the file and skip publishing. https://github.com/atlassian/changesets/pull/359#discussion_r423251801
[ ] Simplify the ternary statement/ code where necessary. https://github.com/atlassian/changesets/pull/359#discussion_r423252723

I am going ahead with working on change but please feel free to discuss if you think something should be added or updated.

Currently, regular versioning and publishing scripts are separate - IMHO it would make sense to stick to that here as well without introducing no-publish flag or similar because it deviates from the standard usage.
My alternative proposal would be to add --snapshot flag to both version and publish commands. You need to rethink if it makes sense to call publish --snapshot tag without previously calling version at all, but seems to me that it shouldn't create much of a problem and maybe would be useful on its own for somebody.
Q: why this has been bound to pre mode? Wouldn't it make sense to allow this outside of it? One could setup snapshot releases on each pr/commit without ever entering the pre mode - this use case seems useful.

A: Snapshot release does not have to bound to pre release, it is just the significance that pre defines a pre-release. User does not have to be in pre mode snapshot release.

Yes, I like the idea of changeset publish --snapshot tag, it read clear to me of what it does but then users will not able to use their own publish script. like mentioned in https://github.com/atlassian/changesets/pull/359#discussion_r423251801, any opinions on this?

Continuing on suggestion of keeping the version and publish separate I see this as:
$ # Gives a version as 0.0.0-<hash>, but does not commit the files no matter the config
$ changeset version --snapshot
$ # Publish command supports the tag option, this overrides config for publish - default as latest
$ changeset publish --tag <tag>

Opinions?

It makes to me, thanks.
To summarize, let me try to apply this to some examples:
Publishing to latest (default)
changeset version
changeset publish

Publishing to next dist-tag instead of latest
changeset version
changeset publish --tag next

Publishing canary releases
changeset version --snapshot
changeset publish --tag canary

Publishing in "pre" mode
changeset pre enter next
changeset version
changeset publish

Did I get this right?

Yes, I like the idea of changeset publish --snapshot tag, it read clear to me of what it does but then users will not able to use their own publish script. like mentioned in #359 (comment), any opinions on this?

Isn't this problem solved by splitting this into 2 commands? @zkochan could use versioning command to adjust files and just use a custom publish command, or have I missed something?

Hey @Andarist, yes you are right. I misunderstood the second line. Sorry.
I see using snapshot flag with version and using tag option with publish looks clean. As in https://github.com/atlassian/changesets/pull/359#issuecomment-627250875
How can we decide on it?

Probably a good idea to wait for @mitchellhamilton’s or @Noviny’s green light

$ # Gives a version as 0.0.0-<hash>, but does not commit the files no matter the config
$ changeset version --snapshot
$ # Publish command supports the tag option, this overrides config for publish - default as latest
$ changeset publish --tag <tag>

This sounds good to me. One little thing: changeset publish should throw if --tag is passed when in pre mode (because the tag changes in a nuanced way when in pre mode). Also changeset version --snapshot some-tag should make the version 0.0.0-some-tag-hash

Unrelated to the above - instead of using the git hash, let's use a random hash so that it's not tied to git + you should be able to do multiple releases without the last commit hash changing

Another good alternative to using hash would be to use date/time. I have noticed this in the typescript canary versions but they use only date.
They have versions like this: 4.0.0-dev.20200512

FYI: React uses git SHA as well for canary/experimental releases
`0.0.0-experimental-${commit}`

https://github.com/facebook/react/blob/4469700bb60ffd62caf112e47bcfa51afdd40e47/scripts/release/utils.js#L196
https://github.com/facebook/react/blob/4469700bb60ffd62caf112e47bcfa51afdd40e47/scripts/release/utils.js#L86-L88

Hey 👋, PR is ready for review. 🙂

Hey @mitchellhamilton , thanks for a lot for accepting suggestion and merging the PR. Due to my travel arrangement this week I will not able to respond. Appreciate it. 🙂

Hey guys, when do you expect to publish this change? I can't wait to use it already.


Final ADS-side hookup for sqlcmd vars

This PR fixes #10703 by adding support for reading sqlcmdvars from the project file, and adds a test for confirming they're part of the final deployment/script generation task profiles.

Coverage decreased (-0.07%) to 34.188% when pulling 491cfa2e752dd43f71131dd8bca65c4dcec151d7 on benjin/sqlcmdProjHookup into c8a3fbca47a7d2a79bf628c36093a9860a39074c on master.

This PR fixes #10703 by adding support for reading sqlcmdvars from the project file, and adds a test for confirming they're part of the final deployment/script generation task profiles.

Do they show in deployment dialog so that user can fill in or does the profile file option shows in deploy dialog to choose? can you share a pic please :)


Roll engine afb9d510c3bb..99e84a9cfa4f (12 commits)

https://github.com/flutter/engine/compare/afb9d510c3bb...99e84a9cfa4f
git log afb9d510c3bb0f1b97980434b41200a2d3491697..99e84a9cfa4f25161edf8bb4acdb8e19d2edeea4 --no-merges --oneline
99e84a9cf Update Engine::ReportTimings to use the new FML_TRACE macros (flutter/engine#9215)
9b47dc679 Roll src/third_party/skia 93d0146dc6a1..6e4fee8c812e (8 commits) (flutter/engine#9214)
9f088c65e Add onReportTimings and FrameRasterizedCallback API (flutter/engine#8983)
647a8524b Revert "Switch PlatformViewsController from Activity ref to Application ref. (#9193)" (flutter/engine#9211)
1d4f3372d Roll src/third_party/skia c5fae22bce20..93d0146dc6a1 (1 commits) (flutter/engine#9209)
2a57255fc Roll src/third_party/skia 642178396b09..c5fae22bce20 (3 commits) (flutter/engine#9208)
2bc2cee67 Roll src/third_party/skia 0f809020ecb0..642178396b09 (2 commits) (flutter/engine#9207)
ca572db14 Roll src/third_party/skia e0d90c84e42f..0f809020ecb0 (5 commits) (flutter/engine#9205)
3371da1e0 Add platform_fuchsia.cc for default font on fuchsia (flutter/engine#9204)
782654846 Align fuchsia and non-fuchsia tracing (flutter/engine#9199)
5ea125eaf Switch PlatformViewsController from Activity ref to Application ref. (flutter/engine#9193)
fd4368c85 Skip golden tests on non-Linux OSes (flutter/engine#9198)
The AutoRoll server is located here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, please contact the current sheriff (bmparr@google.com), and stop
the roller if necessary.

Trybots failed. These were the failed builds: https://cirrus-ci.com/task/4836846513684480 , https://cirrus-ci.com/task/5962746420527104

AutoRoller is stopped; closing the active roll.


Ls is missing from the page

@Johannes-Vink commented on Wed Jul 17 2019
Hi, Lsv2 is listed on this page, however the L non v2 has been removed. On the pricing page the L4 is still listed.

Documentdetails
⚠ Dit gedeelte niet bewerken. Het is vereist om problemen te koppelen tussen docs.microsoft.com en GitHub.

ID: b7323e68-7415-ba43-47de-8d1738f7c52b
Version Independent ID: 1bce47f4-d516-dd38-3e54-8da7b9b7b416
Content: Azure Windows VM-grootten - opslag
Content Source: articles/virtual-machines/windows/sizes-storage.md
Service: virtual-machines-windows
GitHub Login: @jonbeck7
Microsoft Alias: jonbeck

@srvbpigh commented on Wed Jul 17 2019
Hello, @Johannes-Vink
Thank you for your feedback.
We are actively reviewing your comments and will get back to you soon.
Kind regards,
Microsoft DOCS International Team

Hi team,
I'm moving this here since it refers to the original documentation
Kind regards

@Johannes-Vink The Ls series you are looking for is listed on the older generations page here.
Thanks for bringing this to our attention. We will now close this issue. If there are further questions regarding this matter, please tag me in a comment. I will reopen it and we will gladly continue the discussion.


Update the tflite models and respective wasm

Hey @Volcomix
i noticed you were using the january edition of selfie segmentation model
a newer version has been published at https://developers.google.com/mediapipe/solutions/vision/image_segmenter
i wanted to open a PR to update this myself and save time but i faced an error running the tflite inference tool
this also could be the same reason why the github workflow to build the wasm is also failing

Hey @arcinston,
The segmentation model of this demo is from January 2021, so it's indeed quite outdated now. Some details about the reason here even though those details are also outdated as it seems like the latest models are now released under Apache 2.0 license.
The tflite inference tool doesn't build with the latest commits of tensorflow (I disabled the github workflow a few weeks ago) and I was struggling to understand why at a glance when I investigated.
Please note that I initially started this project when there wasn't any public WASM build of TFLite. Since then, there are now (at least) 2 runtimes maintained by TFJS and Mediapipe teams, which rely on more recent version of the segmentation model and which probably handle more edge cases than I did in this demo:

https://github.com/tensorflow/tfjs-models/tree/master/body-segmentation/src/selfie_segmentation_tfjs
https://github.com/tensorflow/tfjs-models/tree/master/body-segmentation/src/selfie_segmentation_mediapipe

I would suggest you to take a look at these implementations and perhaps replace the segmentation part of the pipeline with them. I believe that would be more future proof for your projects.

thanks a lot for this
will really help
also Thank You for this repository
helped me get started with building an npm package for this
will let you know when it's ready :)

Glad to hear that this work was helpful to you. Looking forward to checking out your work when it's ready 😉

Can you please explain what we should change to use the new model?

I haven't tried so I'm not sure if anything changed in the new model architecture but I think you could download selfie_segmenter.tflite and replace selfiesegmentation_mlkit-256x256-2021_01_19-v1215.f16.tflite from the models directory.
Then the mlkit model filename should be replaced by the new one (selfie_segmenter).
Please note that this model should replace the ML Kit model, not Meet.

Thank you for the detailed explanation. I've used the landscape model. I didn't see any noticeable change from the previous model.
There is a lot of flickering around the head which is especially apparent when using a solid background image. Any suggestion how to improve it? I've tried both the cpu and gpu segmenters.
The mediapipe segmenter has LIVE_STREAM running mode. Do you know if it can improve the result when the subject is moving his head in a live video?

The only thing that comes to my mind is that if you use the landscape model, you'll need to change the resolution of the ML Kit model. Perhaps some visual issues could come from this.
Playing with the post-processing sliders could also help to reduce the flickering around the head.
I don't know much about the latest version of mediapipe segmenter so I can't share more insights about it :flushed:.

The flickering happens with all models and also in the demo. I'll open a new issue for discussing it.


Newest (and working) version is not pushed on npm

Hey !
Seems like the fix you made with the node-dmx require has not been deployed on npm, so when I run npm i -g dmx-web, I get an error Error: Cannot find module '@node-dmx/dmx-library'.
I just cloned the repo and used the source for now though.
Thanks !

same issue!

please give it a push, same error here!

Published 1.0.1 just now - please try if that fixes this.

thanks, works!


PowerQUICC-III-e500 Register Size Issues

Describe the bug
When targeting the PowerQUICC-III-e500 language (PowerPC:BE:32:e500), the 64-bit register size associated with instructions leads to incorrect decompilation (and potentially incorrect analysis?). Particularly when passing function boundaries where the parameter and return types are gated to using the _rX registers to use the lower 32-bit words, the loss of the upper 32-bits would be fine, but instructions immediately following then appear to operate using the fully qualified 64-bit registers rX.
Instructions with an explicit size still work (such as the cmpwi on the second parameter in some_funcptr_func below), but those using the "native" register size are the ones that have issue. It also comes up when using any of the auto-decrementing instructions that set and then decrement ctr. (Not entirely relevant, but when I was reading Book E/e500 manuals, it states that the ctr-decrementing branches only operate on the lower 32-bits and rollover from 0 to 0xffffffff does not modify the upper 32-bits. I'm not quite sure if this would ever show as a bug, but noticed the behavior compared to the PCode.)
Some of the register sizing information is lost in simpler examples (e.g. -O0 compilations) due to stw and lwz instructions that provide the missing information to the upper 32-bits of the register before it is operated on.
I believe in the past I also saw an issue when coming across the common PowerPC pattern mtctr; bctr, but in attempting to reproduce the issue on this machine, I could not reproduce the exact behavior I recall. I don't think the UNRECOVERED_JUMPTABLE is related given it is present in the e500 and QUICC languages with -O2.
To Reproduce
Steps to reproduce the behavior:

(Optional) Compile e500_bug_1.c with with default optimization and -O2:

powerpc-linux-gnu-gcc -O2 -shared -g -mcpu=8548 e500_bug_1.c -o e500_bug_1_O2.so
powerpc-linux-gnu-gcc -O0 -shared -g -mcpu=8548 e500_bug_1.c -o e500_bug_1.so

Not necessary to show bug, just highlights how it is masked by compile-time decisions

Import the executables selecting PowerQUICC-III-e500 (PowerPC:BE:32:e500) for the language
(Optional) Import the optimized executable selecting PowerQUICC-III (PowerPC:BE:32:QUICC) for the language

Serves as a good reference as well as showing the failure when reaching certain SPE instructions

Open in Code Browser
Navigate to some_funcs

Just a convenient caller of the 3 callees

Browse each called function to compare

some_funcptr_func

Encapsulates the majority of issues I've seen
Parameter in r3 receiving a CONCAT44 before comparing
Parameter in r4 (moved to r30) displays correctly thanks to cmpwi

some_ctr_func

Similar to some_funcptr_func with a CONCAT44
ulonglong on counter loop variable suggests that ctr is being tracked as a 64-bit value when using bdnz (or other ctr-decrementing instructions)

some_vec_func

An SPE instruction that is not available in the non-e500 PowerQUICC-III language that halts disassembly

Expected behavior
That 32-bit PowerPC instructions will only use the lower 32-bits of the register sets for the PowerPC:BE:32:e500 language.
My understanding comes from reviewing disassembled PowerQUICC-III binaries and from the the e500 & PowerQUICC-III manuals. There are various mentions throughout that reference 32-bit implementations provide the PowerPC Book E only using the "lower" 32-bits. An example of a direct quote:

The e500 provides 32-bit effective addresses and integer data types of 8, 16, and 32 bits, as defined by Book E. It also provides two-element, 64-bit data types for the SPE APU and the embedded vector floating-point APU, which include instructions that operate on operands comprised of two 32-bit elements.

I am a little hesitant to declare that ALL instructions except for SPE should be 32-bit only to avoid the risk of breaking something else.
Given how ideal the regular PowerQUICC-III (non-e500) looks, it serves the majority of my purpose, but it's inability to handle various SPE instructions causes issues with analysis and decompilation.
Screenshots

Description
PowerPC:BE:32:e500 (-O2)
PowerPC:BE:32:QUICC (-O2)

some_funcptr_func

some_ctr_func

some_vec_func

some_vec_func (Listing)

Some additional screenshots of -O0 using PowerPC:BE:32:e500 where the lwz helps the decompiler.

Attachments
e500_test.zip
Zipped to upload the binaries.
❯ unzip -l e500_test.zip
Archive:  e500_test.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  2024-09-11 09:55   e500_test/
    69968  2024-09-11 09:55   e500_test/e500_bug_1.so
     1274  2024-09-11 09:55   e500_test/e500_bug_1.c
    70488  2024-09-11 09:55   e500_test/e500_bug_1_O2.so
---------                     -------
   141730                     4 files

 e500_bug_1.c provided inline
#include <stdlib.h>

#define __noinline__ __attribute__((noinline))

typedef void (*void_funcptr)(void);
void (*get_funcptr(void_funcptr))(void);

void __noinline__ some_funcptr_func(void_funcptr *ptr, int call) {
    if (ptr == NULL) {
        return;
    }
    *ptr = get_funcptr(NULL);
    if (call == 0) {
        (*ptr)();
    }
}

typedef unsigned long long 	__attribute__ ((vector_size (8))) __ev64_u64__;
struct vec_op {
    __ev64_u64__ result;
    __ev64_u64__ in1;
    __ev64_u64__ in2;
};

void __noinline__ some_vec_func(struct vec_op *op) {
    __asm__ __volatile__(
            "evldd %%r5, 0(%[a_in1])\n"
            "evldd %%r6, 0(%[a_in2])\n"
            "evfsadd %%r4, %%r5, %%r6\n"
            "evstdd %%r4, 0(%[a_result])\n"
            : : [a_result] "r" (&(op->result)), [a_in1] "r" (&(op->in1)), [a_in2] "r" (&(op->in2)));
}

struct node {
    struct node *next;
    union {
        unsigned long long ullval;
        unsigned long ulval;
    };
};

void __noinline__ some_ctr_func(unsigned int ctr, struct node *node) {
    unsigned int first_loop = 0;

    while (--ctr != 0) {
        node->ulval++;
        node = node->next;
    }
}

void some_funcs(void) {
    some_funcptr_func(NULL, 0);
    some_vec_func(NULL);
    some_ctr_func(0, NULL);
}

Environment (please complete the following information):

OS: Ubuntu 22.04.4 (Linux)
Java Version: 21.0.4
Ghidra Version: 11.1.2
Ghidra Origin: GitHub distro

Additional context
Binaries were generated on an Ubuntu 22.04 with the following gcc:
powerpc-linux-gnu-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Documents/manuals referenced:

Book E: Enhanced PowerPC™ Architecture
PowerPC™ e500 Core Family Reference Manual
MPC8548E PowerQUICC™ III Integrated Processor Family Reference Manual

That's a fundamental problem with our PowerPC architecture presently. I'm working on updating it to support both 32-bit and 64-bit implementations with 64-bit registers, which is how the Book E register model is described. Both the e500 and e200 use 32-bit Book E instructions and 64-bit SPE instructions. We're not handling the 32-bit Book E instructions correctly when we have 64-bit registers.


Update to Docker 1.12.1 (Sierra related fixes).

Checklist

[X] The commit message includes the cask’s name and version.
[X] brew cask audit --download {{cask_file}} is error-free.
[X] brew cask style --fix {{cask_file}} left no offenses.

Also, check out cask-repair, it makes Cask updates like this quite easy (details in CONTRIBUTING)


[Error] Downloading stash for Standard

[03-10-2015 1:10] System.Exception: Downloading stash for Standard, details logged to DebugInfo.log, please open a ticket at https://github.com/Stickymaddness/Procurement/issues
at POEApi.Model.POEModel.GetStash(String league, String accountName)
at Procurement.ViewModel.LoginWindowViewModel.LoadStashItems(Character character)
at Procurement.ViewModel.LoginWindowViewModel.d__6.MoveNext()
at System.Collections.Generic.List1..ctor(IEnumerable1 collection)
at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
at Procurement.ViewModel.LoginWindowViewModel.<>c__DisplayClass2.b__1()
at System.Threading.Tasks.Task.Execute()

The new version of Procurement is out, which fixes this issue: https://github.com/Stickymaddness/Procurement/releases/tag/1.9.6
Unfortunately until GGG decide to support the dev community, these type of issues will continue to happen as it is out of our hands. http://i.imgur.com/yrPtajM.jpg


user login with invalid creadentails no response shown to user

when user tries to login and his/her credentials are wrong no error message or alert is shown or handled this state

fixed this issue now in order to solve the error display mechanism I must create a universal errors showing component and display all the error using that component. also must create error context.

fixed this issue now in order to solve the error display mechanism I must create a universal errors showing component and display all the error using that component. also must create error context.


Third pane not showing for (example.scpt)(Open File...)

AppleScripts that include the on open handler are given the Open File... action in QS. However, the third pane is not made available to select a file.
To reproduce:

Create and save an AppleScript with the following contents:

on open theFile
tell application "Finder" to display dialog name of theFile
end open

Select the AppleScript in QS.
Select the Open File... action in QS
Try in vain to tab into the third pane, only to find yourself cycling between the first and second panes instead.

Quicksilver β63(3912)
Mac OS X 10.7.2

I'm not too sure myself how that action works. Perhaps you want to save the applescript in the Actions folder in ~/Library/Application Support/Quicksilver/Actions and then run it as an action?
@philostein knows a lot more about applescripts than me.

Sounds similar to the problem we had with “process text”. It’s been a while since I looked at that section of the code, but I’d bet it has to do with the argument count being determined incorrectly.

So, is this going to be assigned to anyone?

The majority of issues never get assigned. Don’t read too much into it. :-)

The bug is present in β62. For whatever reason, when I try to test using β61 and lower, the Open File... action is not available at all (probably a side effect of running an older version with a set of prefs from β63), so I can't say for sure if it was present then.
Jon
On 2011-12-11, at 3:46 PM, Patrick Robertson wrote:

Unfortunately a lot of us have our hands full at the moment.
Can you pinpoint when this bug was introduced? Which QS version? That will make it easier for us to track and fix.

Reply to this email directly or view it on GitHub:
https://github.com/quicksilver/Quicksilver/issues/603#issuecomment-3099524

When I work on #623, I’ll probably be in the neighborhood of where this happens, so I’ll try to look at it too.

probably a side effect of running an older version with a set of prefs from β63

I still run B54 sometimes and it works just fine. :-) There were other similar problems with AppleScript and process text at the time. Maybe that’s why the action doesn’t show up.

Excellent!

Sorry, IIRC, my work was on when the apple script is an action, I have no insight on this one...

Sorry Eric, I guess I must have mixed things up. I appreciate you getting back to us!
Good luck with everything

Yeah, what @ddlsmurf did involved fancy new features. I suspect this is just a bug somewhere involving argumentCount.

From a a very brief github browse, it looks like this should also handle kAppleScriptOpenFilesAction. (sorry can't compile here and try)

From a a very brief github browse, it looks like this should also handle kAppleScriptOpenFilesAction. (sorry can't compile here and try)

That was it.

Thanks, I can confirm this is working in ß65 Lion.
In Lion, if you're testing, the Finder line needs to read:
tell application "Finder" to display dialog (name of item 1 of theFile)

No, it doesn't. All you need is to use the "on open" hander as follows:
on open thefiles
--code goes here
end open

Apologies, should've been more specific.
The script produces pane 3 and executes, but doesn't show any visible result. I seem to recall that before SL, a single file selection's class was an alias(?) as opposed to a list for multiple items. In Lion at least, a single file selection is also returned as a list. Finder can't display a list in a dialog.
My new code still fails though, so here's a revised version:
set _name to (name of item 1 of theFile)
display dialog _name


Enable dagger-in-dagger by default.

Based on top of https://github.com/dagger/dagger/pull/3927 only the last commit is unique to this PR
Still a few cleanups marked as TODOs in comments but tests all pass. Also will add a test suite specific to dagger-in-dagger to provide coverage that i.e. host filesystem leaks aren't possible before merging.

Current approach results in the mode needed by our test cases (each dagger.Connect results in a new session, as opposed to connecting to an existing shared one) being the default. This is just because I think it's a smaller change to support this only initially. We can add support for the shared session approach in a follow up.
However, I want to think a little more and see if there's any trivial routes to instead starting out with the default of shared session, so will update this if I think of anything.

EDIT: thought of something... trying it out

Either way, once out of draft I will update with a more thorough explanation of the details here. In the mean time, the description of the PR this is based on should help provide some background (especially the "next steps" section).

I would suggest to not remove the feature flag for now:

Sounds good! It'll be easy to make this toggle-able still. And honestly even in the long run it probably makes sense to always allow disabling of this feature even if it defaults on in the future. So I code it such that we retain the experimental feature flag and in the future when we want to default it on it's just a single line change and can still be toggled off.


Make an option to start on startup

Also you could select if you want it to display the full window or start it minimized.

To launch the app at startup, use one of these methods: Mac / Windows.
As for making it start windowed or hidden, I could add a setting for that in a future update.

It is possible to start any app on login on a Mac by entering System Preferences > Users and Groups > (your account) > Login Items and then adding the app. Check next to its name once added to start it hidden.
On Windows, create a shortcut to the application and put it in the Startup folder (search for this in the start menu). On Windows, I don't know if it is possible to start hidden on Windows but it is possible on macOS.


feat: Add Reminders fields and Notifications

Description
Adds native reminder support to tasks without the need of a plugin.

Motivation and Context
Had some issues with existing external plugin and figured a built-in solutions would help solve some of those issues and simplify things.
Fixes #1854

How has this been tested?
Tests have been created for the new fields and for some query filters. More tests are need for notifications

Screenshots (if appropriate)

Types of changes

Changes visible to users:

[ ] Bug fix (prefix: fix - non-breaking change which fixes an issue)
[x] New feature (prefix: feat - non-breaking change which adds functionality)
[ ] Breaking change (prefix: feat!! or fix!! - fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation (prefix: docs - improvements to any documentation content for users)
[ ] Sample vault (prefix: vault - improvements to the Tasks-Demo sample vault)
[ ] Contributing Guidelines (prefix: contrib - any improvements to documentation content for contributors - see Contributing to Tasks)

Internal changes:

[ ] Refactor (prefix: refactor - non-breaking change which only improves the design or structure of existing code, and making no changes to its external behaviour)
[ ] Tests (prefix: test - additions and improvements to unit tests and the smoke tests)
[ ] Infrastructure (prefix: chore - examples include GitHub Actions, issue templates)

Checklist

[x] My code follows the code style of this project and passes yarn run lint.
[x] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] My change has adequate Unit Test coverage.

Terms

[x] My contribution follow this project's contributing guide
[x] I agree to follow this project's Code of Conduct

Left To-do

[ ] add more unit tests around notifications and queries
[ ] Update notification modal css
[ ] Test Dateview Serializer, just copied over from default

Hi @Erik-Handeland, huge thanks for doing this!

I started testing this out, and have noted the first few comments.
It's too large a PR to review in one go, so I'll mainly focus on the behaviour initially - and later, look at user docs and then tests.
Behaviour-wise, on Mac I created this task at about 9:09...

[ ]  #task do stuff today 📅 2023-05-01 ⏲ 2023-05-01 9:15 am

It's now 09:17 and I didn't get a reminder.
I don't know if it's relevant:

macOS Catalina 10.15.7
Tasks 1.2.6 (insider)
I had two vaults open
I was reading web pages at the time, so Obsidian was running but was not the front program

This is weird, but does space have multiple ascii/unicode values?

When I print out the list of load tasks from the cache, I see that your tasks do not parse correctly, while mine seemingly identical do. When I compare the two strings

Anyway, when looking at the printout of the task cache I can see that reminders aren't getting parsed with the string I copied from github compared to the one I made from the create task modal.

Hey @Erik-Handeland - I've been trying to figure out why I'm not getting any notifications on my Mac, and also looking at ways to give you advice on writing tests...
Also, looking at the number of comments already on this PR it's maybe getting a little hard to manage for both of us, I suspect...
You mentioned you might be able to work on tests this weekend. I've had some really good experiences pair-programming with others on open-source projects - way more efficient, effective and fun than going back and forth with comments in GitHub!
I think it would be great if we could find a time this weekend - preferably Sunday for me, or I could do after 9pm UK on Saturday - to pair on writing tests including for the notification code.
I think it will move the PR a long way forward for much less time than we are spending back-and-forth here...
And I venture to suggest that as well as me learning about notifications, I will be able to share some time-saving tips about writing effective unit tests on hard-to-test code.
My email address is in my profile here.

@Erik-Handeland I have been working on some exciting new custom grouping capabilities for Tasks - which will later extend to custom sorting, and then custom filtering...
In each of these, users may use the reminder date/time. Already that is more complicated than all the the other fields, as it introduces the time element.
Full support for times is something that is not yet fully supported by this PR - rightly. For example, 'show me tasks with reminders before midday tomorrow'.
So I do remain keen to see this PR merged and released, but it already adds the need for a lot more underlying work on Tasks, for full support.
So, I am afraid that on reflection I have decided that it will not be possible to accept support for multiple reminders in this PR.
Multiple reminders would make this PR too big, as a lot of work remains to get it working (from the code pushed so far) but more significantly, multiple reminders greatly increases the maintenance burden for me on existing Tasks features, and it adds a permanent overhead on all future Tasks features.
So please don't spent any more time improving the behaviour of multi-reminder handling the PR.
I'm happy to do the work of removing multiple reminder support after the PR is merged, to at least save you the time of having to remove it.
Sorry this isn't better news, but I have to prioritise the overall usability and reliability of tasks, and the time of myself and future maintainers and contributors too.

@claremacrae I see. I understand where you're coming from with the maintenance burden and overhead for new feature. However, I have no interest in removing multiple reminders as I require it for my workflow. I appreciate your offer to remove "multiple reminder support after the PR is merged", but I find myself with less free time lately. It would probably take me a few months to flush out the rest of the TODOs.
So, I'll leave the branch attached to this pr alone to preserve its current state. In case you or others want to use what's currently here. I'm going to continue working on the features I need for my workflow (reminder on due/start date) on a separate branch. I still believe there is a way to implement this while still being easy to maintain, although it will take me some time to think through and get it right.
Hopefully, future refactoring efforts will reduce some tech debt and make extending queries on a single field a bit easier. There's a fair bit of abstract that could be done throughout the codebase to simplify things. I see a number of PR working towards that end. There are also a number of long running and quite large PRs. It would probably be best to wait for more of these to be merged before pursuing reminders further. I think it would be best to pause/close this PR for now.

Hi @Erik-Handeland, thank you for your understanding. And thank you for saying you will keep the branch behind this, so I can pick this up later.
If you are comfortable leaving this open, then as I work on it, I can push to your branch.
The big benefit of this is that when the PR is merged, you will rightly get the credit for it, in the history and in the release notes. (I could never have implemented what you have done, and I would really like the history of the project to reflect your contribution.)
I'm presuming you don't have any un-pushed changes, I would be grateful if you cold push them.

If you are comfortable leaving this open, then as I work on it, I can push to your branch.

Sounds good to me

I'm presuming you don't have any un-pushed changes, I would be grateful if you cold push them.

Haven't pushed anything since last week. So it already has my last changes.

Hi @Erik-Handeland, In looking at the documentation (thank you) I just wondered...
I see you've opted ⏲ as the emoji, and the Reminders plugin uses ⏰ (according to the Tasks notes about it, anyway)
I was just curious if there was any particular reason for this? Thanks.

Hi @Erik-Handeland, In looking at the documentation (thank you) I just wondered...
I see you've opted ⏲ as the emoji, and the Reminders plugin uses ⏰ (according to the Tasks notes about it, anyway)
I was just curious if there was any particular reason for this? Thanks.

Didn't want to provide any sort of expectations that existing reminders would just work / have to make sure they work. Also was running both for a bit and having a different emoji seem like a good idea

Hi @Erik-Handeland, In looking at the documentation (thank you) I just wondered...
I see you've opted ⏲ as the emoji, and the Reminders plugin uses ⏰ (according to the Tasks notes about it, anyway)
I was just curious if there was any particular reason for this? Thanks.

Didn't want to provide any sort of expectations that existing reminders would just work / have to make sure they work. Also was running both for a bit and having a different emoji seem like a good idea

Oh that's a really good point. Thank you.
I favour Tasks not inventing inconsistent emoji where possible, as if we do, other plugins want to support both Tasks and Reminders formats it have more work to do.
I've been thinking about this all day, and I can see now how to make the Tasks reminders consistent with the Reminders emoji format, which would give users the best of both worlds, compatibility-wise.
I think it means:

Add an option in Tasks to turn off Tasks' reminders notifications, so that people can use the Reminders plugin instead if they wish, but still use tasks to edit their reminders, like in the modal

The big reason to use Tasks' reminders modal is that recurrence will work properly when they complete a task
But being able to switch between the two reminder systems might help people experiment with a migration path from one plugin to the other

Switch to using the same emoji as Reminders plugin
Use the same date format as Reminders plugin (which is 24-hour...)

I totally understand that this won't work for you - sorry about that.

Hi @Erik-Handeland, In looking at the documentation (thank you) I just wondered...
I see you've opted ⏲ as the emoji, and the Reminders plugin uses ⏰ (according to the Tasks notes about it, anyway)
I was just curious if there was any particular reason for this? Thanks.

Didn't want to provide any sort of expectations that existing reminders would just work / have to make sure they work. Also was running both for a bit and having a different emoji seem like a good idea

Oh that's a really good point. Thank you.
I favour Tasks not inventing inconsistent emoji where possible, as if we do, other plugins want to support both Tasks and Reminders formats it have more work to do.
I've been thinking about this all day, and I can see now how to make the Tasks reminders consistent with the Reminders emoji format, which would give users the best of both worlds, compatibility-wise.
I think it means:

Add an option in Tasks to turn off Tasks' reminders notifications, so that people can use the Reminders plugin instead if they wish, but still use tasks to edit their reminders, like in the modal

The big reason to use Tasks' reminders modal is that recurrence will work properly when they complete a task
But being able to switch between the two reminder systems might help people experiment with a migration path from one plugin to the other

Switch to using the same emoji as Reminders plugin

Use the same date format as Reminders plugin (which is 24-hour...)

I totally understand that this won't work for you - sorry about that.

Hmmm. The Reminders README says that only one time format is supported:
https://github.com/uphy/obsidian-reminder

However, drilling down in the docs is a section that does not appear in the main docs menu:

Use the same date format as Reminders plugin (which is 24-hour...)

I totally understand that this won't work for you - sorry about that.

In reminders settings you can set a custom format like so. It's what I was using, but not sure how much of it working is on purpose or as a result of how forgiving moment.js is with parsing.

Also, I think I remember reading that reminders requires the emoji to be the first one? In order to parse it correctly.


Clean up some UB

The SILBuilder could potentially reference itself during its own
initialization if a valid insertion point was left around and a
new basic block was created.  Move basic block creation after the
initializer instead.

CSDiag was comparing canonical types for equality directly, which
leads to mixed-type comparisons if one side of the comparison is nullptr.
Use isEqual instead.

@swift-ci please smoke test and merge


error: bundling failed: "TransformError [...] (While processing preset: node_modules [... \babel-preset-react-native\index.js")"

Is this a bug report?
Yes

Have you read the Contributing Guidelines?
No
Environment

react-native -v: react-native-cli: 2.0.1
node -v: v6.11.2
npm -v: 3.10.10
yarn --version: not using

Then, specify:

Target Platform: Android

Development Operating System: Windows 7 Professional SP1 x86_64

Build tools: Android Studio 2.3.3, JRE 1.8.0_122, Android SDK Tools 26.0.2

Steps to Reproduce

(Write your steps here:)

D:\path\path>react-native init project
cd project
react-native run-android

Expected Behavior

The welcome React-Native screen should appear on the emulator screen.
Actual Behavior

It throws the below error:
React packager ready.

Loading dependency graph, done.
Bundling `index.android.js`  [development, non-minified, hmr disabled]  ░░░░░░░░░░░░░
Bundling `index.android.js`  [development, non-minified, hmr disabled]  0.0% (0/1), f
ailed.
Bundling `index.android.js`  [development, non-minified, hmr disabled]  ░░░░░░░░░░░░░
error: bundling failed: "TransformError: D:\\path\\path\\project\\index.android.js: Unex
pected token ) (While processing preset: \"D:\\\\path\\\\path\\\\project\\\\node_modules
\\\\babel-preset-react-native\\\\index.js\")"

Reproducible Demo

It is an empty standard project as it is described in https://facebook.github.io/react-native/docs/getting-started.html > Building Projects with Native Code.

some here +1

+1

@Kennytian Thank you for the solution. I have known about the workaround. The issue has appeared a few days ago and I've expected to disappear. But it is still there and it's frustrating that the react-native team didn't fix it. I'm desperate to finish a project and I'm only struggling with all kind of errors because versions of packages and compilers don't match.

+1
workaround didnt fix it in my app:
npm: 5.0.1
react-native-cli: 2.0.1
react-native: 0.47.1
node: v7.9.0

@facebook-github-bot duplicate #15513

for yarn used following Commands
yarn remove babel-preset-react-native
yarn add<EMAIL_ADDRESS>for npm used following Commands
npm uninstall babel-preset-react-native
npm install<EMAIL_ADDRESS>

This work like a charm
@tudor2it work around:  npm install --save-dev<EMAIL_ADDRESS>

workaround fixed it for me

@Kennytian workaround fixed it thanks!

@Kennytian  workaround fixed it, thank you

@Kennytian  fixed it, thank you so much

@ShubhamBabhulkar This fixed my issue as well. Thank you.

@Kennytian Great Thanks it works.. :+1:

Still broken. Repro:
https://github.com/sospedra/RNAnimated

step1
npm install --save-dev<EMAIL_ADDRESS>step2
npm update

@Kennytian fixed it! Great Thanks it works.. :+1:

Gettting this Error In Ios
TransformError: /Users/stellent/Desktop/terapanth/index.ios.js: Couldn't find preset "babel-preset-react-native-stage-0/decorator-support" relative to directory "/Users/stellent/Desktop/terapanth"

Getting similar error in android
Couldn't find preset "babel-preset-react-native-stage-0/decorator-support" relative to directory

npm reinstalls did not work for me.  Only Yarn method
yarn remove babel-preset-react-native
yarn add<EMAIL_ADDRESS>

I am getting error: bundling failed: TypeError: Cannot read property 'bindings' of null

getting the same error here

I love you ma~
@Kennytian

give this man (@Kennytian) a medal

一直挣扎在版本，编译不匹配的坑里，rn team要加油！


Keybase helper not installing

Have tried the new .dmg provided in previous responses, not working.
my log id: d2fc08af78152a013e4cf71c

Solved with
sudo dseditgroup -o edit -a $(whoami) -t user staff


Fix ISO C function/object pointer issue

Showed up on GCC with strict warnings.
Fixes #3252 comment raised by @dot-asm

commit cf10df8 thanks!


Update kubernetes.md

Purpose of this pull request
This pull request provides alternate mechanism to install the Kubernetes application plane app. This is in response to lots of customer requests who do not want to run helm command.
Select the type of change

[x] Minor Changes - Typos, formatting, slight revisions
[ ] Update Content - Revisions, updating sections
[ ] New Content - New features, sections, pages, tutorials
[ ] Site and Tools - .clabot, version updates, maintenance, dependencies, new packages for the site (Docusaurus, Gatsby, React, etc.)

Ticket (if applicable)
https://sumologic.slack.com/archives/C1PB1DMB3/p1711760228386479

@himanshu219 thank you for submitting this! Approved and will merge.


WinRT is now a portable class library. Removed some use of binding flags...

Remade the WinRT library as a portable class library. This should better highlight what framework features we can and can not use. In the process removed some uses of Binding Flags which are not a part of the portable language subset (mostly confined to fsPortableReflection.cs).

Thanks, I've (hopefully) fixed the build with the referenced commit. There were a couple of issues with this pull request:

You can use the UNITY_METRO define to trigger WinRT compilation support (the csproj was broken and not correctly activating it)
The csproj files are handwritten so that they don't require maintenance when, ie, adding/removing files


Temperature Sensor

Describe the bug
Temperature sensor thinks it is a Climate controller.

Current Temperature is incorrect

Screenshots

Steps To Reproduce

Add temperature sensor to Smart Life.
Restart Homebridge

Plugin Version
0.6.3

Homebridge Config

Device Config

"defaults": [
    {
        "id": "REDACTED",
        "device_type": "climate"
    }
],

Additional Context

Payload extracted from API using debug tool
{
   "current_temperature":2329,
   "max_temper":10000,
   "min_temper":-2000,
   "online":"True",
   "state":"2329",
   "temp_unit":"CELSIUS",
   "temperature":2329,
   "dev_type":"climate",
   "ha_type":"climate",
   "icon":"https://images.tuyaeu.com/smart/icon/1540907310m7lcr25209f_0.png",
   "id":"REDACTED",
   "name":"Temp Living Room"
}

For real though, what the heck is Tuya doing here....
This device is giving very strange output through the API.
Could it be that the actual temperature at that time was 23.29 degree celsius? That seems the closes to your actual recorded temperature.
In that case please set the current_temperature_factor to 0.01.
The HomeKit tile is showing 150 degrees since I hard-coded that to be the maximum value that it will ever show, it needs some max value and hotter than the hottest ever recorded temperature outside seems reasonable 😉.
I will work on an update that will allow you to overwrite the device type to a temperature sensor so that you will not be able to alter the current temperature.

And I released an update that will allow you to overwrite the device type  to a temperature sensor 😉.
Please update the plugin to version 0.7.0 and update your config to reflect the following:
{
   "id":"REDACTED",
   "device_type":"temperature_sensor",
   "current_temperature_factor":"0.01"
}

Have updated the plugin. Now it show 150 all the time.
Homebridge

Homekit

Config
  {
            "name": "TuyaWebPlatform",
            "options": {
                "username": "REDACTED",
                "password": "REDACTED",
                "countryCode": "REDACTED",
                "platform": "smart_life"
            },
            "defaults": [
                {
                    "id": "REDACTED",
                    "device_type": "temperature_sensor",
                    "target_temperature_factor": "0.01"
                },
                {
                    "id": "REDACTED",
                    "device_type": "temperature_sensor",
                    "target_temperature_factor": "0.01"
                }
            ],
            "scenes": false,
            "platform": "TuyaWebPlatform"
        }

plugin version: @milo526/homebridge-tuya-web v0.7.0

Works now. Thank you!

For some reason now temp sensors are grouped. Before they were separate but with incorrect temp. Now they are correct reporting hence grouped.

Sadly this is a side-effect of exposing your thermostats as temperature sensors.
Temperature sensors are shown as sensors in the sensor bar of homekit. All sensors that share a characteristic (i.e. current temperature) get grouped into 1 tile.
This is the way Apple designed the Home app. You might find it easier to use a third party app, not all third-party apps group sensors in this way.


Bug with @ key on german keyboard

I've just noticed that when you're pressing the key @ (alt gr + q) you also have to press another key to get the @ character.

(Tested on latest git clone)
Runtime Log
Catched on osu client.

Is this still relevant? I can't reproduce this issue.

Still happens for me with Italian keyboard (and my problem is the same of this duplicated issue: ppy/osu/issues/3884)

I decided to investigate this a little bit. Not only do the AltGr combination keys not work, Alt codes don't either. It's an esoteric input method, I know.
After a short browse I found these lines:
https://github.com/ppy/osu-framework/blob/7d8df261cc21023dd014444fd5acbf23671241b3/osu.Framework/Graphics/UserInterface/TextBox.cs#L712-L713
Root cause seems to be that those conditions for e.AltPressed and e.ControlPressed (because surprise, AltGr is secretly Ctrl+Alt, at least on Windows) prevent character input using those keys from being consumed. Removing them reenables both AltGr and Alt codes.
Last change to lines above was in 6ebcbb97. I'm lacking context here so it's hard for me to say what the correct fix would be here. I might prop up a tiny PR for this, though I had trouble getting text boxes in visual tests to consume keyboard input through the InputManager, so I resorted to more primitive tactics to diagnose. I would want to submit a test for this, though, just for good practice.

This is likely something that needs to be fixed in osuTK.  Future transitions to SDL may also render this moot.

Should be fixed via https://github.com/ppy/osu-framework/pull/4985


websocket client closing connection (code: 1000) after first push received from server

We have a client and server connected using web socket. On the client side, the connection is getting closed after receiving a push from the server, even though we have written it to run forever.
Client side code:
async def connect() -> websockets.connect:
    uri: str = _get_uri() // helper function to get uri
    connection = await websockets.connect(uri)
    if connection.open:
        print('Connected to server')
        await sendMessage(connection, "Hello from client")
        return connection

async def sendMessage(connection: websockets.connect, message):
    await connection.send(message)

async def receiveMessage(connection: websockets.connect):
    while True:
        try:
            message = await connection.recv()
            print('Received message from server: ' + str(message))
        except (websockets.exceptions.ConnectionClosed, KeyboardInterrupt) as e:
            break

async def heartbeat(connection):
    while True:
        try:
            await connection.send('ping')
            print('Heartbeat ping')
            await asyncio.sleep(5)
        except websockets.exceptions.ConnectionClosed:
            break

def main():
    try:
         event_loop = asyncio.events.get_event_loop()
         connection = event_loop.run_until_complete(connect(data, callback))

          tasks = [
               asyncio.ensure_future(receiveMessage(connection)),
               asyncio.ensure_future(heartbeat(connection)),
          ]
          event_loop.run_until_complete(asyncio.wait(tasks))
          event_loop.create_task(receiveMessage(connection))
          event_loop.create_task(heartbeat(connection))

          event_loop.run_until_complete(asyncio.gather(receiveMessage(connection), heartbeat(connection)))
          event_loop.run_forever() // trying to keep it alive forever, until user terminates from keyboard

    finally:
         print('bye')

Server side code:
class Server:
    _host: str
    _port: int
    _websocket: websockets.WebSocketServerProtocol

    def __init__(self, host: str, port: int):
        self._host = host
        self._port = port

    def init_server(self) -> websockets.server.Serve:
        return websockets.serve(self._serve, self._host, self._port)

    def run(self) -> None:
        event_loop = asyncio.get_event_loop()
        try:
            event_loop.run_until_complete(self.init_server())
            event_loop.run_forever()
        finally:
            event_loop.close()

Output:
Connected to client
Heartbeat ping
Heartbeat ping
Received message from server: SUCCESS
Connection closed - 1000

Wondering if I can get some help understanding why this is happening.

You could stop catching the ConnectionClosed exceptions in order to see them.
Or you could enable debug logs: https://websockets.readthedocs.io/en/latest/howto/cheatsheet.html#debugging

@aaugustin Enabled debug logs now.
2022-09-22 23:14:59,359:[websockets.client]:[DEBUG]:: < Server: Python/3.9 websockets/8.1
= connection is OPEN
2022-09-22 23:14:59,359:[websockets.client]:[DEBUG]:: = connection is OPEN
> BINARY e0 01 00 ea ee b3 81 83 de af 87 be ac 84 74 79 ... cb 9a 80 ba 00 c8 0a 00 [166348 bytes, continued]
2022-09-22 23:14:59,359:[websockets.client]:[DEBUG]:: > BINARY e0 01 00 ea ee b3 81 83 de af 87 be ac 84 74 79 ... cb 9a 80 ba 00 c8 0a 00 [166348 bytes, continued]
2022-09-22 23:14:59,360:[cli_network]:[INFO]:: 100% sent
> CONT '' [0 bytes]
2022-09-22 23:14:59,360:[websockets.client]:[DEBUG]:: > CONT '' [0 bytes]
> TEXT 'ping' [4 bytes]
2022-09-22 23:14:59,361:[websockets.client]:[DEBUG]:: > TEXT 'ping' [4 bytes]
> TEXT 'ping' [4 bytes]
2022-09-22 23:15:04,362:[websockets.client]:[DEBUG]:: > TEXT 'ping' [4 bytes]
< BINARY e0 01 00 ea ee 93 81 83 de 8f 87 bd 84 74 79 70 ... 63 63 65 73 73 66 75 6c [60 bytes]
2022-09-22 23:15:07,829:[websockets.client]:[DEBUG]:: < BINARY e0 01 00 ea ee 93 81 83 de 8f 87 bd 84 74 79 70 ... 63 63 65 73 73 66 75 6c [60 bytes]
< CLOSE 1000 (OK) [2 bytes]
2022-09-22 23:15:07,833:[websockets.client]:[DEBUG]:: < CLOSE 1000 (OK) [2 bytes]
= connection is CLOSING
2022-09-22 23:15:07,833:[websockets.client]:[DEBUG]:: = connection is CLOSING
> CLOSE 1000 (OK) [2 bytes]
2022-09-22 23:15:07,833:[websockets.client]:[DEBUG]:: > CLOSE 1000 (OK) [2 bytes]
= connection is CLOSED
2022-09-22 23:15:07,837:[websockets.client]:[DEBUG]:: = connection is CLOSED

Based on the < and > marks, it looks to me that once the client is sending data to the server, the server is asking it to close the connection by send a 1000? Is that expected

Yes, it looks like your connection handler (the _serve method) returns early and the connection is closed from the server side.


Puddle [PCSE00042]

App summary

App name: Puddle
App serial: PCSE00042
App version: 1.00

Vita3K summary

Version: v0.1.9
Build number: 3386
Commit hash: https://github.com/vita3k/vita3k/commit/6f71dc1c
CPU backend: Dynarmic
GPU backend: OpenGL

Test environment summary

Tested by: crasher9032
OS: Windows 11
CPU: Intel
GPU: NVIDIA
RAM: 16 GB

Issues
Black screen, the game is running but doesn't show up.

Screenshots

Log
vita3k.log
Recommended Labels

Ingame -
input bug


PSDefaultParameterValues

When setting PSDefaultParameterValues for Get-aduser as follows:
$PSDefaultParameterValues=@{'Get-ADUser:Properties' = "SamAccountName" , "UserPrincipalName" , "DistinguishedName" , "GivenName" , "Surname" , "Name" , "Enabled" , "employeeid" , "lastlogondate"}
In addition to the requested parameters, SID / ObjectGUID and ObjectClass are still displayed.

The AD cmdlets will do this regardless of $PSDefaultParameterValues, with specifying these properties manually, so it's not really related to that.
The AD cmdlets have a 'defaut property set' of a handful of properties that it returns when no properties are specifically requested. When you request specific properties, it treats those as "additional" to the default set, not as a full replacement for its default set.
If you want to have objects with only certain properties on them, you need to use Select-Object to pare off the properties you don't want.


[assets] set LoadState properly and more testing!

Sets LoadState properly on all failing cases in AssetServer::load_async
Adds more tests for sad and happy paths of asset loading

Note: this brings in the tempfile crate.

From your tests, it seems LoadState::NotLoaded is used for:

handle to an asset not yet loaded (for example, building an handle from a path that was not loaded)
handle to an asset built outside of the asset server
handle to an asset created by loading it through the asset server but without an asset loader for its extension

Having those bundled together doesn't seems right to me.

Having those bundled together doesn't seems right to me.

This is fair, however, this isn't a change on my part. This was simply the original behavior of the LoadState.
@mockersf
Based on the list you gave I assume you'd expect the following:

handle to an asset not yet loaded (for example, building an handle from a path that was not loaded)

LoadState::NotLoaded

handle to an asset built outside of the asset server

LoadState::???

handle to an asset created by loading it through the asset server but without an asset loader for its extension

LoadState::Failed
The curious part about this last one is that this is the only unhappy path that doesnt change the LoadState to Failed. However this is because if a loader does not exist for the extension type async_load immediately returns before creating a SourceInfo struct for this.
Should we creat a SourceInfo struct for it?

This is fair, however, this isn't a change on my part. This was simply the original behavior of the LoadState.

Right, your tests made this issue visible 😄 . It can be a followup PR if you prefer.

handle to an asset not yet loaded (for example, building an handle from a path that was not loaded)

LoadState::NotLoaded
👍

handle to an asset built outside of the asset server

LoadState::???
LoadState::WhatAreYouDoing? LoadState::NotSomethingYouLoadedWhyYouDoingThis? LoadState::NotFromAssetServer? LoadState::ManuallyLoaded? LoadState::NotALoadedAsset?

handle to an asset created by loading it through the asset server but without an asset loader for its extension

LoadState::Failed
👍

The curious part about this last one is that this is the only unhappy path that doesnt change the LoadState to Failed. However this is because if a loader does not exist for the extension type async_load immediately returns before creating a SourceInfo struct for this.
Should we creat a SourceInfo struct for it?

I think a SourceInfo is used to track the life of an asset's source for things like reloading, ... This is not needed are so I would say no.

handle to an asset created by loading it through the asset server but without an asset loader for its extension

LoadState::Failed
The curious part about this last one is that this is the only unhappy path that doesnt change the LoadState to Failed. However this is because if a loader does not exist for the extension type async_load immediately returns before creating a SourceInfo struct for this.
Should we creat a SourceInfo struct for it?

It was mentioned today that it fails silently for that case. It was in a case of loading a gltf model with jpg textures, which doesn't work without --features jpeg. Could you also add a log in that case? (actually this would probably not help in this case at all as the gltf loader doesn't go back to the asset server to load its texture, still would probably be good to log that the user is doing something that can't work)

I think a SourceInfo is used to track the life of an asset's source for things like reloading, ... This is not needed here so I would say no.

Well, the SourceInfo struct is what conatins the LoadState.
So in order to set the load state, you would have to insert a SourceInfo.

When this gets merged in I'll submit a follow up PR to address #2261 and that calling get_load_state on a Handle manually constructed (not thought .load()) should return a specific LoadState.

ping @cart :wink:

pinging here again to hopefully get some traction.
Would like to get this merged in as it unblocks me from adding #2310 which then unblocks 2 other PRs.

Looks good to me!

bors r+


Add general exception formatter for trace events to Azure.Core

I think we need to move this into Azure.Core and add a couple of tests. It doesn't have to be a part of this PR.
Originally posted by @pakrym in https://github.com/Azure/azure-sdk-for-net/pull/8249

Looked at the source again. I think ToString is good enough for a general case.


Refactor integration tests

Replace use of .sl-span per https://github.com/softlayer/ember-style-guide/issues/29, as well as utilize the same referenced selector in other references as appropriate.

@notmessenger please assign to me.


Add LICENSE file

Hiya, noticed this repo was missing a license file. Copied the license verbatim from the gomatrixserverlib repo.

Thanks @shazow  - can you sign off on these changes so we're able to merge them?
Just need to leave a comment here like so:
Signed-off-by: Your Name<EMAIL_ADDRESS>

Signed-off-by: Andrey Petrov<EMAIL_ADDRESS>