Unity hangs after switching to UWP in 2019.3

It looks like on latest Unity, there's some changes in Unity that make it susceptible to a hang when swapping platforms (when there is code in OnValidate that's doing the wrong stuff - i.e. destroying things).
This surfaces because the MixedRealityToolkit.cs code has OnValidate which is running on platform switch (which under the covers does way more work than is necessary on validate). This is a patch fix to make it so that during asset import, we don't do this work, which resolves this particular version of this issue)
Fixes: https://github.com/microsoft/MixedRealityToolkit-Unity/issues/7299

/azp run

/azp run

Ah, it looks like this actually didn't resolve the issue for folks. It turns out that I thought it was working because on close/restart of Unity you're far less likely to hit it.


cmd/go: workspace documentation is uninformative

The new workspace feature looks like a great thing, but the only helpful documentation is the design doc. The output from go help is barely rudimentary.
Look at where we start:
% go help work
Go workspace provides access to operations on workspaces.

Note that support for workspaces is built into many other commands,
not just 'go work'.

See 'go help modules' for information about Go's module system of
which workspaces are a part.

A workspace is specified by a go.work file that specifies a set of
module directories with the "use" directive. These modules are used
as root modules by the go command for builds and related operations.
A workspace that does not specify modules to be used cannot be used
to do builds from local modules.

To determine whether the go command is operating in workspace mode,
use the "go env GOWORK" command. This will specify the workspace
file being used.

Usage:

	go work <command> [arguments]

The commands are:

	edit        edit go.work from tools or scripts
	init        initialize workspace file
	sync        sync workspace build list to modules
	use         add modules to workspace file

Use "go help work <command>" for more information about a command.

It doesn't even say what a workspace is. It does kinda say how to make one, and hints at what it means, but it's just not good enough. The final sentence of the one substantive paragraph is unintelligible out of context.
What do they do? Why do I want one? Can I have more than one? What defines a workspace? etc. etc. The second sentence says they are so important they are implemented all over the place. What does that even mean and is it relevant?
The tip to go help modules is probably necessary but contains no direct information about workspaces and is itself a huge topic.
The individual commands add little:
% go help work use
usage: go work use [-r] [moddirs]

Use provides a command-line interface for adding directories,
optionally recursively, to a go.work file.

The -r flag searches recursively for modules in the argument directories.
%

From the go help output alone I cannot understand this feature, what it is, what it solves, whether I should use it or not, and how to use it. Such an important new feature needs proper documentation support in the help system.

CC @matloob @bcmills

@matloob is still working on workspace documentation

@matloob is still working on workspace documentation

That's on me at the moment, I think — I still owe him a review on CL 383854.

Hi, we now have a tutorial at https://go.dev/doc/tutorial/workspaces in addition to the reference documentation in https://go.dev/ref/mod#workspaces. I've submitted a CL (that will be cherry picked onto 1.18 and provides links to both of those docs from go help work.

The aforementioned CL has now been cherry-picked to release-branch.go1.18 via CL 389914 (commit 0b38b0277e43c8304a96cddec7b6180e643fec3b).

I'm hoping that the workspace documentation improvements we've made address the sense that the documentation is uninformative.
Our plan with go command documentation is to have the website be the primary source of documentation rather than the command. So it's intentional that most of the documentation is on the website, and the go command documentation focuses only on the individual commands rather than workspaces as a whole.
If the documentation on the website is confusing or incomplete, we would definitely want to improve it.


bootstrap process workflow, controller/scheduler podaffinity issue

My understanding of the current bootkube workflow is;

bootkube comes up with temporary control plane including short lived bootstrap pods for API server/controller/scheduler
apiTest() waits for API server to be ready
Then we inject the long lived assets (kube-dns, flannel, api server ds, controller deployment, scheduler deployment etc)

In a multi-master deployment, once step 2 is executed nodes still report themselves as "Not Ready". This is because Network/CNI is not yet deployed and functional, and kubelet is not reporting Ready back to the API server. Hence temporary Scheduler pod cannot make appropriate scheduling decisions to apply pod affinity rules. Step 3 takes over and all assets are deployed, nodes start reporting ready, however during the process Scheduler was not effective and multiple scheduler/controller pods end up getting scheduler on the master node where bootkube was executed.
I believe the process may be tweaked to (at a high level):

bootkube comes up with temporary control plane including short lived bootstrap pods for API server/controller/scheduler
apiTest() waits for API server to be ready
CNI/Flannel stack is deployed
New Function checks to make sure all registered nodes (or just master nodes) report ready
we inject the long lived assets (kube-dns, flannel, api server ds, controller deployment, scheduler deployment etc)

I've tested this via forking bootkube to stop the process once API server comes up and deployed a cluster with it;
kubectl get pods --all-namespaces -o wide
NAMESPACE     NAME                                        READY     STATUS    RESTARTS   AGE       IP             NODE
kube-system   bootstrap-etcd-master0                      1/1       Running   0          2m        <IP_ADDRESS>   master0
kube-system   bootstrap-kube-apiserver-master0            1/1       Running   0          2m        <IP_ADDRESS>   master0
kube-system   bootstrap-kube-controller-manager-master0   1/1       Running   0          2m        <IP_ADDRESS>   master0
kube-system   bootstrap-kube-scheduler-master0            1/1       Running   0          2m        <IP_ADDRESS>   master0

kubectl get nodes
NAME      STATUS     AGE       VERSION
master0   NotReady   4m        v1.6.4+coreos.0
master1   NotReady   4m        v1.6.4+coreos.0
master2   NotReady   4m        v1.6.4+coreos.0
worker0   NotReady   4m        v1.6.4+coreos.0

Once the short lived control plane was up, I've deployed flannel
kubectl -n kube-system create -f ./generated/manifests/kube-flannel.yaml
configmap "kube-flannel-cfg" created
daemonset "kube-flannel" created

kubectl get pods --all-namespaces -o wide
NAMESPACE     NAME                                        READY     STATUS    RESTARTS   AGE       IP             NODE
kube-system   bootstrap-etcd-master0                      1/1       Running   0          5m        <IP_ADDRESS>   master0
kube-system   bootstrap-kube-apiserver-master0            1/1       Running   0          5m        <IP_ADDRESS>   master0
kube-system   bootstrap-kube-controller-manager-master0   1/1       Running   0          4m        <IP_ADDRESS>   master0
kube-system   bootstrap-kube-scheduler-master0            1/1       Running   0          4m        <IP_ADDRESS>   master0
kube-system   kube-flannel-2tzln                          2/2       Running   0          24s       <IP_ADDRESS>   worker0
kube-system   kube-flannel-5lnz3                          2/2       Running   0          24s       <IP_ADDRESS>   master1
kube-system   kube-flannel-9nh04                          2/2       Running   0          24s       <IP_ADDRESS>   master2
kube-system   kube-flannel-cstgh                          2/2       Running   0          24s       <IP_ADDRESS>   master0

The nodes reported status ready
 kubectl get nodes
NAME      STATUS    AGE       VERSION
master0   Ready     6m        v1.6.4+coreos.0
master1   Ready     6m        v1.6.4+coreos.0
master2   Ready     6m        v1.6.4+coreos.0
worker0   Ready     6m        v1.6.4+coreos.0

deployed controller manager and scheduler deployments
kubectl -n kube-system create -f ./generated/manifests/kube-scheduler.yaml
deployment "kube-scheduler" created
kubectl -n kube-system create -f ./generated/manifests/kube-controller-manager.yaml
deployment "kube-controller-manager" created

controller and scheduler long lived pods are scheduled to master1 and master2 servers as they have pod affinity rules
kubectl get pods --all-namespaces -o wide | grep -E 'kube-scheduler|kube-controller'
kube-system   bootstrap-kube-controller-manager-master0   1/1       Running             0          9m        <IP_ADDRESS>   master0
kube-system   bootstrap-kube-scheduler-master0            1/1       Running             0          9m        <IP_ADDRESS>   master0
kube-system   kube-controller-manager-2248957630-87gcv    0/1       ContainerCreating   0          3m        <none>         master1
kube-system   kube-controller-manager-2248957630-c4xr5    0/1       ContainerCreating   0          3m        <none>         master2
kube-system   kube-scheduler-1310662694-381nh             0/1       ContainerCreating   0          3m        <none>         master2
kube-system   kube-scheduler-1310662694-gdsgf             0/1       ContainerCreating   0          3m        <none>         master1

This seems like a reasonable approach - but that being said, we've tended towards trying to keep as few coordination points as possible to reduce the internal complexity of bootkube. Although not a hard rule (e.g. we've considered it for other things like making sure DNS service IP doesn't get stolen: https://github.com/kubernetes-incubator/bootkube/issues/136 )
However, with that in mind, I still think we can get to the desired end state without necessarily needing to adding coordination points around CNI & master count.
The master-count can become problematic, for example, because then the assets you've generated might only "work" if you happen to deploy the cluster in a specific way.
Similarly with CNI, this might become more cumbersome to generically support other CNI plugins (calico, weave, etc.) - as their "coordination" points might actually differ.
Instead, the option we're moving forward with at the moment (in tectonic) is to use coordination around labels + required anti-affinity rules.
PR: https://github.com/coreos/tectonic-installer/pull/1129
Related discussion: https://github.com/coreos/tectonic-installer/issues/347#issuecomment-307177869
This would work for supporting both single master and multi-master installations - and essentially allows for co-located pods during version skew (e.g. an "update"), but requires anti-affinity otherwise (so will force replica pods to be spread across hosts).

Missed the latest updates on this topic, thanks @aaronlevy .
Gave 1129 a try, initial provisioning placement looks great to me;
kubectl get pods --all-namespaces -o wide | grep -E 'kube-scheduler|kube-controller'
kube-system       kube-controller-manager-2150839064-68f4n   1/1       Running             1          5m        <IP_ADDRESS>       master0
kube-system       kube-controller-manager-2150839064-wsxpl   1/1       Running             0          5m        <IP_ADDRESS>       master1
kube-system       kube-scheduler-3187535986-qjd0j            1/1       Running             0          5m        <IP_ADDRESS>       master1
kube-system       kube-scheduler-3187535986-x6s2f            1/1       Running             0          5m        <IP_ADDRESS>       master0

I am good to close this


Switch to inflateRaw when inflate header check fails

See chromium/filter/gzip_filter.cc:131

As noted in Mozilla implementation, some servers such as Apache with mod_deflate don't generate zlib headers.
See 677409 for instances where this work around is needed.
Insert a dummy zlib header and try again.

Possible fix for #93 and #45

Coverage decreased (-0.9%) to 99.148% when pulling f10451a83bf6606c4915dd08cc473a57f02e0b9a on gzzhanghao:master into b46c5ea9ee6692676a2824334e24f9d3b95d3b78 on bitinn:master.

Thx for the PR and an explanation to the mystery!
But this is my opinion:

I really don't feel well workaround server problem.
IF we must do so, it should be supported through a well-tested small npm module (is there already one?), we certainly don't want to maintain this ourselves.

On a second thought, why can't we detect zlib deflate from zlib deflateRaw? if we can, we only need to choose zlib inflate and inflateRaw and not add many lines of code.

Actually, if we want to be rough about this, try zlib.inflate and catch any error with zlib.inflateRaw, if none works, throw a custom error to inform users.

Coverage decreased (-0.6%) to 99.381% when pulling 4d981dc5916dc329d011b4c9c936b250d2f08c90 on gzzhanghao:master into b46c5ea9ee6692676a2824334e24f9d3b95d3b78 on bitinn:master.

@bitinn Any update on this?
I've pushed a commit to detect if we should use InflateRaw according to the first byte (not aligned to browsers, hopefully it works :P).
Also, I think we should align to browsers' behaviour AMAP, so I think this workaround is necessary for us.

@gzzhanghao I will keep this open for now, I would like to find a better solution then maintaining our own inflate lib (which is entirely a workaround).

This is now fixed in v1.6.0, I chose a less verbose method, but still thank you very much for pointing me in the right direction.


Update asciidoc plugins, config

Addresses #558

I looked into updating Asciidoctor when prototyping specref and I did it like this.

Latest Asciidoctor Maven plugin doesn't include latest Asciidoctor. I added a new property for it:

...
<properties>
    <asciidoctor-maven.version>2.2.1</asciidoctor-maven.version>
    <asciidoctorj.version>2.5.2</asciidoctorj.version> <!-- <<<<< added line <<<<< -->
    <asciidoctorj-pdf.version>1.6.0</asciidoctorj-pdf.version>
   ...
</properties>
...

and a dependency to the Asciidoctor Maven plugin:

...
<plugin>
    <groupId>org.asciidoctor</groupId>
    <artifactId>asciidoctor-maven-plugin</artifactId>
    <version>${asciidoctor-maven.version}</version>
    <dependencies>
        <!-- >>>>> added dependency >>>>> -->
       <dependency>
           <groupId>org.asciidoctor</groupId>
            <artifactId>asciidoctorj</artifactId>
            <version>${asciidoctorj.version}</version>
        </dependency>
        <!-- <<<<< added dependency <<<<< -->
        <dependency>
            <groupId>org.asciidoctor</groupId>
            <artifactId>asciidoctorj-pdf</artifactId>
            <version>${asciidoctorj-pdf.version}</version>
        </dependency>
    </dependencies>
    ...
</plugin>

Asciidoctor Maven plugin has some breaking changes. These configuration changes were enough for me, though I didn't try rendering a PDF:

<configuration>
    <sourceDirectory>src/main/asciidoc</sourceDirectory> <!-- otherwise warnings are printed -->
    <sourceDocumentName>cdi-spec.asciidoc</sourceDocumentName>
    <attributes>
        <license>${license-file}</license>
        <revremark>${revremark}</revremark>
        <imagesdir>images</imagesdir>
        <source-highlighter>coderay</source-highlighter>
    </attributes>
</configuration>

I have updated the plugin configuration to use the explicit asciidoctorj.version setting and added the addition configuration/attribute changes. The test build with this PR shows no errors/warnings:
https://ci.eclipse.org/cdi/job/CDISpec/8/console

I vaguely recall seeing a 3.0 somewhere else too, but that should be fixed in another PR.


CI fixes

Pull Request Test Coverage Report for Build 8
Warning: This coverage report may be inaccurate.
We've detected an issue with your CI configuration that might affect the accuracy of this pull request's coverage report.
To ensure accuracy in future PRs, please see these guidelines.
A quick fix for this PR: rebase it; your next report should be accurate.

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 69.943%

Totals

Change from base Build 7:
0.0%

Covered Lines:
854

Relevant Lines:
1221

💛  - Coveralls


chore: added repo url

Description:
Added repo URL to package.json

Pull Request Test Coverage Report for Build 258182309

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 257972845:
0.0%

Covered Lines:
19

Relevant Lines:
19

💛  - Coveralls


Coverage

Closes #68

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@91a347c). Click here to learn what that means.
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #70   +/-   ##
=======================================
  Coverage        ?   93.52%
=======================================
  Files           ?       11
  Lines           ?      417
  Branches        ?        0
=======================================
  Hits            ?      390
  Misses          ?       27
  Partials        ?        0

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

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

Did you merge the cancel pr into here?

Yeah, this will look better shortly


co19/LanguageFeatures/nnbd/flow-analysis/reachability_* fail

For example co19/LanguageFeatures/nnbd/flow-analysis/reachability_A05_t03.
/**
 * @assertion other literal: If N is some other literal than the above, then:
 *  Let null(N) = unreachable(before(N)).
 *  Let notNull(N) = before(N)
 * @description Checks reachability after int literal
 *
 * @author<EMAIL_ADDRESS> * @issue 41985
 */
// SharedOptions=--enable-experiment=non-nullable
// Requirements=nnbd-strong

main() {
  late int i;
  if (0 == null) {
    i = 42;  // Variable is initialized in a dead code. This leaves it definitely unassigned
  }
  i;  // It is an error to read a local late variable when it is definitely unassigned.
//^
// [analyzer] unspecified
// [cfe] unspecified
}

The expectation seems reasonable to me.
0 is never equal to null, so the assignment is never reachable.
We currently don't implement operator== fully as specified, we only have promotion of variables to non-nullable. Specifically, we don't have reachability updated.
But when I try to evaluate what the specification says, I don't get the unreachable state.

operator== If N is an expression of the form E1 == E2 then:

Let before(E1) = before(N)
Let before(E2) = after(E1)
Let true(N) = join(join(null(E1), null(E2)), join(notNull(E1), notNull(E2)))
Let false(N) = join(join(null(E1), notNull(E2)),                      join(notNull(E1), null(E2)),                      join(notNull(E1), notNull(E2)))

We need to evaluate true(0 == null).
We have E1 = 0, E2 = null; null(E1) = unreachable, null(E2) = reachable, nonNull(E1) = reachable, nonNull(E2) = unreachable. But join(reachable, unreachable) = reachable. So, both join(null(E1), null(E2)) = reachable, and join(notNull(E1), notNull(E2)) = reachable, and so the whole true(0 == null) = reachable.
So, the assignment is reachable, and the error for the late int i is not reported.
Is there a mistake in my calculations?
@leafpetersen @stereotype441 You noticed another issue in here. Do you want to fix the specification? Or do we keep it as a known issue, and keep the implementation as is? What should we do with co19 tests (there are 26 related tests)?

Leaf and I talked about this a long time ago.  See https://github.com/dart-lang/language/pull/763#discussion_r366642882
My two cents: I think we're getting close enough to the NNBD deadline that for now we should adjust the spec to match what we currently have implemented; if time allows, we can always follow up with an improvement later.

I think this is not planned, is that correct @stereotype441 ?

I suspect this was addressed by e403e6ae77c1c6fabd5dd5a9db26b63f5a416057, but unfortunately I don't have time to confirm right now.  I'll double check when I return from vacation on Wednesday.

This seems to have been fixed.

Confirmed that this was fixed by e403e6ae77c1c6fabd5dd5a9db26b63f5a416057.


Typescript "defineProps" removes "Boolean" type in production

Version
3.2.21
Reproduction link
github.com
Steps to reproduce
Set type "boolean" in the type annotation of "defineProps" macro, like this:
<script setup lang="ts">
defineProps<{ callable?: boolean }>();
</script>

run npm run build command
What is expected?
Component props to be inferred as
props: {
    callable: Boolean, // or {type: Boolean, required: false}
  }

What is actually happening?
Component props is inferred as
props: {
    callable: null,
  }

The reason being is that I can't use callable shortcut on a component instead of :callable="true".
This works in development thought (and was hard to spot on production :)))

Duplicate of https://github.com/vuejs/vue-next/issues/4783


start plugin from a uninstalled blender (ie, only unzipped to filefolder) on windows

Fails to load DLL:
import prman_for_python_3 as prman_for_python
(prman.py, line 77).
It works when I installed using a blender installer instead. I tried setting path to include %RMANTREE%bin\ and pythonpath to include both the bin and lib folder, but that did not help. Simply installing blender using the installer however, and it works immediately. It does still not work from the buildbot (nightly builds). I'm unsure of the reason. Could it have to do with os protection of program files folders? Or does the blender installer setup path variables of importance? Where? In settings the path and pythonpath at least are unchanged.
(The path and pythonpath does look correct and include the correct folders, and I can run the prman.exe from the commandline without being in the folder.)
Running windows 10, downloaded prman (20.6) and prman for blender today (latest).
Best wishes,
Torbjörn

Hey Torbjorn!  Happy new year.
Usually you don't have to set the pythonpath and other env variables unless you're installing PRMan to a non-standard location (not C:\Program Files).  That said.  If you ARE installing PRMan to a non-standard location, you should just need to set RMANTREE to where you install it, and everything else should be taken care of.

Brian,
I think that the problem is on the Blender side of things. I just tested an experimental version of Blender and it has problems that a normal release does not. I don't see this as a problem that we could correct.

Ohhhh.... possibly the newest version is built on python 3.5?
On Sat, Jan 2, 2016 at 6:05 PM, MWY3510<EMAIL_ADDRESS>wrote:

Brian,
I think that the problem is on the Blender side of things. I just tested
an experimental version of Blender and it has problems that a normal
release does not. I don't see this as a problem that we could correct.
—
Reply to this email directly or view it on GitHub
https://github.com/bsavery/PRMan-for-Blender/issues/165#issuecomment-168449952
.

--
<EMAIL_ADDRESS>508-274-8700

Now that's a quick response! However, you misunderstand me. I did make sure to set those variables only because I got that error and did not understand why I did not get it to work. It really seemed like a path error to me. I installed PRMAN to default location. But I usually use buildbot builds of blender (builder.blender.org, ie unstable nightly builds) and have several builds installed at the same time. Usually you do not need to install blender, it is enough to just unzip it. Interestingly I was unable to install the addon (copying it to the addon folder or selecting the zip and installing from file makes it appear in the addon list, but when I try to click to activate it I get the error that it does not find a dll and points to line 77 as written above. I have been able to install other addons. I do not know why this does not work. I do not have any concurrent experience of windows application development, and I do not know if the os protects the program file folder or if I would have needed to run blender as an administrator if run from a different location. However, the official install works. I do not know what's different in their environments.

Yes, the newest builds have python 3.5 Is that a problem?

The official build has 3.4.2.

So the addon is all just python code and version agnostic.  However it
loads a dll from RMANTREE that is compiled to python 3.4.  I thought python
plugins compiled to 3.4 should be forward compatable... but it's possible
they're not
On Sat, Jan 2, 2016 at 6:11 PM, tobbew79<EMAIL_ADDRESS>wrote:

The official build has 3.4.2.
—
Reply to this email directly or view it on GitHub
https://github.com/bsavery/PRMan-for-Blender/issues/165#issuecomment-168450100
.

--
<EMAIL_ADDRESS>508-274-8700

My experience in python is just for scripting purposes, so I would not know. It took me a couple of hours before I tried installing an older official build using an installer.
I tested installing the addon in a blender 2.75 (python 3.4.2) which is not installed using an installer, and it works fine there. It could be the python version then. It that'd be confimed, perhaps the rendermanproserver-20.6/bin/prman.py should have more controls for it's supported python versions before line 77 and give a more informative message. If this would not be changed there perhaps the init.py of the blender addon could check to give a message, or at lest this could perhaps be written somewhere close to the download link and in the documentation somewhere. I'm currently downloading the official build in zip form to see if it works there.

Fair enough.  I had it on my list to test the dll with python 3.5...
On Sat, Jan 2, 2016 at 6:43 PM, tobbew79<EMAIL_ADDRESS>wrote:

My experience in python is just for scripting purposes, so I would not
know. It took me a couple of hours before I tried installing an older
official build using an installer.
I tested installing the addon in a blender 2.75 (python 3.4.2) which is
not installed using an installer, and it works fine there. It could be the
python version then. It that'd be confimed, perhaps the
rendermanproserver-20.6/bin/prman.py should have more controls for it's
supported python versions before line 77 and give a more informative
message. If this would not be changed there perhaps the init.py of the
blender addon could check to give a message, or at lest this could perhaps
be written somewhere close to the download link and in the documentation
somewhere. I'm currently downloading the official build in zip form to see
if it works there.
—
Reply to this email directly or view it on GitHub
https://github.com/bsavery/PRMan-for-Blender/issues/165#issuecomment-168450852
.

--
<EMAIL_ADDRESS>508-274-8700

Confirms it works with 2.76b just unzipped without installation, so it might very well be the python version then.

Just to be clear, I've confirmed that the prman python dll loads in python 3.5

That's really comforting to know. Thank you for sharing that information. Then it should not be a problem to solve this in the future, and it should not have to involve you.


[feature] Confirm exiting application while flashing image

v1.0.0-beta.15 - 2016-09-26
macOS x86

While an image is being flashed, it's too easy to close Etcher unintentionally. I believe it would be a helpful feature to show a confirm() dialog before quitting while an image is being flashed.

Great idea! I'm sure Electron provides a way to intercept a close event. The FlashStateModel component also provides a nice isFlashing() method that can be used to either allow the user to close the app directly, or show the confirmation modal.

Created a simple warning modal to alert the user if they close the application while an image is being flashed.

Looks good. But I think "...sure you want to..." is more idiomatic than "...sure you would like to..."

It's worth noting that the implications of this action aren't immediately clear to the user. I think that adding a sentence explaining what will happen would be nice. Also, currently "what will happen" is that Etcher will continue flashing headless :laughing:

Hmm, given that the dialog in #840 says "You will be able to overwrite your system drives if you're not careful.", maybe this dialog could also say something like "This may leave your drive in an unusable state." ?

Also, currently "what will happen" is that Etcher will continue flashing headless :laughing:

Yeah, that's a bug #850

Updated copy on design.

@taahirisaacs Looks good! Following @konmouz line of thoughts regarding these kinds of modals, I think we can remove the "Cancel" button and just present "Yes, continue". The user can dismiss the modal by clicking somewhere else or in the top right corner cross icon.

I think we can remove the "Cancel" button and just present "Yes, continue".

No! Please, no! Having just a "dismiss" button on actions like this is detrimental for the user. I have yet to see an existing app by a notable company or group that doesn't have a "no" option on dialog boxes like this, and there's a good reason for that: "dismissing" the warning of imminent danger is not the same as aborting the action that caused it. In the other recent case of the "unsafe mode" dialog, there wasn't an immediate threat, so I didn't have a significant issue with it; but in this case, it really does matter.
Having the "dismiss" button is great and gives the user a quick and natural choice, but it doesn't work for all cases, especially when the user intentionally initiated the offending action.

@taahirisaacs we can just remove the 'X' on this modal. In general when there is a question we need to have 'yes and no' CTAs. On the contrary when you need to make a selection (like when you select a drive) there could be just a 'continue' CTA and an 'X' one to dismiss.


Depricated API?

When I try to build my Cordova 6 app for Android with this plugin, I get this error:
"Note: Some input files use or override a deprecated API."
This happens only when I add this plugin.
My Android SDKs are all up to date.
Plugin version: 2.2.5
Platform: Android
OS version: 6
Device manufacturer / model: Several
Cordova version (cordova -v): 6.4.0
Cordova platform version (cordova platform ls): 6.0.0

Notice: this issue has been closed because it has been reported for branch 2.x or later. It could be already fixed in v3 or is not relevant anymore. You may reopen this issue if it has been closed in error.


Avoid running concurrent checkpointing + gc

It's not safe to have concurrent checkpointers running for a timeline.
Simple solution is probably just wrapping checkpoint routine with a Mutex?
Maybe GC is safe because a lock is held for the duration?

@patins was this done already? @hlinnaka mentioned that he thinks we don't have this issue anymore

Concurrent checkpoints are still possible, they are executed by at least: checkpointer loop thread, timeline shutdown, GC w/ checkpoint_before_gc = true.
I never figure out if concurrent checkpoint + GC is safe, that might still be an issue as well


[PE-D] corrupted addressbook.json data

if i edit the json file and it gets corrupted, there is no error message upon startup and the file is completely deleted.
One possible way would be to change the file name of the corrupted file and give the user an error message so that the user can try to manually save their data.

Labels: type.FeatureFlaw severity.Medium
original: muhammad-faruq/ped#8

Possible to show error message?


prepend public path to output src if present

This is needed to support CDN scenarios.

Hi Mark. Thanks for making the plugin. Let me know if there is anything else I need to do to get this merged. Cheers.

@markdalgleish any update on merging this? Thanks.

Just got bit by this myself. On Android versions of Google Chrome, it seems to cause issues whether or not one uses a CDN: given a tree that includes this...
public
├── img
│   └── a5fad71f02af5c65a136d7c1954117c2.png
└── manifest-b5154266300fae0ce2ee91a1366c7325.json

...and JSON that includes this...
"icons": [
  {
    "src": "img/a5fad71f02af5c65a136d7c1954117c2.png",
    "type": "image/png",
    "sizes": "144x144"
  }
]

...Chrome shows a broken image for the relatively-referenced icon and refuses to display the app banner.
Is there any path to getting this merged in, @markdalgleish? It looks beautifully thought-out and tested, at least to my untrained eye.

Ping @markdalgleish could you please take a look at this and publish a new release of this loader?


[HOLD for payment 2024-03-07] Upgrade Reanimated to 3.7.0+

For context, this task is just a branched-off subtask of enabling the new React Native architecture in E/App.
Problem
Reanimated 3.6.1 does not work with Fabric in React Native 0.73, preventing us from enabling the new arch.
Solution
Upgrade to Reanimated 3.7.0

@garrettmknight someone from SWM will comment soon to assign themselves to this.

Hey! I'm Bartosz from Software Mansion and I would like to work on this task.

Clarifying here that whatever C+ is assigned should be paid $250 for their review of https://github.com/Expensify/App/pull/36404 instead of the standard $500

Currently waiting on C+ review from @allroundexperts, and it looks like he's started reviewing

Payment summary:

Contributor: @BartoszGrajdek
Contributor+: @allroundexperts $500

Please request!

$500 approved for @allroundexperts based on summary.


Save logs to file

Could use flexi_logger for instance https://docs.rs/flexi_logger/0.25.3/flexi_logger/ or fern https://github.com/daboross/fern


Enable label annotation animations

Fix: #539
Partially address: #535

Filename
Size
Change

dist/chartjs-plugin-annotation.esm.js
11.2 kB
-155 B (-1%)

dist/chartjs-plugin-annotation.js
11.3 kB
-156 B (-1%)

dist/chartjs-plugin-annotation.min.js
7.64 kB
+38 B (0%)

@kurkle first of all, apologize... yesterday I havent udenrstood what you meant but now yes.
You moved the properties about stored value as properties of the element and then you configured them as animated....
Really sorry but I didn't think to implement as you wrote... Probably this approach could be also used in other annotations.
Let me review better your updates..

@kurkle apoligize again for I'm poor knowledge on the animation engine...
But I was looking for animation activation since the first drawing of the chart. It seems that annotations, at the first drawing, are located to the final position.
Maybe it could be good to animate them during the first drawing as well.
Having a look to the code, I don't seen how to enable it at first drawing (it seems already implemented):
https://github.com/chartjs/chartjs-plugin-annotation/blob/ef7bf770652f21fd151ea3043156b4dbadd59064/src/annotation.js#L122-L127

It's the reset state that should be the animation starting point for first draw, as seen on Chart.js controllers. It's just not handled for animations, but should be quite easy to handle. But the problem is, I'm not sure what annotations should do by default. Appear from some edge? Or grow from zero size? Maybe fade the colors in? It's not going to please everyone.

ok, let's stay as is. Anyway I'm going to try it, to see how it will look like.

Actually it looks like the initial reset is only applied to updating new elements on controllers. Plugins do not receive it.
I was thinking we should make the initial element state configurable in Chart.js, but maybe it could be done in this plugin only (to start with)
Anyhow, you can try for example this:
export default class LineAnnotation extends Element {
  constructor() {
    super();
    this.options = {
      borderColor: 'transparent',
    };
  }
...

The lines are transparent to begin with. Chart.js does not seem to animate the sub-objects in options (eg. label.backgroundColor), that should be fixed.

@kurkle uhm... by default, if I have seen correctly, 'color', 'borderColor', 'backgroundColor' are the default properties of animations, type color.
We need to do the same think that you have done here, I guess, setting specific properties on the element for all subnodes. Correct?

@kurkle uhm... by default, if I have seen correctly, 'color', 'borderColor', 'backgroundColor' are the default properties of animations, type color.
We need to do the same think that you have done here, I guess, setting specific properties on the element for all subnodes. Correct?

Yes, but it turns out that
this.options = {
  borderColor: 'transparent',
  label: {
    backgroundColor: 'transparent'
  }
}

does not animate the label backgroundcolor. I assume this is an limitation of the animator in Chart.js (did not take a look, and don't remember anymore the specifics)

I think the engine is currently using ONLY properties of the element (but I didn't check) therefore all properties of subnodes should be ignored.
Nevertheless I still have some doubts about also width and height, because, even if they are numbers to animated, it doesn't seem it's happening.

I assume this is an limitation of the animator in Chart.js (did not take a look, and don't remember anymore the specifics)

It seems so. it could be great to configure the property with its path, something like:
animations: {
  colors: {
    type: 'color',
    properties: ['color', 'borderColor', 'backgroundColor', 'label.borderColor', 'label.backgroundColor' ]
  },
},

@kurkle I think we could merge this and then enable other options to be animated with another PR. What do you think?

Sure, I will fix the merge conflicts soon, when I'm free from other work.

Sure, I will fix the merge conflicts soon, when I'm free from other work.

Sorry, I didn't want to push you. I didn't know if you wanted to add this additional options... I'm doing other stuff too.

Sure, I will fix the merge conflicts soon, when I'm free from other work.

Sorry, I didn't want to push you. I didn't know if you wanted to add this additional options... I'm doing other stuff too.

No problem, was just busy and wanted to let you know. Will do the rebase now.

Hmm, I'll investigate these random failures a bit still, found a way to reproduce consistently locally.

Did not find the real cause. But with random seed 94637 I get a consistent failure in fixtures/label/stylingPoint.js

The failure is because measureText returns different values than normally:
key: This is my text,and this is the second row of my textnormal 12px 'Helvetica Neue', 'Helvetica', 'Arial', sans-serif
w/h:<PHONE_NUMBER>75 28.799999999999997
No fail:
key: This is my text,and this is the second row of my textnormal 12px 'Helvetica Neue', 'Helvetica', 'Arial', sans-serif
w/h: 232 28.799999999999997

Sometimes it happens to me as well, but when I relaunch it works... maybe I'm wrong because I'm not an expert of karma, but it sounds related to it. Every time that I'm testing locally, with the browser, the rendering it's always fine.
Maybe some config in karma?

it happens clip-false test case too. But it's really random.

Can repeat by passing the seed: http://localhost:9876/debug.html?seed=94637

@kurkle FYI
><EMAIL_ADDRESS>build
> rollup -c

src/index.js → dist/chartjs-plugin-annotation.js...
(!) Circular dependencies
src\helpers\index.js -> src\helpers\helpers.canvas.js -> src\helpers\index.js
src\helpers\index.js -> src\helpers\helpers.chart.js -> src\helpers\index.js
created dist/chartjs-plugin-annotation.js in 219ms

src/index.js → dist/chartjs-plugin-annotation.min.js...
(!) Circular dependencies
src\helpers\index.js -> src\helpers\helpers.canvas.js -> src\helpers\index.js
src\helpers\index.js -> src\helpers\helpers.chart.js -> src\helpers\index.js
created dist/chartjs-plugin-annotation.min.js in 768ms

src/index.esm.js → dist/chartjs-plugin-annotation.esm.js...
(!) Circular dependencies
src\helpers\index.js -> src\helpers\helpers.canvas.js -> src\helpers\index.js
src\helpers\index.js -> src\helpers\helpers.chart.js -> src\helpers\index.js
created dist/chartjs-plugin-annotation.esm.js in 178ms


Align organizations with current website

Description
This PR is intended to align the organizations added to the existing website. I'll leave it open until we make the full migration and update the home page to target this repo.

[x] I have read the Contributing Guidelines

I was planning to leave this open in case new orgs are added until the new site launch


Add a Recursion Breaker to Opaque Type Substitution

The current check in MiscDiagnostics can only handle local 2-cycles as in:
func foo() -> some P { return bar() }
func bar() -> some P { return foo() }
Larger cycles, such as the 3-cycle present in the validation test in this patch cannot be detected without resolving all substitutions up front. Therefore, we take the tact that we can at least prevent the compiler from crashing. At runtime, instead, type resolution will blow out the stack.
The check here is simple: Plumb through a set of opaque type decls that the resolution machinery has already seen, and if we encounter a recursive opaque type substitution bail with the original opaque type.
rdar://87121502

@swift-ci smoke test

@swift-ci smoke test

Docker's busted
@swift-ci smoke test Linux platform

@swift-ci smoke test


has same owner from 0x2A1049062c6Cfd69bd38fbaf3b0559DF1DBbc92c 0x02CA4101eA84f400c62b3BeB87Fb5450a8702941

Related Safe Addresses
0xd2749489a4b7c3754f83bad20eb8bef5ab61bdbb
0xd3ae95bbd12fc31335ce5f884b1782bd7251edd7
0xeed778bc497ac8f8104a54f3ae2116a9aa27594e
0xfa709bf66d44526302a53821b5126746a45ba82a
0x8CA6fb6A34dA6B5f486f977c5E1c7eB021233625
0x54d2f913348f79bbddcd62d4eedc8f39fe851654
0x58d0c3df11c938aca49b4ba7ceeedc8abda066d1
0x668b9bd7c09f448dc94a883863e7115f84fa529c
0xa15f1754d25a5e97028323b56ba8bea5c48a8e6a
0xa40320e6495ec554645746af3e36209a0e08871d
0xc1906daafdd4b782221db9250ab36242d8229b76

-->
Reasoning
Those Vault has same owner by 0x8CA6fb6A34dA6B5f486f977c5E1c7eB021233625 .
And same creator from 0x2A1049062c6Cfd69bd38fbaf3b0559DF1DBbc92c 0x02CA4101eA84f400c62b3BeB87Fb5450a8702941
Methodology
I check the safe vault who has same tokens and same creator, Then manually detect if they were created by the same person.
Safe Address
0x88A253aD0be9081b6D520B91a7e620eDd6Ad5c7b

Reasoning
Those Vault has same owner by 0x8CA6fb6A34dA6B5f486f977c5E1c7eB021233625 . And same creator from 0x2A1049062c6Cfd69bd38fbaf3b0559DF1DBbc92c 0x02CA4101eA84f400c62b3BeB87Fb5450a8702941

Creating several Safes with the same owner/creator is not airdrop farming per se but quite common.
Please elaborate on why you think this is airdrop farming and how you can be sure to not eliminate legitimate usage.

We haven't received any further information on this ticket and therefore deemed this submission invalid.
Unfortunately just the pure fact that Safes...

were created by the same address
have the same owner
conducted the same transactions
received assets from the same address

... is not enough reasoning for a valid submission, as there are legit user behaviour leading to such as well (relayer, scripts, power users, exchanges)
This submission didn't provide sufficient indicators to convince the team that there is some targeted airdrop farming behind the provided addresses. As per the rules, when in doubt we will default in favor of the airdrop recipients in order to not risk any false positives when sorting out airdrop hunters.


Server Crash after using dispatcher to send broadcast to nakama-godot client

Before you submit an issue we recommend you drop into the community forum and ask any questions you have or mention any problems you've had getting started with the server.
Please provide as much information as you can with this issue report. If you believe it may be an issue with one of the client libraries please report it on their own trackers.
Model Name:	MacBook Pro
Model Identifier:	MacBookPro15,1
Processor Name:	6-Core Intel Core i7
Processor Speed:	2.6 GHz
Number of Processors:	1
Total Number of Cores:	6
L2 Cache (per Core):	256 KB
L3 Cache:	9 MB
Hyper-Threading Technology:	Enabled
Memory:	16 GB
Description
Steps to Reproduce

Register a new user
Connect to server socket
add to matcher
join match after on_matched is called
5 send broadcast to clients using nill in game loop then error.

Expected Result
{"level":"info","ts":"2020-02-06T12:41:39.650+0100","msg":"My body no go gree","mid":"937ced6b-5005-4097-a90f-8f2c55d08ed9"}
{"level":"info","ts":"2020-02-06T12:41:39.650+0100","msg":"User added to match 'table: 0xc000a28000'","mid":"937ced6b-5005-4097-a90f-8f2c55d08ed9"}
{"level":"debug","ts":"2020-02-06T12:41:39.650+0100","msg":"Processing presence event","joins":1,"leaves":0}
{"level":"debug","ts":"2020-02-06T12:41:39.650+0100","msg":"Sending *rtapi.Envelope_Match message","uid":"889c3b43-eeb1-4c73-983f-bc76ca04ac9d","sid":"396d69ac-d185-4198-a95e-f20014763ca7","envelope":"cid:"2" match:<match_id:"937ced6b-5005-4097-a90f-8f2c55d08ed9.nakama-node-1" authoritative:true label:<value:"Quickplay" > size:1 presences:<user_id:"1831b11b-2da0-4e46-a2be-f8e8a5d3f530" session_id:"826cc6e4-5aca-40f2-8c36-5bfed282da97" username:"ashtonkase" > self:<user_id:"889c3b43-eeb1-4c73-983f-bc76ca04ac9d" session_id:"396d69ac-d185-4198-a95e-f20014763ca7" username:"G:10115341080" > > "}
{"level":"warn","ts":"2020-02-06T12:41:40.589+0100","msg":"Stopping match after error from match_loop execution","mid":"937ced6b-5005-4097-a90f-8f2c55d08ed9","tick":0,"error":"runtime error: invalid memory address or nil pointer dereference\ngoroutine 412 [running]:\ngithub.com/yuin/gopher-lua.(*LState).PCall.func1(0x52b6b08, 0xc0004553f0, 0xc001293bc0, 0x0, 0x0, 0x2)\n\tgithub.com/yuin/gopher-lua@v0.0.0-20190514113301-1cd887cd7036/state.go:1964 +0x633\npanic(0x4f067e0, 0x5fb2470)\n\truntime/panic.go:679 +0x1b2\ngo.uber.org/atomic.(*Bool).Load(...)\n\tgo.uber.org/atomic@v1.4.0/atomic.go:233\ngithub.com/heroiclabs/nakama/v2/server.(*RuntimeLuaMatchCore).broadcastMessage(0xc00119e140, 0xc0004553f0, 0x2)\n\tgithub.com/heroiclabs/nakama/v2@/server/runtime_lua_match_core.go:513 +0x2a\ngithub.com/yuin/gopher-lua.callGFunction(0xc0004553f0, 0x0, 0xc0012b2ac0)\n\tgithub.com/yuin/gopher-lua@v0.0.0-20190514113301-1cd887cd7036/vm.go:163 +0x40\ngithub.com/yuin/gopher-lua.init.3.func26(0xc0004553f0, 0xc07c140205, 0xc001272000, 0x0)\n\tgithub.com/yuin/gopher-lua@v0.0.0-20190514113301-1cd887cd7036/vm.go:764 +0x3ae\ngithub.com/yuin/gopher-lua.mainLoopWithContext(0xc0004553f0, 0xc001272000)\n\tgithub.com/yuin/gopher-lua@v0.0.0-20190514113301-1cd887cd7036/vm.go:60 +0x11d\ngithub.com/yuin/gopher-lua.(*LState).callR(0xc0004553f0, 0x5, 0xffffffffffffffff, 0x2)\n\tgithub.com/yuin/gopher-lua@v0.0.0-20190514113301-1cd887cd7036/state.go:1191 +0x248\ngithub.com/yuin/gopher-lua.(*LState).Call(...)\n\tgithub.com/yuin/gopher-lua@v0.0.0-20190514113301-1cd887cd7036/state.go:1943\ngithub.com/yuin/gopher-lua.(*LState).PCall(0xc0004553f0, 0x5, 0xffffffffffffffff, 0x0, 0x56030e0, 0xc00098f1c0)\n\tgithub.com/yuin/gopher-lua@v0.0.0-20190514113301-1cd887cd7036/state.go:2006 +0x136\ngithub.com/heroiclabs/nakama/v2/server.(*RuntimeLuaMatchCore).MatchLoop(0xc00119e140, 0x0, 0x50a7440, 0xc00092b620, 0xc00092baa0, 0x4041d8c, 0xc00040bfd8, 0x8, 0x0)\n\tgithub.com/heroiclabs/nakama/v2@/server/runtime_lua_match_core.go:454 +0x2bf7\ngithub.com/heroiclabs/nakama/v2/server.loop(0xc0013b8ea0)\n\tgithub.com/heroiclabs/nakama/v2@/server/match_handler.go:256 +0x91\ngithub.com/heroiclabs/nakama/v2/server.NewMatchHandler.func2(0xc0013b8ea0)\n\tgithub.com/heroiclabs/nakama/v2@/server/match_handler.go:182 +0x157\ncreated by github.com/heroiclabs/nakama/v2/server.NewMatchHandler\n\tgithub.com/heroiclabs/nakama/v2@/server/match_handler.go:169 +0x6ac\n\nstack traceback:\n\t[G]: in function 'broadcast_message'\n\tdata/modules/quickplay.lua:56: in main chunk\n\t[G]: ?"}
Actual Result

Context
Using Nakama-Godot official plugin v1.0
Your Environment

Nakama: 2.9.1+8f527a71
Database: CockroachDB CCL v19.2.2 (x86_64-apple-darwin14, built 2019/12/11 01:27:47, go1.12.12)
Environment name and version:
Model Name:	MacBook Pro
Model Identifier:	MacBookPro15,1
Processor Name:	6-Core Intel Core i7
Processor Speed:	2.6 GHz
Number of Processors:	1
Total Number of Cores:	6
L2 Cache (per Core):	256 KB
L3 Cache:	9 MB
Hyper-Threading Technology:	Enabled
Memory:	16 GB
Operating System and version:
OSX Catalina

=============GDSCRIPT ======
extends Control
var game_center = null
var _settings = {
"credentials": {
"display_name":"",
"email":"",
"password":""
}
}
var scheme = "http"
export var host = "<IP_ADDRESS>"
#export var host = "<IP_ADDRESS>"
export var port = 7350
var server_key = "defaultkey"
var client := Nakama.create_client(server_key, host, port, scheme)
var session : NakamaSession = null
var socket = null
Called when the node enters the scene tree for the first time.
func _ready() -> void:
Settings.save_settings(_settings)
Settings.load_settings(_settings)
# check if the user login details is available
if  OS.get_name() == "iOS" and Engine.has_singleton("GameCenter"):
game_center = Engine.get_singleton("GameCenter")
#var result = game_center.get_instance_id()
if game_center.is_authenticated():
game_center.request_identity_verification_signature()
else:
$Label.set_text("An error Occured, Exiting")
$Timer.start(3)
elif OS.get_name() == "Android":
pass
elif OS.get_name() == "OSX":
var file2Check = File.new()
var doFileExists = file2Check.file_exists(Settings.SAVE_PATH);
if (doFileExists):
var display_name = Settings.get_setting(_settings,"credentials", "display_name")
var email = Settings.get_setting(_settings,"credentials", "email")
var password = Settings.get_setting(_settings,"credentials", "password")
if(email != null && password != null && display_name != null && email != "" && password != ""  && display_name != ""):
session  = yield(client.authenticate_email_async(email, password,display_name), "completed")
print("Printing session :: ",session.token)
if session.is_valid() :
$Label.set_text("Searching for players")
socket = Nakama.create_socket_from(client)
socket.connect("connected", self, "_on_socket_connected")
socket.connect("closed", self, "_on_socket_closed")
socket.connect("received_error", self, "_on_socket_error")
socket.connect("received_matchmaker_matched", self, "_on_received_matchmaker_matched")
socket.connect("received_match_state", self, "_on_received_match_state")
socket.connect("received_match_presence", self, "_on_received_match_presence")
yield(socket.connect_async(session), "completed")
#var ticket = yield(socket._send_async({ "matchmaker_add": {"min_count": 2,"max_count": 2,"query": ""}}),"completed")
var ticket = yield(socket.add_matchmaker_async("",2,2,{},{}),"completed")
print("Ticket : ",ticket.ticket)
print("Done")
else:
$Label.set_text("An error Occured, Exiting")
$Timer.start(2)
pass
else:
$Label.set_text("An error Occured, Exiting")
$Timer.start(2)
else :
$Label.set_text("An error Occured, Exiting")
$Timer.start(2)
func _on_socket_connected():
print("Socket connected.")
func _on_socket_closed():
print("Socket closed.")
func _on_socket_error(err):
printerr("Socket error %s" % err)
func _on_received_matchmaker_matched(p_matchmaker_matched):
$Label.set_text("Player Matched")
print("Player Matched %s" % p_matchmaker_matched.match_id)
#Now join the match
var join = yield(socket.join_matched_async(p_matchmaker_matched),"completed")
print("Join Match : ",join)
#print("Matched")
func _on_received_match_state(p_match_state):
print("Received Match State %s" % p_match_state)
func _on_received_match_presence(p_match_presence_event):
print("Received Presence  event %s" % p_match_presence_event)
func _process(delta: float) -> void:
if  OS.get_name() == "iOS" and Engine.has_singleton("GameCenter"):
check_events()
func _on_FadeIn_fade_finished() -> void:
get_tree().change_scene("res://scenes/Home.tscn")
func _on_Timer_timeout() -> void:
$FadeIn.show()
$FadeIn.fade_in()
func check_events():
while game_center.get_pending_event_count() > 0:
var event = game_center.pop_pending_event()
if event.type == "authentication":
if event.result == "ok":
pass
else:
$Label.set_text("An error Occured, Exiting")
$Timer.start(2)
elif event.type == "identity_verification_signature":
if event.result == "ok":
#logging to nakama using the gotten credentials
#authenticate_game_center_async(p_bundle_id : String, p_player_id : String, p_public_key_url : String,
#p_salt : #String, p_signature : String, p_timestamp_seconds : String, p_username = null, p_create : bool = true, p_vars = null)
print(event)
session  = yield(client.authenticate_game_center_async("whotfire",event.player_id,event.public_key_url,event.salt,event.signature,  str(event.timestamp),  str(event.player_id),true),"completed")
print("Printing session :: ",session.token)
if session.is_valid():
$Label.set_text("Searching for players")
socket = Nakama.create_socket_from(client)
socket.connect("connected", self, "_on_socket_connected")
socket.connect("closed", self, "_on_socket_closed")
socket.connect("received_error", self, "_on_socket_error")
socket.connect("received_matchmaker_matched", self, "_on_received_matchmaker_matched")
socket.connect("received_match_state", self, "_on_received_match_state")
socket.connect("received_match_presence", self, "_on_received_match_presence")
yield(socket.connect_async(session), "completed")
				var ticket = yield(socket.add_matchmaker_async("*",2,2,{},{}),"completed")
				print("Ticket : ",ticket.ticket)
				print("Done")
			else:
				$Label.set_text("An error Occured, Exiting")
				$Timer.start(2)
				pass
		else:
			$Label.set_text("An error Occured, Exiting")
			$Timer.start(2)

@stonekase Please can you share the Lua code you've configured for the matchmaker callback?

@stonekase Please can you share the Lua code you've configured for the matchmaker callback?

Match_init
local nk = require("nakama")
-- For example let's create a two player authoritative match.
local function matchmaker_matched(context, matched_users)
-- print matched users
for _, user in ipairs(matched_users) do
local presence = user.presence
nk.logger_info(("Matched user '%s' named '%s'"):format(presence.user_id, presence.username))
for k, v in pairs(user.properties) do
nk.logger_info(("Matched on '%s' value '%s'"):format(k, v))
end
end
nk.logger_info("Creating a Quickplay match")
local modulename = "quickplay"
local setupstate = {invited = matched_users}
local matchid = nk.match_create(modulename, setupstate)
return matchid
end
nk.register_matchmaker_matched(matchmaker_matched)
=====================quickplay===================
local nk = require("nakama")
--local du = require("debug_utils")
local M = {}
function M.match_init(context, setupstate)
local state = {
presences = {}
}
nk.logger_info("Timaya don come again")
local tickrate = 1 -- per sec
local label = "Quickplay"
return state, tickrate, label
end
function M.match_join_attempt(context, dispatcher, tick, state, presence, metadata)
local acceptuser = true
return state, acceptuser
end
function M.match_join(context, dispatcher, tick, state, presences)
nk.logger_info("My body no go gree")
for _, presence in ipairs(presences) do
state.presences[presence.session_id] = presence
nk.logger_info(("User added to match '%s'"):format(state.presences[presence.session_id]))
end
return state
end
function M.match_leave(context, dispatcher, tick, state, presences)
for _, presence in ipairs(presences) do
state.presences[presence.session_id] = nil
end
return state
end
function M.match_loop(context, dispatcher, tick, state, messages)
for _, presence in pairs(state.presences) do
--nk.logger_info(("Presence %s named %s"):format(presence.user_id, presence.username))
--.broadcast_message(101, "", nil, nil)
end
for _, message in ipairs(messages) do
nk.logger_info(("Received %s from %s"):format(message.data, message.sender.username))
local decoded = nk.json_decode(message.data)
for k, v in pairs(decoded) do
nk.logger_info(("Message key %s contains value %s"):format(k, v))
end
print("Data Message : '%s'", message.data)
print("Data Sender : '%s'", message.sender)
-- PONG message back to sender
local status, result = pcall(dispatcher.broadcast_message(1, message.data, nil,{message.sender}))
if (not status) then
nk.logger_error(("Error occurred: %q"):format(result))
end
end
local opcode = 1234
local message = { ["hello"] = "world" }
local encoded = nk.json_encode(message)
local presences = nil -- send to all.
local sender = nil -- used if a message should come from a specific user.
dispatcher.broadcast_message(opcode, encoded, presences, sender)
return state
end
function M.match_terminate(context, dispatcher, tick, state, grace_seconds)
local message = "Server shutting down in " .. grace_seconds .. " seconds"
dispatcher.broadcast_message(2, message)
return nil
end
return M

Thanks for reporting this! Fixed in https://github.com/heroiclabs/nakama/commit/76d7c1404eced863f1b08598b04682e2f7d810b9 and will be part of the next release. If you need to you can use 2.8.0 for now, it's unaffected by this issue.


Lab 1

Fixes #
Review of colleague's PR #
Changes proposed in this PR:
-

Please don't label PR with failing CI build as Ready for review.
Please go through the common high level code review comments collected from other PRs - they might be useful to you as well.

Codecov Report

Merging #150 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master   #150   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           1      2    +1
  Lines           2     18   +16
=====================================
+ Hits            2     18   +16

Impacted Files
Coverage Δ

01_fib/kasunfdo/main.go
100% <0%> (ø)

Continue to review full report at Codecov.

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


Update README.md - added OCR API library

Added a unified and free OCR API library - available in several programming languages. Thanks!

unified and free

What does "unified" mean? What engine runs in the backend? And how "free" is it?

Unified refers to a single API solution that's integrated, and the free (without expiration) tier offers 800 API calls/month across the entire library.


Error log

HI
I tried to install the neo-gui and the error log shows this: System.NotSupportedException An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information. at System.Reflection.RuntimeAssembly.nLoadFile(String path, Evidence evidence) at System.Reflection.Assembly.LoadFile(String path) at Neo.Plugins.Plugin.LoadPlugins(NeoSystem system) at Neo.Program.Main()
How do I fix this so the client will run? Thx

@lock9 could you help close this issue? Seems it was resolved.

Solved


Dark mode

Is there a possibility to run the Gradio in Dark Mode.
I have tried to put "--theme dark" in the wb address but that didn't seem to do anything

You can use ?__theme=dark at the end of the URL to switch to dark mode.


Fixing memoryleak in multiclassloader context

Keeping classes keeps the classloaders forever, introducing leaks when the classloader should be collected.

I have been looking into your code and it is not quite clear to me what problem you are trying to solve.
What is the memory leak you are talking about?
The provided modifications look problematic to me. From the commit history I can see that you also provided fixes for the fixes. So the fix itself caused new problems.
It seems that the modifications make the code less clear and understandable.

Sadly I don't know a way, to dynamically create classes during Runtime - then it would be possible to write a unit-test for the leak.
The leak is a bit specific because it only happens in an environment where classloaders are created and removed - for example when plugins can be dynamically loaded/unloaded.
One Version didn't work, because it's not sufficient to make the HashMaps weak, because the Value also references the Key. Another version had a typo using the wrong HashMap.
This version now seems to work and didn't cause any issues.
If you want, I can make a new PR, with only one commit.
What does the fix do? It basically counts the subscriptions, and if it reaches zero, they are explicitly unsubscribed.

That is indeed a specific scenario - and very understandable you can't provide a unit test for this.
Generally, I am very cautious about changing code in core methods. Especially if it only covers a very specific use case.
I recently merged another PR that introduced cleaning methods for the subscriptions.
I think that this is the way to deal with such a situation. If the bus is used within a plugin environment I expect there will be some kind of hook or event that could be used to plugin a handler that cleans all empty subscriptions.
Trying to do it automatically every time a listener is subscribed adds code complexity and runtime overhead.
I think that cleanupEmptySubscriptions or just cleanup could do the trick. How about that?


update recipe and version, set to new upstream

Checklist

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

Cleans up: pep517 packaging, python version support, tests/coverage

Note I am also the "upstream" guy for this package.

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.
Here's what I've got...
For recipe:

noarch: python recipes are required to have a lower bound on the python version. Typically this means putting python >=3.6 in both host and run but you should check upstream for the package's Python compatibility.

@conda-forge-admin

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

@sarnold we just had a @conda-forge/core meeting where we discussed the case of "New Upstream." Here is what we believe is an OK-ish way to solve it. (Spoiler, yours is the most complicated one!)

Try to send the changes as a patch with a link to a PR upstream.
If upstream is non-responsive try to change the name to something that users can related, like pystache-fork, or pystache-myusername, etc.
If renaming is a no-no because it would cause a lot of churn downstream, try to get the upstream "blessing" for your fork.
If all fail we would need some evidences that upstream is not responsive or on longer interested in the project where a fork can claim to be the new source. One would be to take over the PyPI name, we would trust PyPI's judgment. Another one would be to open an issue upstream with say, 3, and come back after a certain amount of time they don't respond (probably with more data like, last PR merged, active contributions, etc).

Does that make sense?
PS: we will write that as docs soon, just polishing the details...

Oh. I forgot, there is still an issue with claiming a name. We may have the license for the code but a name may be trademarked or something, so we will have to be careful if the only option is the last one.

Still no upstream answer, and I have no idea how to go about getting pypi "blessing" to push new versions there.  Have you guys done that before?

Also I'm starting to rethink the renaming option. Would that mean only the conda package name would change?

Yep. It would be a new package with its own PyPI and conda namespace.

I'm closing this because I think it has been addressed in the intervening 3 years.


Add pmggd.bg

@MariinaKP lib/domains/bg/pmggd: this request has an incorrect file path format, please ensure that you are familiar with     this repository rules located at the bottom of this page and change     your request accordingly. If you don't know how to change request, close it and open a new one.     If you are not able to make the pull request according the instructions, please send us an email to<EMAIL_ADDRESS>Please mention this request URL in the message.

@MariinaKP Please provide us with:

the school official website URL
the school name in Bulgarian
the school street address, including city and country
a proof, which shows that the school recognizes the domain you are submitting as an official email domain for the students.

You can provide us with any of the following as the proof:

A copy of instruction (a hard-copy or electronic one) given to you by the school that tells you to use an email address in this email domain
An URL of a page at the official school website that says that students use this email domain
A reference to a recognized journal where an article was published by someone from the school, with explicit affiliation to the school, and e-mail address from the email domain
A WHOIS data that link the email domain to the school somehow
A copy of official letter from the school representative saying that the school provides e-mail addresses in this domain to the students
Anything else that can prove this fact in similar way, i.e. can be verified independently.

@philipto
School URL: https://pmggd.bg/
School name in Bulgarian: Природо-математическа гимназия „Яне Сандански“
Address: 4 Skopje Street, 2900 Center, Gotse Delchev, Bulgaria (ул. „Скопие“ 4, 2900 Център, Гоце Делчев)
School director's email<EMAIL_ADDRESS>as it can be seen on the top of the website.
Student's emails are<EMAIL_ADDRESS>(for example, mine is<EMAIL_ADDRESS>

@MariinaKP Thank you for your patience while waiting for a review and processing your request. Pull request merged. Thank you!


Keyref in topic not properly resolved taking into account key scopes

I'm attaching a sample project. It has two submaps, they both refer to a topic which refers to a key with different values in different key scopes.
If the topic is referenced like this:
<keydef keys="topic" href="topic.dita"/>
<!-- referencing the topic -->
<topicref keyref="topic"/>

its inner keyref will not be properly expanded to the correct key value.
But if the topic is referenced directly:
<!-- referencing the topic -->
<topicref href="topic.dita"/>

then things start working.
keyref_keyscope_topic.zip

Because <keydef> defaults to processing-role="resource-only", KeyrefModule fails to detect that topic.dita is used twice.

I think in order to fix this, we'd need to reread both the maps and all topics that were turned into normal processing-role during key resolution.

I replaced in both maps the keydefs with:
 <topicref keys="topic" href="topic.dita" toc="no"/>

The problem persists, the HTML5 TOC still shows the same title showing to the same topic for both places.


Request: Heat energy to M3 (for use in energy dashboard)

Did you read the instructions?

[X] I have read the README.

The request
First of all, thank you for your work!
Can you add a sensor to the integration that converts the heat energy (E1) to M3?
That way you can have the Gas equivalent for usage in the Energy dashboard.
according to the official government website https://www.infomil.nl/onderwerpen/duurzaamheid-energie/energiebesparing/vragen-antwoorden/overige-vragen/omrekening-verbruik/
1 GigaJoule = 31,6 m3
So, the formula should be  [x]GJ*31.6=m3
Thanks!
Additional information
No response

Please have a look at issue #21. However, the formula provided there is slightly different...

@tmaniac I requested this in the Month of "What the heck?!" forums
https://community.home-assistant.io/t/wth-allow-gj-gigajoule-as-a-long-term-statistic/469968
Feel free to add comments and your vote.

Support for this is now done, see https://github.com/golles/ha-kamstrup_403/releases/tag/2.0.0


[UI/UX] Implement Trial Management page

Implementation:
Provided mock-up: https://www.figma.com/proto/WzlfNehyQjLLLgqPKxncyB/Wireframing?node-id=261514%3A251&scaling=min-zoom
Match Patient/Device button will redirect the user to the Match Patient with Device form page.
Manage Patient button will redirect the user to Patient List page.
For the design part, keep in mind to apply the result of #76 task.
For the HTML part, keep in mind to follow the guidelines after the refactor for the other pages (e.g. #80, #79, #78...)
Expected result:
The page should look like in the provided mock-ups

@paiusCatalin  Where can I find the image in .png format?

Hi @elubilu,
A new image in SVG format has been added within #102.
Could you please validate that the new image has better quality also on your side?
Thank you.


Incompatible install in (summarize your environment)

Prerequisites

[x] Read Python 2 Sunset docs.
[x] Python 2 is required for this application.
[x] I maintain the software that installs Setuptools (if not, please contact that project).
[x] Setuptools installed with pip 9 or later.
[x] Pinning Setuptools to setuptools<45 in the environment was unsuccessful.

Environment Details

Operating System and version:
Python version:
Python installed how:
Virtualenv version (if using virtualenv): n/a

Command(s) that triggered the warning/error (and output):

Command(s) used to install setuptools (and output):

Output of pip --version when installing setuptools:

Other notes

Hey Robin. Sorry you've run into trouble, but there's nothing we can do without more detail.


Test fixtures for GWAS plugin

We have gotten confirmation that we will soon have new population genomics data incoming. I took this as encouragement to continue the investigation of the GWAS plugin started by @Kwentine in EB-56. Big thanks for the previous progress on this! I mostly just tweaked the config and prepared new test data.
EDIT: one week later, the data has now been made public. Findings from tests of a representative file from the dataset are presented in the next post below.

The initial commit include fixtures with BED-like data and an updated version of the EB-56 config. The result is a working Manhattan plot.
The dummy data is based on the structure of an incoming dataset I got to preview. Since that data is yet to be made public, the fixture data contains a randomized score column with a distribution based on the min-max values of the original file with some outliers sprinkled in for effect.
To test (inspired by PR37):
./scripts/dockermake --test SPECIES=gwas_testing_ground
./scripts/dockerserve --dev
cp tests/fixtures/gwas_testing_ground/gwas_randomized_dummy_data.txt.bgz* hugo/static/data
cp -r tests/data/gwas_testing_ground hugo/static/data

And then open: http://localhost:8080/genome-browser/?config=/data/gwas_testing_ground/config.json
Some observations:

First I attempted to load the plain text file using bedAdapter, but this only resulted in an empty plot, which is similar to the result Quentin previously got with the other test data.

Switched to BedTabixAdapter like in the example in the GWAS plugin repo. Realized/remembered that tabix only accepts tab-delimited data ("What's in a name?" :smile: ). Reformatted with awk '{$1=$1}1' OFS='\t' data.txt > data.tab_delim.txt. BED sort, bgzip, tabix. The data now displayed!

Despite that the official specification for the BED format states that it is whitespace-delimited, tab-delimited BEDs are commonly used and are likely the easiest way to ensure compatibility with JBrowse 2. From now on, we will ask submitting researchers to tab-delimit their BED files

BED-like files can have headers: first line need to start with # and be tab-separated. The column titles can be used to define e.g. the scoreColumn for the plot.

Take-home message: ask researchers to tab-delimit their BED files.

Some things left to consider:

Can BED-like files be used for other visualizations? Manhattan plots will not be suitable for all population genomics datasets. Histograms have already been requested.

Should the GWAS plugin be installed in the repo instead of called remotely?

Will the  bedAdapter config work with the tab-delimited data?

The FASTA has a file size of 2 Mb despite being truncated. The config can be altered to call on the remote data instead, but a refNameAlias first need to be prepared.

I put this a a draft PR for now because I anticipate that the incoming dataset might have additional data types that need to be tested.

@brinkdp First of all I must say that I am impressed by your clever workarounds, and always very clear summary.
For complex configurations, such as the Manhattan plot, I think we should directly craft config.json, partly because the add-track CLI does not allow to specify adapter options such as scoreColumn. Other track-level advanced options could be passed to add-track as a JSON string, but if we are to write JSON I reckon we might as well edit config.json directly.
That being said, the backend should still prepare the data for tracks manually added to config.json So I propose that we add an optional skipAddTrack  key to config.yaml that, when set to true, would instruct make build to generate track files as usual, but skip the add-track call.
What do you think ?

You raise good points; a skipAddTrack key in combination with manual crafting of config.json would be an easy way to proceed with this. Please go ahead with that idea!
There is indeed an elevated complexity in this config. This got me thinking about how to best transfer this knowledge to new staff members in the future, should the need arise. Some documentation or perhaps even helper scripts would be needed. I will ruminate on this.

Great, I will go ahead an implement in one or more separate branches:

skipAddTrack
header-preserving sorting of BED files
tabifying of BED files

When all these are reviewed and merged, I will help you merge back the changes in this branch.
Does that sound good ? The alternative would be for me to implement everything in this very branch,  but I fear it may mix too many concerns.

Great, sounds like a good plan!

This PR can now be closed, and worked continued on the re-based branch gwas-test-continued (#53)


Is this a real time environment a pretend/practice environment? Sorry I'm a bit out of the tech loop since I was bad to leave ITT to raise a baby.  Your honesty is appreciated!

@me-sweetNspicy try it for yourself: https://copy.sh/v86/
also recommend trying jslinux: https://bellard.org/jslinux/

I'm sorry so will this all app help me practice or will it actually make changes to my phone?

I'm trying to figure out if my phones has malfeasance or shot ease on it like my last 6 iPhone did from a jealous bf.

Alright it's a virtual machine thanks!


Is it possible to write packages in NodeJs?

Question

Hi,
Thanks for asking. No, it is not possible for the moment. I plan to implement it later, you can take a look at this issue and this card.
Let me know if you have any questions.


[Core]Add New Run:ai Streamer Load format.

Add RunAI Model Streamer Support for Efficient Model Loading
Description
This PR adds support for Run:ai Model Streamer in vLLM, enabling more efficient model loading by streaming weights directly to GPU memory. The RunAI Streamer offers significant performance improvements through:

Direct CPU to GPU streaming
Multi-threaded loading with configurable concurrency
Efficient memory management
Support for both local and S3 storage

Implementation Details

Added RunAIStreamerLoader class inheriting from BaseModelLoader
Added RUNAI_STREAMER to LoadFormat enum
Implements direct-to-GPU tensor streaming
Supports both single and sharded safetensors files
Handles HuggingFace model downloads
Configurable thread count for parallel loading
S3 integration with customizable settings

@omer-dayan , Thanks for opening up an another PR.  #10192, I am closing this. Thanks for your contribution, can't wait to try it with vllm soon.


OS: Added support for Gentoo/FreeBSD

Description
Features
The ultimate aim of this PR is to expand Neofetch's support to Gentoo/FreeBSD. Testing will have to be done in these distros (in an installed environment, not a LiveCD):

[x] FreeBSD / DragonFlyBSD
[x] OpenBSD / Bitrig / NetBSD
[ ] PacBSD
[x] Gentoo/FreeBSD (see screenshot)
[x] Solaris (OpenIndiana/Oracle)
[x] Dragora

These testings are done because we're merging the package detection for Linux/Solaris and BSD. We all want accurate results for package, don't we?
Issues

Also, see my comments in the diff.
TODO

Errors need to be suppressed.
Cleanup get_distro, I think.

It seems ASCII detection of Gentoo is a bit broken when we use distro_shorthand=off. In Getnoo FreeBSD, the PRETTY_NAME is Gentoo/BSD while on Linux it's Gentoo/Linux.

We're going to have modify the case for Gentoo.
Not on Linux right now so here's an example:
# This is in get_distro_colors()
# Just remove Gentoo from wherever it is now and add this in.
"Gentoo"*)
    set_colors X X X
    ascii_distro="gentoo"
;;

Alright. Since the problem also exist in Gentoo Linux, I'm going to push that one change to master.

So all tests are done and I'm ready to merge. I need only one more test from PacBSD.
AFAIK, PacBSD has both pacman and pkg installed, but only pacman is used. If pkg exists, I want to know if the output of pkg info | wc -l == 0. If the output is not 0, then we'll need to use if [[ "$kernel_name" == "FreeBSD" && "$distro" != "PacBSD"* ]] instead of using case.

LGTM :+1:
We can fix PacBSD once the servers are online.


Fmriprep 23.2 qsiprep 0.19

Just reviewd Erin's changes and added all of them to my repo.

I think this one is in there my mistake - we might want to reject if to avoid compromising the main branch with new versions

It's from  GhazalehManj:fmriprep-23.2_qsiprep-0.19 to TIGRLAB: fmriprep-23.2_qsiprep-0.19. So it should be fine as main branch is all good!


Pass value to formatCharacters validate

How about passing input value to validate method in formatCharacters. I think it will be convenient.
Example
<MaskedInput
  formatCharacters={{
    'w': {
      validate(char, value) {
        return value.length === 1 && char === 'w' || value.length === 2 && char === 'W';
      },
    }
  }}
/>

This example does not make sense, but this functional can be useful.

+1. This is needed, if we need to validate the expiry-date is between 0 and 12, and return empty otherwise. Without this, I'm not sure how you can achieve this feature, as this function gives single char at a time.


Admin cannot manage the register 'Register'

When an admin tries to manage a register, the application throws an error.
URL
https://managing-registers-staging.cloudapps.digital/register
Steps to reproduce

Log as admin
Click in the 'Register' link.

Actual result
Error page: We're sorry, but something went wrong.
Expected
To see the register Register records.
Note: Maybe just a data problem. It happens in staging and locally.
2017-10-27T09:08:31.33+0100 [RTR/1] OUT     2017-10-27T09:08:31.33+0100 [APP/PROC/WEB/1] OUT I, [2017-10-27T08:08:31.337083 #69]  INFO -- : [dd310a48-290c-45d9-b387-8091315ceb6f] Completed 500 Internal Server Error in 1252ms (ActiveRecord: 0.9ms)    2017-10-27T09:08:31.33+0100 [APP/PROC/WEB/1] OUT F, [2017-10-27T08:08:31.337622 #69] FATAL -- : [dd310a48-290c-45d9-b387-8091315ceb6f]       2017-10-27T09:08:31.33+0100 [APP/PROC/WEB/1] OUT F, [2017-10-27T08:08:31.337688 #69] FATAL -- : [dd310a48-290c-45d9-b387-8091315ceb6f] ArgumentError (comparison of String with nil failed):    2017-10-27T09:08:31.33+0100 [APP/PROC/WEB/1] OUT F, [2017-10-27T08:08:31.337738 #69] FATAL -- : [dd310a48-290c-45d9-b387-8091315ceb6f]       2017-10-27T09:08:31.33+0100 [APP/PROC/WEB/1] OUT F, [2017-10-27T08:08:31.337799 #69] FATAL -- : [dd310a48-290c-45d9-b387-8091315ceb6f] app/controllers/register_controller.rb:13:insort_by'
2017-10-27T09:08:31.33+0100 [APP/PROC/WEB/1] OUT [dd310a48-290c-45d9-b387-8091315ceb6f] app/controllers/register_controller.rb:13:in index'
/cc @Maidment64

@fjavierm do you know if it's a recent regression?

@arnau I haven't done any investigation, I was trying to do something else. I've raised the issue to take a look in some point

We decided users should not be able to edit the 'Register' register and it has been filtered out, so this issue can be closed.


The EETQ quantization model cannot be performed locally

System Info
hardware : 4090
PyTorch  2.1.0 Python  3.10(ubuntu22.04) Cuda  12.1
Information

[ ] Docker
[X] The CLI directly

Tasks

[X] An officially supported command
[ ] My own modifications

Reproduction
CUDA_VISIBLE_DEVICES=0 text-generation-launcher --model-id 'llama2-7b/llama2-7b-eetq' --num-shard 1 --quantize eetq
The model was quantified by the local EETQ process and saved by the 'save_pretrained()' instruction.
There should be no major problem with the dependencies on my machine, and I can feed the quantized models of gptq and awq into the TGI instruction for inference , only eetq quantized model didn't work.
Expected behavior
Error 1: cuda does not support 4-bit and 8-bit

Error 2: transformers/quantizers/auto.py did not support eetq quantization type

TGI cannot load a quantized eetq model but quantize it after loading the fp16 model. It is tough to load a quantized eetq model in TGI since the quantized weights cannot be concatenated or split owing to the cutlass preprocess. It is possible to save a model by TGI and reuse it.
You should use transformers via source code installation.

It is possible to save a model by TGI and reuse it.

@dtlzhuangz, may I ask how to do that?

It is possible to save a model by TGI and reuse it.

@dtlzhuangz, may I ask how to do that?

Sorry, we do not support loading a model in TGI. we only support loading a model in 'transformers'. (They are different since kernel fusion and tensor parallel of TGI will contribute to the quantized weight unable to be used from transformers. ).

So, is there a way to load the quantized model in TGI somehow?

@Narsil Hi, is it possible to save an EETQ model and load it in TGI?


treewide: cross-fixes

Motivation for this change
Fixes xorg and luasocket cross builds.
Perl code could be deduplicated but not sure if worth the hassle.
Fixes #51178
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Success on x86_64-linux (full log)
Attempted: luaPackages.luasocket, xorg.libX11, xorg.libXv
Partial log (click to expand)
patching script interpreter paths in /nix/store/3zym2iq3g4hc3lkpsqwpib1b0l0x7ail-libXv-1.0.11-dev
checking for references to /build/ in /nix/store/3zym2iq3g4hc3lkpsqwpib1b0l0x7ail-libXv-1.0.11-dev...
shrinking RPATHs of ELF executables and libraries in /nix/store/c2s0fb8ggirf2p238ir6529z40l133fz-libXv-1.0.11-devdoc
gzipping man pages under /nix/store/c2s0fb8ggirf2p238ir6529z40l133fz-libXv-1.0.11-devdoc/share/man/
strip is /nix/store/yldzqb0x7gmycr1z0sa8h640lyr9gl84-binutils-2.30/bin/strip
patching script interpreter paths in /nix/store/c2s0fb8ggirf2p238ir6529z40l133fz-libXv-1.0.11-devdoc
checking for references to /build/ in /nix/store/c2s0fb8ggirf2p238ir6529z40l133fz-libXv-1.0.11-devdoc...
/nix/store/9kj58cn5lm2mcjzynmc15mrvc52p3vjc-lua5.2-socket-3.0-rc1
/nix/store/h0fv5n55qw8ihw6wr851snqk9qipfr9k-libX11-1.6.7
/nix/store/pd65mb184s4cib47ksz6y38drhr2mc6i-libXv-1.0.11

Some of this can't be built on staging due to ncurses failing cross there, have built these packages on a fork successfully.

Timed out, unknown build status on x86_64-darwin (full log)
Attempted: luaPackages.luasocket, xorg.libX11, xorg.libXv
Partial log (click to expand)
cannot build derivation '/nix/store/qym2i90pv3cilb41z0w6hzz6xn2kfyfq-configd-osx-10.8.5.drv': 8 dependencies couldn't be built
cannot build derivation '/nix/store/ffwgnx8qxa3jd44arm0kmb0avpc1d82f-python-2.7.15.drv': 8 dependencies couldn't be built
cannot build derivation '/nix/store/8lic1cab790dkpbyjvn3p0j8jndysrnr-libxml2-2.9.8.drv': 3 dependencies couldn't be built
cannot build derivation '/nix/store/42ijrrsx1qlhx04y27xa55b02hkikzqr-xcb-proto-1.13.drv': 3 dependencies couldn't be built
cannot build derivation '/nix/store/0d0vi7r9pdr4qdzaaf2l5r5lk9j2aivh-libxslt-1.1.32.drv': 4 dependencies couldn't be built
cannot build derivation '/nix/store/lllr4cliw3azgylw6sgkj2jf5pbvb560-libxcb-1.13.1.drv': 8 dependencies couldn't be built
cannot build derivation '/nix/store/8q4lk09b4rsam0h3di050fjwr948pjh5-libX11-1.6.7.drv': 10 dependencies couldn't be built
cannot build derivation '/nix/store/jc7bpgxi9hij72s1zlzqh13r4ngb5y1n-libXext-1.3.3.drv': 6 dependencies couldn't be built
cannot build derivation '/nix/store/hr799mdrw4hbyfnsnaaxpf9izqcfb3k5-libXv-1.0.11.drv': 7 dependencies couldn't be built
error: build of '/nix/store/8q4lk09b4rsam0h3di050fjwr948pjh5-libX11-1.6.7.drv', '/nix/store/dm8xyzvl20lj20dsndz9rpzgg2k809av-lua5.2-socket-3.0-rc1.drv', '/nix/store/hr799mdrw4hbyfnsnaaxpf9izqcfb3k5-libXv-1.0.11.drv' failed

Success on x86_64-linux (full log)
Attempted: cups, luaPackages.luasocket, xorg.libX11, xorg.libXv
Partial log (click to expand)
/nix/store/fwblchmz7s7cx0v038z5azfxnhf5zr8c-cups-2.2.6
/nix/store/9kj58cn5lm2mcjzynmc15mrvc52p3vjc-lua5.2-socket-3.0-rc1
/nix/store/h0fv5n55qw8ihw6wr851snqk9qipfr9k-libX11-1.6.7
/nix/store/pd65mb184s4cib47ksz6y38drhr2mc6i-libXv-1.0.11

Success on aarch64-linux (full log)
Attempted: luaPackages.luasocket, xorg.libX11, xorg.libXv
Partial log (click to expand)
patching script interpreter paths in /nix/store/298gzrygg5447zd424byihqg7cib9ckn-libXv-1.0.11-dev
checking for references to /build/ in /nix/store/298gzrygg5447zd424byihqg7cib9ckn-libXv-1.0.11-dev...
shrinking RPATHs of ELF executables and libraries in /nix/store/954djph2gcrawbh39nc8kikwkakh1zdr-libXv-1.0.11-devdoc
gzipping man pages under /nix/store/954djph2gcrawbh39nc8kikwkakh1zdr-libXv-1.0.11-devdoc/share/man/
strip is /nix/store/6yjvaipy9zffribmc4l13c7i8k19ama5-binutils-2.30/bin/strip
patching script interpreter paths in /nix/store/954djph2gcrawbh39nc8kikwkakh1zdr-libXv-1.0.11-devdoc
checking for references to /build/ in /nix/store/954djph2gcrawbh39nc8kikwkakh1zdr-libXv-1.0.11-devdoc...
/nix/store/qszdyx8786yhs5r658kvar13xv2f9ljh-lua5.2-socket-3.0-rc1
/nix/store/cgq27p130fjaylgdb1gvz0ivvh4khmdg-libX11-1.6.7
/nix/store/cdmmxsdga8n1p7h6vdr78kzby2sfdmz0-libXv-1.0.11

Failure on aarch64-linux (full log)
Attempted: cups, luaPackages.luasocket, xorg.libX11, xorg.libXv
Partial log (click to expand)
gzipping man pages under /nix/store/j6w4rsi5ypka7zn114mqxpp3cshr1kqy-avahi-0.7/share/man/
strip is /nix/store/6yjvaipy9zffribmc4l13c7i8k19ama5-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/j6w4rsi5ypka7zn114mqxpp3cshr1kqy-avahi-0.7/lib  /nix/store/j6w4rsi5ypka7zn114mqxpp3cshr1kqy-avahi-0.7/bin  /nix/store/j6w4rsi5ypka7zn114mqxpp3cshr1kqy-avahi-0.7/sbin
patching script interpreter paths in /nix/store/j6w4rsi5ypka7zn114mqxpp3cshr1kqy-avahi-0.7
/nix/store/j6w4rsi5ypka7zn114mqxpp3cshr1kqy-avahi-0.7/etc/avahi/avahi-autoipd.action: interpreter directive changed from "/bin/sh" to "/nix/store/vljll3kz8qqmchp8qrvmdf332sg6in4a-bash-4.4-p23/bin/sh"
/nix/store/j6w4rsi5ypka7zn114mqxpp3cshr1kqy-avahi-0.7/etc/avahi/avahi-dnsconfd.action: interpreter directive changed from "/bin/sh" to "/nix/store/vljll3kz8qqmchp8qrvmdf332sg6in4a-bash-4.4-p23/bin/sh"
checking for references to /build/ in /nix/store/j6w4rsi5ypka7zn114mqxpp3cshr1kqy-avahi-0.7...
moving /nix/store/j6w4rsi5ypka7zn114mqxpp3cshr1kqy-avahi-0.7/sbin/* to /nix/store/j6w4rsi5ypka7zn114mqxpp3cshr1kqy-avahi-0.7/bin
cannot build derivation '/nix/store/aj4c91zkxiv9l2zci1g85fnd9p8n0xdg-cups-2.2.6.drv': 2 dependencies couldn't be built
error: build of '/nix/store/aj4c91zkxiv9l2zci1g85fnd9p8n0xdg-cups-2.2.6.drv' failed

Failure on aarch64-linux (full log)
Attempted: cups, luaPackages.luasocket, xorg.libX11, xorg.libXv
Partial log (click to expand)
stripping (with command strip and flags -S) in /nix/store/959p8w9zap0g7w2a3pl22q8wj2crk55j-libusb-1.0.22/lib
patching script interpreter paths in /nix/store/959p8w9zap0g7w2a3pl22q8wj2crk55j-libusb-1.0.22
checking for references to /build/ in /nix/store/959p8w9zap0g7w2a3pl22q8wj2crk55j-libusb-1.0.22...
shrinking RPATHs of ELF executables and libraries in /nix/store/2vyd9pim99sa9fzham188r2d25j8wz86-libusb-1.0.22-dev
strip is /nix/store/6yjvaipy9zffribmc4l13c7i8k19ama5-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/2vyd9pim99sa9fzham188r2d25j8wz86-libusb-1.0.22-dev/lib
patching script interpreter paths in /nix/store/2vyd9pim99sa9fzham188r2d25j8wz86-libusb-1.0.22-dev
checking for references to /build/ in /nix/store/2vyd9pim99sa9fzham188r2d25j8wz86-libusb-1.0.22-dev...
cannot build derivation '/nix/store/aj4c91zkxiv9l2zci1g85fnd9p8n0xdg-cups-2.2.6.drv': 2 dependencies couldn't be built
error: build of '/nix/store/aj4c91zkxiv9l2zci1g85fnd9p8n0xdg-cups-2.2.6.drv' failed

Timed out, unknown build status on x86_64-darwin (full log)
Attempted: cups, luaPackages.luasocket, xorg.libX11, xorg.libXv
Partial log (click to expand)
cannot build derivation '/nix/store/mxqx45mdh5f5i9d0f0p6sba5f9k9pmfm-apple-framework-Accelerate.drv': 4 dependencies couldn't be built
cannot build derivation '/nix/store/h3hz5c1h4g7vqg185lg8p8zh417j5jix-apple-framework-ServiceManagement.drv': 4 dependencies couldn't be built
cannot build derivation '/nix/store/25m5jpq4yjfkpvvgca2w39169341kci2-apple-framework-SystemConfiguration.drv': 4 dependencies couldn't be built
cannot build derivation '/nix/store/ps3b32yjyr12hj37y8i1s3wc95czb1mk-apple-framework-CoreGraphics.drv': 7 dependencies couldn't be built
cannot build derivation '/nix/store/myf11r2g4cad69xfbcjyj1njbx8psars-apple-framework-CoreServices.drv': 11 dependencies couldn't be built
cannot build derivation '/nix/store/41hfsa1i44d0sfxfbpd6m782qb5ci9fl-apple-framework-CoreText.drv': 4 dependencies couldn't be built
cannot build derivation '/nix/store/zyk04vi0q54jp54d2b2ar48qhv1swfxs-apple-framework-ImageIO.drv': 4 dependencies couldn't be built
cannot build derivation '/nix/store/r7f5n1zj7v63jcykgdsiiarrha8q64jp-apple-framework-ApplicationServices.drv': 6 dependencies couldn't be built
cannot build derivation '/nix/store/2a6jxgqvk73r1wimlmzlrgymsbkacd9d-cups-2.2.6.drv': 12 dependencies couldn't be built
error: build of '/nix/store/2a6jxgqvk73r1wimlmzlrgymsbkacd9d-cups-2.2.6.drv', '/nix/store/8q4lk09b4rsam0h3di050fjwr948pjh5-libX11-1.6.7.drv', '/nix/store/dm8xyzvl20lj20dsndz9rpzgg2k809av-lua5.2-socket-3.0-rc1.drv', '/nix/store/hr799mdrw4hbyfnsnaaxpf9izqcfb3k5-libXv-1.0.11.drv' failed

Success on x86_64-linux (full log)
Attempted: cups, luaPackages.luasocket, ssmtp, xorg.libX11, xorg.libXv
Partial log (click to expand)
post-installation fixup
moving /nix/store/7ggl1kh9mydsf3wl321cbvjckyyh4qzx-ssmtp-2.64/man to /nix/store/7ggl1kh9mydsf3wl321cbvjckyyh4qzx-ssmtp-2.64/share/man
shrinking RPATHs of ELF executables and libraries in /nix/store/7ggl1kh9mydsf3wl321cbvjckyyh4qzx-ssmtp-2.64
shrinking /nix/store/7ggl1kh9mydsf3wl321cbvjckyyh4qzx-ssmtp-2.64/sbin/ssmtp
gzipping man pages under /nix/store/7ggl1kh9mydsf3wl321cbvjckyyh4qzx-ssmtp-2.64/share/man/
strip is /nix/store/yldzqb0x7gmycr1z0sa8h640lyr9gl84-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/7ggl1kh9mydsf3wl321cbvjckyyh4qzx-ssmtp-2.64/libexec  /nix/store/7ggl1kh9mydsf3wl321cbvjckyyh4qzx-ssmtp-2.64/sbin
patching script interpreter paths in /nix/store/7ggl1kh9mydsf3wl321cbvjckyyh4qzx-ssmtp-2.64
checking for references to /build/ in /nix/store/7ggl1kh9mydsf3wl321cbvjckyyh4qzx-ssmtp-2.64...
moving /nix/store/7ggl1kh9mydsf3wl321cbvjckyyh4qzx-ssmtp-2.64/sbin/* to /nix/store/7ggl1kh9mydsf3wl321cbvjckyyh4qzx-ssmtp-2.64/bin

Failure on aarch64-linux (full log)
Attempted: cups, luaPackages.luasocket, ssmtp, xorg.libX11, xorg.libXv
Partial log (click to expand)
Total Test time (real) =  11.22 sec

The following tests FAILED:
         45 - djpeg-shared-rgb-islow-icc-cmp (Failed)
Errors while running CTest
make: *** [Makefile:130: test] Error 8
builder for '/nix/store/mkkjxd7x4c001qxz8484hhawgrqmmpkh-libjpeg-turbo-2.0.1.drv' failed with exit code 2
cannot build derivation '/nix/store/pjrd3pqrprqylcf5gpgpz5i15y3bzd2g-libtiff-unstable-2018-11-04.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/aj4c91zkxiv9l2zci1g85fnd9p8n0xdg-cups-2.2.6.drv': 2 dependencies couldn't be built
error: build of '/nix/store/aj4c91zkxiv9l2zci1g85fnd9p8n0xdg-cups-2.2.6.drv' failed

Timed out, unknown build status on x86_64-darwin (full log)
Attempted: cups, luaPackages.luasocket, xorg.libX11, xorg.libXv
Partial log (click to expand)
cannot build derivation '/nix/store/mxqx45mdh5f5i9d0f0p6sba5f9k9pmfm-apple-framework-Accelerate.drv': 4 dependencies couldn't be built
cannot build derivation '/nix/store/h3hz5c1h4g7vqg185lg8p8zh417j5jix-apple-framework-ServiceManagement.drv': 4 dependencies couldn't be built
cannot build derivation '/nix/store/25m5jpq4yjfkpvvgca2w39169341kci2-apple-framework-SystemConfiguration.drv': 4 dependencies couldn't be built
cannot build derivation '/nix/store/ps3b32yjyr12hj37y8i1s3wc95czb1mk-apple-framework-CoreGraphics.drv': 7 dependencies couldn't be built
cannot build derivation '/nix/store/myf11r2g4cad69xfbcjyj1njbx8psars-apple-framework-CoreServices.drv': 11 dependencies couldn't be built
cannot build derivation '/nix/store/41hfsa1i44d0sfxfbpd6m782qb5ci9fl-apple-framework-CoreText.drv': 4 dependencies couldn't be built
cannot build derivation '/nix/store/zyk04vi0q54jp54d2b2ar48qhv1swfxs-apple-framework-ImageIO.drv': 4 dependencies couldn't be built
cannot build derivation '/nix/store/r7f5n1zj7v63jcykgdsiiarrha8q64jp-apple-framework-ApplicationServices.drv': 6 dependencies couldn't be built
cannot build derivation '/nix/store/2a6jxgqvk73r1wimlmzlrgymsbkacd9d-cups-2.2.6.drv': 12 dependencies couldn't be built
error: build of '/nix/store/2a6jxgqvk73r1wimlmzlrgymsbkacd9d-cups-2.2.6.drv', '/nix/store/8q4lk09b4rsam0h3di050fjwr948pjh5-libX11-1.6.7.drv', '/nix/store/dm8xyzvl20lj20dsndz9rpzgg2k809av-lua5.2-socket-3.0-rc1.drv', '/nix/store/hr799mdrw4hbyfnsnaaxpf9izqcfb3k5-libXv-1.0.11.drv' failed

Timed out, unknown build status on x86_64-darwin (full log)
Attempted: cups, luaPackages.luasocket, xorg.libX11, xorg.libXv
The following builds were skipped because they don't evaluate on x86_64-darwin: ssmtp
Partial log (click to expand)
cannot build derivation '/nix/store/mxqx45mdh5f5i9d0f0p6sba5f9k9pmfm-apple-framework-Accelerate.drv': 4 dependencies couldn't be built
cannot build derivation '/nix/store/h3hz5c1h4g7vqg185lg8p8zh417j5jix-apple-framework-ServiceManagement.drv': 4 dependencies couldn't be built
cannot build derivation '/nix/store/25m5jpq4yjfkpvvgca2w39169341kci2-apple-framework-SystemConfiguration.drv': 4 dependencies couldn't be built
cannot build derivation '/nix/store/ps3b32yjyr12hj37y8i1s3wc95czb1mk-apple-framework-CoreGraphics.drv': 7 dependencies couldn't be built
cannot build derivation '/nix/store/myf11r2g4cad69xfbcjyj1njbx8psars-apple-framework-CoreServices.drv': 11 dependencies couldn't be built
cannot build derivation '/nix/store/41hfsa1i44d0sfxfbpd6m782qb5ci9fl-apple-framework-CoreText.drv': 4 dependencies couldn't be built
cannot build derivation '/nix/store/zyk04vi0q54jp54d2b2ar48qhv1swfxs-apple-framework-ImageIO.drv': 4 dependencies couldn't be built
cannot build derivation '/nix/store/r7f5n1zj7v63jcykgdsiiarrha8q64jp-apple-framework-ApplicationServices.drv': 6 dependencies couldn't be built
cannot build derivation '/nix/store/2a6jxgqvk73r1wimlmzlrgymsbkacd9d-cups-2.2.6.drv': 12 dependencies couldn't be built
error: build of '/nix/store/2a6jxgqvk73r1wimlmzlrgymsbkacd9d-cups-2.2.6.drv', '/nix/store/8q4lk09b4rsam0h3di050fjwr948pjh5-libX11-1.6.7.drv', '/nix/store/dm8xyzvl20lj20dsndz9rpzgg2k809av-lua5.2-socket-3.0-rc1.drv', '/nix/store/hr799mdrw4hbyfnsnaaxpf9izqcfb3k5-libXv-1.0.11.drv' failed


chore: Remove out-of-date EPL licenses on some files

What does this PR do?
Update license headers on a few files to Apache 2.0 from EPL. It appears some files were missed in https://github.com/devfile/devworkspace-operator/pull/496
What issues does this PR fix or reference?
N/A
Is it tested? How?

PR Checklist

[ ] E2E tests pass (when PR is ready, comment /test v8-devworkspace-operator-e2e, v8-che-happy-path to trigger)

[ ] v8-devworkspace-operator-e2e: DevWorkspace e2e test
[ ] v8-che-happy-path: Happy path for verification integration with Che

/test v8-devworkspace-operator-e2e

probably commit message should be updated in order to pass the semantic PR check

I really don't want to litter our commit history with semantic PR requirements. I'm fine putting descriptors in PR titles but since we don't squash PRs in this repo it doesn't make sense to use semantic commits (many of the commits don't fall neatly into a category).


WinUI Win32 app opens and closes in taskbar before opening

Describe the bug
A WinUI Win32 app pops up in the taskbar before disappearing, before reappearing and finally opening. See the animation below.
Steps to reproduce the bug

Steps to reproduce the behavior:

Open a WinUI Win32 app (through Start, search, or desktop icon—doesn’t seem to matter)
Observe taskbar (slightly different behavior that is also wrong if pinned to taskbar)

Expected behavior
The icon should appear on the taskbar once and stay open.
Screenshots

Version Info

NuGet package version:
Microsoft.WinUI 3.0.0-preview1.200515.3

Windows 10 version
Saw the problem?

Insider Build (xxxxx)

November 2019 Update (18363)
Yes

May 2019 Update (18362)

October 2018 Update (17763)

April 2018 Update (17134)

Fall Creators Update (16299)

Creators Update (15063)

Device form factor
Saw the problem?

Desktop
Yes

Mobile

Xbox

Surface Hub

IoT

Additional context
Some Win32 apps (notably, I believe Google Chrome) also occasionally exhibit something similar to this behavior.

@MikeHillberg @Austin-Lamb Any ideas what might be happening here and where this issue needs to be routed ?

This looks like it's fixed in the latest preview version.  Let me know if that's not the case.

This looks like it's fixed in the latest preview version.  Let me know if that's not the case.