Store workflow state

After working with Effektif for a while now we're pretty happy, except for one big thing, and that is figuring out in Mongo in what activityId a workflowInstance is.
To find out in what open activityId an instance is, the following query is needed:
workflowInstances.find({"activityInstances" : { $elemMatch : { activityId : "xxx", end : { $exists : true }}}}, { "activityInstances.$" : 1 })

But when doing aggregations (reporting) or trying to find out in what activityId a workflowInstance is when the flow is ended (you'll have to look at the last entry of the activityInstances array, again a problem in the aggregation framework) is a pain in the (...)
So my proposal is to introduce an array on the top level in workflowInstances containing the current (=last) states a workflowInstance is in (an array because when using a parallel gateway one workflowInstance can actually have 2 or more states it is in)
For example, the json of this array would look like this:
    "currentActivityIds" : [
        {
            "activityId" : "WaitingForUserInput"
        },
        {
            "activityId" : "timedOut"
        }
    ],

if the workflowInstance is in two activityId states.
Querying would become easy:
workflowInstances.find({ "currentActivityIds.activityId" : "xxx"})

The activityInstances array would still exist, but more as history.
Any comments or other (better) ideas are welcome.

Looks like a reasonable request to me.  Might become useful for ourselves at some point as well.
I'ld use a list of strings for the activityIds: { "WaitingForUserInput", "timedOut" }  Then you can also do the same query with the $in operator.

Great, we have that code running already for some time, see #38 for the pull request.

It seems even possible to query the array like this :
workflowInstances.find({ currentActivities : "timedOut" })

if you are only looking for one currentActivity. Nice

You show the right way to do it.  Actually my $in suggestion is is wrong.  $in is only to be used if you want to match the value in the mongo json document with many possible options.

Okay - I guess I need to figure out the tricky query that it replaces
The the commit - jblankendaal/effektif@fe37b0e - I’m not sure about the implications of WorkflowInstanceImpl.currentActivityIds having type Set
i.e. a set of the instances instead of a set of their IDs
I wonder how that serialises
Also, I don't have a warm fuzzy feeling about introducing a new field into the model with no documentation
tombaeyens 10:05
ok. i ll look into it
it should serialize to a set of object ids
that s the main part

I guess a summary of the discussion at effektif/effektif#36 belongs as a documentation comment on the new field

I ll have a look and fix if necessary so that we get a list of strings as the currentActivityIds

It actually returns a list of strings, the json representation is for example:
"currentActivities" : [  "WaitingForUserInput", "timedOut" ]

Hope that helps.
Also, if I can contribute documenting it better, just let me know the format you want it documented in.

@jblankendaal I renamed to openActivityIds and changed the impl a bit.  let me know if this poses a problem for you

@tombaeyens The rename is a good idea, I was actually looking for a better name but couldn't come up with one...
You also changed the location in the code where the activityId was removed from the openActivityIds list. This does pose a problem for us with a parallel gateway, since the workflowInstance that is waiting to be joined has its end date already filled in, so does not show up in openActivityIds, but we do need it to show up.
Two possible solutions as far as I am concerned:

If a workflowInstance gets state "joining" the end date should not be set, Arguably the best solution because technically it is not finished there
Move the remove from openActivityIds back to the location were I had it, but then the name openActivityIds does not make sense anymore :-)
There is actually a 3) and that is that you don't care and leave it where you have it because thats the way you need it in your product.
A workflow example is here, notice the numbers next to the activities, especially the one next to the merging parallel gateway (waiting to be joined with a workflowInstance that is in the UserTask).

I'm open to model it in different ways but currently the auto-firing of depends on the activity instances being closed.
Take the next  process with 3 simple activities in parallel.  The middle one could arrive at the end event in which only 2 joining activity instances will be created.  In that case the second one has to know it is the last one even when there are 3 incoming transitions.  This is handled by checking 'Is there more work to be done?'.  Which is implemented as 'Are there still open activity instances?'

I may have a solution by taking the joining into account when deciding to auto-fire a joining parallel gateway.  Investigating...

Conclusion: might be possible to get it done somehow, but it takes more time then i can currently spend on it.  The path to explore further is this: 1) change the ParallelGatewayImpl as indicated below.  This means only setting the state to joining when an activity instance arrives.  And ending the otherJoiningActivityInstances when the joining parallel gateway fires.  Also the check for hasOtherUnfinishedActivities needs to be adjusted accordingly.
Other places that will be impacted:

ScopeInstanceImpl.hasOpenActivityInstances()
ScopeInstanceImpl.activityInstanceEnded
Tests that express the expected open activity instances need to be changed and the joining gateways need to be added.

Changed ParallelGatewayImpl:
  @Override
  public void execute(ActivityInstanceImpl activityInstance) {
    activityInstance.setJoining();
    boolean hasOtherUnfinishedActivities = false;

    List<ActivityInstanceImpl> otherJoiningActivityInstances = new ArrayList<>();
    for (ActivityInstanceImpl siblingActivityInstance: activityInstance.parent.activityInstances) {
      if (!siblingActivityInstance.isEnded()
          && !siblingActivityInstance.isJoining()) {
        hasOtherUnfinishedActivities = true;
      }

      if ( siblingActivityInstance!=activityInstance
           && siblingActivityInstance.getActivity()==activityInstance.getActivity()
           && siblingActivityInstance.isJoining() ) {
        otherJoiningActivityInstances.add(siblingActivityInstance);
      }
    }

    if ( !hasOutgoingTransitions ) {
      activityInstance.end();
      activityInstance.propagateToParent();

    } else if ( otherJoiningActivityInstances.size()==(nbrOfIncomingTransitions-1)
                || !hasOtherUnfinishedActivities
              ) {
      if (log.isDebugEnabled()) log.debug("Firing parallel gateway");
      for (ActivityInstanceImpl otherJoiningActivityInstance: otherJoiningActivityInstances) {
        otherJoiningActivityInstance.end();
        activityInstance.removeJoining(otherJoiningActivityInstance);
      }
      activityInstance.onwards();
    }
  }

btw, I don't have anything to say about your requirements, but still i'm going to do it :)  I think your users may not be as interested as you think in the number of open joining parallel gateways.  They are typically only interested in the number of real activities that are open.  So consider if not solving this is a good resolution for this issue for you.

To close the issue: I solved it in a custom class in our project implementing WorkflowExecutionListener. The transition method is the only method implemented and looks like this:

    @Override
    public boolean transitioning(ActivityInstanceImpl activityInstance, TransitionImpl transition, ActivityInstanceImpl activityInstance1) {
        List<String> lastActivityIds = (List<String>) activityInstance.workflowInstance.getProperty(CpFields.LastActivityIds);

        if (lastActivityIds == null) {
            lastActivityIds = new ArrayList<>();
            activityInstance.workflowInstance.setProperty(CpFields.LastActivityIds, lastActivityIds);
        }

        lastActivityIds.remove(activityInstance.getActivity().getId());

        if (activityInstance1 != null && !lastActivityIds.contains(activityInstance1.getActivity().getId()))
            lastActivityIds.add(activityInstance1.getActivity().getId());

        activityInstance.workflowInstance.setProperty(CpFields.LastActivityIds, lastActivityIds);

        return true;
    }


az webapp up - with F0 - when F0 is already taken - improve error text

az feedback auto-generates most of the information requested below, as of CLI version 2.0.62

Describe the bug
If I create a webapp, az webapp up --sku F1 --name XYZ when for whatever reason the F1 is already take or not allowed, I get an  unauthorized error instead of something that tells me I need to pick a different SKU.
To Reproduce
On internal subscription, when  F1 isn't allowed or already taken, create resource with command. Get error shown in image.
Expected behavior
Error indicates pricing sku as issue.
Environment summary

Additional context

route to CXP team

@yonzhan - are you asking me to do that or you are doing that?

webapp related CLI commands are owned by service team, so I added CXP team to help with.

Since @StrawnSC from the webapp CLI team is owning this, I am removing the CXP Attention label from this and adding Service attention label.

@diberry thanks for reporting this. Could you rerun the failing command with --debug and share the output? Be sure to obfuscate any nonpublic info or feel free to DM me a screenshot on teams/email

Based on our email exchange, it seems like this issue was fixed in a recent release. Please reopen if you're still running into this bug


Housecleaning

Updated:

Streamlined code to tidy up format functions and convert to python3 format strings, compressed code and made it more efficient.
Standardised where possible all messages use " instead of '  to make life easier.
Also flipped the config file to an example and added it to .gitignore, so we don't commit secrets in testing to git :)

Shall work on changes, will see if easier to implement into class implementation too

Fixed changes as requested, will work on class re-work once these changes are committed :)


Test build unexpected exit for test failure

Latest openjdk9 test build failed for unexpected exit when there is test failure
https://ci.adoptopenjdk.net/view/OpenJDK tests/job/openjdk9_j9_openjdktest_x86-64_linux
https://ci.adoptopenjdk.net/view/OpenJDK tests/job/openjdk9_hs_openjdktest_x86-64_linux/

java.io.IOException: No space left on device
14:58:35 	at java.base/sun.nio.ch.FileDispatcherImpl.allocate0(Native Method)
14:58:35 	at java.base/sun.nio.ch.FileDispatcherImpl.allocate(FileDispatcherImpl.java:80)
14:58:35 	at java.base/sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:918)
14:58:35 	at Size.testLargeFile(Size.java:73)
14:58:35 	at Size.main(Size.java:45)
14:58:35 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
14:58:35 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
14:58:35 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
14:58:35 	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
14:58:35 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115)
14:58:35 	at java.base/java.lang.Thread.run(Thread.java:844)
14:58:35
14:58:35 JavaTest Message: Test threw exception: java.io.IOException: No space left on device
14:58:35 JavaTest Message: shutting down test

Happened to MAC test-macincloud-macos1010-2
https://ci.adoptopenjdk.net/view/OpenJDK tests/job/openjdk8_hs_openjdktest_x86-64_macos/42/consoleFull
https://ci.adoptopenjdk.net/view/OpenJDK tests/job/openjdk10_hs_openjdktest_x86-64_macos/4/consoleFull

Some of them don't have message "No space left on device"
All have message "Error: Some tests failed or other problems occurred"
We do have build on same day with test failures, which do not exit unexpected.

https://ci.adoptopenjdk.net/view/OpenJDK tests/job/openjdk8_hs_openjdktest_x86-64_macos/44/consoleFull
Seems it only happened on MAC. And only happened when jdk_nio sub group got failure either as "Error: Some tests failed or other problems occurred." or as "Unexpected exit from test [exit code: 143]"

The failure started two weeks ago, seems related with PR :Update the count mechanism for testKitGen @renfeiw

I have a PR: https://github.com/eclipse/openj9/pull/1443 to replace the error prone echo -e. Hope the PR will resolve this issue.

We should have now picked up fix openj9/#1443, so should confirm if this problem is resolved, and if issue can be closed.

I can confirm that builds from Mar 16 do not have  line " -e " with the openj9/#1443. However this is a intermittent failure with unexpected exit will run a few other personal build and see if it goes way.

I've not seen this issue recur, will close now.


MNT: rerender

Hi! This is the friendly automated conda-forge-webservice.
I've started rerendering the recipe as instructed in #16.
If I find any needed changes to the recipe, I'll push them to this PR shortly. Thank you for waiting!
Here's a checklist to do before merging.

[ ] Bump the build number if needed.

@carterbox what startegy would you like to go? would you like to usb libavif16.dll. This seems like the "better way" but i personally don't think i have too much time for this.

The original intention was for unix to run_export libavif16 and Windows to run_export libavif because Windows doesn't support versioned libraries AFAIK.

Thank you.


Scatter Plots.

In future releases, we can try to add scatter plots as a new from of visualization.

This is typically what I've seen to represent bimodality (figure B).

Also below

The microbiome package offers an example of performing bimodality analysis at https://microbiome.github.io/microbiome/Bimodality.html.
@xiaoumc @grabear

I concur, and the microbiome package was one of the first things I came across when we first discussed bimodality.


Remove unused modules

Hi @AlexKurek, currently I am on vacation,  in any case, PR can happens only once pipelines pass. I will reject this MR, if you plan a new PR in the future, please notify me in advance about the scope.
Cheers and Thanks
Andrea

I can do the same PR when you have more time, if you consider it valuable for the code.

Dear @AlexKurek, yes, I have to remove some unused import, but I also plan a slight refactoring, so, to avoid conflict I will reopen the PR once before working on the refactoring.
Thanks
Andrea


Uninstall - HowTo?

How would I completely uninstall PythonMiniProbe from a Linux system?

You just need to remove the folder of the probe and disable the startup of the init-script.

rm -R /etc/PythonMiniProbe
rm /etc/init.d/prtgprobe
update-rc.d -f prtgprobe remove

Will do, thanks!

@c-eller @konstantinpae It would make sense to include this section into the readme.


fix: reduce buttons padding to 14px

Issue: when embedded form is viewed under Safari it divides button into 2 lines.

Solution: reduce the default padding from 16px to 14px so that they fit into one line.

Follow-up to #169

Works great :)


Don’t export as email message, and be less strict about import requirements

Fixes #158
Fixes #253
Android intent filters are really only designed to work with standard mimetypes (like ‘image/png’). Even if you can share something with a custom mime type, it’s likely to get lost somewhere along the way, from email, or Gdrive, or Files app etc.
Path matching patterns in intent filter only apply to file schemes, content scheme is likely to be some generated id in temp storage. content filters maintly go by mimetype, but as noted above, a custom mimetype has often gone AWOL. Generic application files are usually downloaded as application/octet-stream. Basically we have to trust the user not to try to load some other random file into ScratchJr. The import function will fail and give an error message if they do.
Finally, fix the way we’re sharing ScratchJr files. While the button says ‘Share by Email’ for a long time Android has shown a selection of ways to share the file. However, we were setting the mime type as an email message so the saved file would always try to open in an email client instead of ScratchJr.
Most useful SO post about intent filters: https://stackoverflow.com/questions/1733195/android-intent-filter-for-a-particular-file-extension
Basically go look at the Android Source: https://android.googlesource.com/platform/frameworks/base.git/, and then browse to core/java/android/content/IntentFilter.java
Things I'm not fixing in this release:

Share button says 'Share by Email', this has not been true for many releases of Android
blue ribbon on imported projects is not responsive to the size of the thumbnail and is slightly too big on small devices.

Testing:
Create a project in ScratchJr and export it, common steps:

tap the yellow tab in the upper right
click the parents button
click share by email (yes this still says share by email, no one is available to redesign the button)

Export to email:

select gmail in the list of apps that appears when you click the share button
email should have the name of the file as subject, some introductory text in the body, and the project.sjr file as an attachment

Export to file (GDrive and files):

select Google drive or files app
filename should be project.sjr (if it doesn't have .sjr extension, please rename when saving for the next part)

Import from email (how this works seems to depend a bit on what version of android you have)

Tap on attachment in email
If ScratchJr opens, it should have the project in the lobby with a blue bow (Note if you already have ScratchJr open, you will need to manually go back to the lobby)
If it says that you don't have anything to open that type of file, download the file and try opening it from the downloads folder

Import from Gdrive:

Click on file in drive, if prompted to select the app to open the file choose ScratchJr.
ScratchJr should open with the project in the lobby with a blue bow (again it will not go back to the lobby if it's already open)

Import from files(downloads):

Click on the file in the files app, if prompted select ScratchJr as the app to open the file
project is added to the lobby with a blue bow

Things you should not see:

when clicking on a file the options for opening it are email apps (e.g. gmail etc), and do not include general file apps or ScratchJr

I was able to open it, with a blue bow, using all 3 methods. Looks good to me!


Changed throw to revert() per Solidity 0.4.13

https://github.com/ethereum/solidity/releases/tag/v0.4.13

Thanks! This should really be require(...) for a proper update, though.


Add genotype to phenopacket

Consider

VMC
HGVS
VCF like
combination of abov e

Beacon or MME implementation:
We already have this:
https://github.com/phenopackets/phenopacket-reference-implementation/blob/master/src/main/java/org/phenopackets/api/model/entity/Variant.java


Fixes for slotController

Description
When using partial template, and displaying it in different location in the DOM, according to mobile/desktop - slots that are moved into shadow DOM, disappear from the display.
Fixes # (issue)
Instead of moving slots into Shadow DOM, cloning them works much better.

The original slot stays in the lightDOM (it never gets displayed)
shadowSlotLocation consist the original link ("reveal" when inspecting elements), that usually display the slot in the correct location.

This PR:

Clones the slotted content into the right location (before shadowSlotLocation)
Removes shadowSlotLocation so the original link of light DOM content is no longer there.
Each slot type has to be cloned in a special way:

named-slot
default-slot--content
default-slot--element

Breaking changes:
To style a specific cloned slot, write in CSS:
div[cloned-slot-name='background-image'] {
  height: 100%;
}

Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

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

[ ] Test A
[ ] Test B

Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules

Tests need updating.

Done 🎉


Escape Single Quotes in WHERE clauses

Where clauses with ' are not escaped, causing 400 bad requests (in the best case) for the likeOperator.
The following code outputs: SELECT Name FROM Account WHERE Name LIKE '%Blips 'n' Chitz%'
I would expect it to be: SELECT Name FROM Account WHERE Name LIKE '%Blips \'n\' Chitz%'
package main

import (
	"github.com/forcedotcom/go-soql"
	"log"
)

type Account struct {
	Name string `soql:"selectColumn,fieldName=Name" json:"Name"`
}

type AccountQueryCriteria struct {
	AccountName []string `soql:"likeOperator,fieldName=Name"`
}

type AccountSoqlQuery struct {
	SelectClause Account              `soql:"selectClause,tableName=Account"`
	WhereClause  AccountQueryCriteria `soql:"whereClause"`
}

func main() {
	soqlStruct := AccountSoqlQuery{
		SelectClause: Account{},
		WhereClause: AccountQueryCriteria{
			AccountName: []string{"Blips 'n' Chitz"},
		},
	}

	soqlQuery, err := soql.Marshal(soqlStruct)
	if err != nil {
		log.Fatal(err)
	}

	log.Println(soqlQuery)
}

Thanks for filing the issue. I will schedule this to be done over next couple of weeks. Sorry for the delay in response.


Many operations don't support uint64

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): No
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Mac OS 10.14.2
TensorFlow installed from (source or binary): binary
TensorFlow version (use command below): b'unknown' 1.13.0-rc1
Python version: Python 3.7.2
Bazel version (if compiling from source): N/A
GCC/Compiler version (if compiling from source): N/A
CUDA/cuDNN version: N/A
GPU model and memory: N/A

Describe the current behavior
I've encountered several operations that support int64 but not uint64, without any clear reasoning. tf.equal, tf.fill, tf.where, and tf.stack, for example, give errors like:
InvalidArgumentError (see above for traceback): No OpKernel was registered to support Op 'Pack' used by node stack (defined at <stdin>:4) with these attrs: [T=DT_UINT64, axis=0, N=2]

Describe the expected behavior
Functions that work for int64s should also work for uint64s when the behavior would be the same.
Code to reproduce the issue
https://gist.github.com/hjfreyer/31ab2dd2d85d1a509272af1c5e011dde
Other info / logs
Include any logs or source code that would be helpful to diagnose the problem. If including tracebacks, please include the full traceback. Large logs and files should be attached.

@hjfreyer Most of the operations in TF does not support uint64. There are some historical and reality reasons as far as I know. One is the binary size which could be really big if all signed and unsigned int (8/16/32/64) are enabled. Also, some integer types does not work on GPU for certain math operations yet.
By default, int8, uint8, int16, uint16, int32, int64 are supported for most of the ops. uint32 and uint64 are supported for bitwise ops additionally. There are also some ops that are merely memory/type manipulation (like cast) so uint32 and uint64 are supported as well.
From the list you provide, tf.equal, tf.fill, tf.where, and tf.stack, my guess is that they will not be supported, unless uint32 and uint64 are added to the default list and applies to almost all other ops.
This might take some time and might need guidance from api team I believe.

(For API owners) We can take a look when there is a specific proposal to review.

@hjfreyer Most of the operations in TF does not support uint64. There are some historical and reality reasons as far as I know. One is the binary size which could be really big if all signed and unsigned int (8/16/32/64) are enabled. Also, some integer types does not work on GPU for certain math operations yet.
By default, int8, uint8, int16, uint16, int32, int64 are supported for most of the ops. uint32 and uint64 are supported for bitwise ops additionally. There are also some ops that are merely memory/type manipulation (like cast) so uint32 and uint64 are supported as well.
From the list you provide, tf.equal, tf.fill, tf.where, and tf.stack, my guess is that they will not be supported, unless uint32 and uint64 are added to the default list and applies to almost all other ops.
This might take some time and might need guidance from api team I believe.

@yongtang is there some definitive list what is to be supported, or what shouldn't?
e.g. I just stumbled over the fact that for dtype tf.uint16 operator == is not implemented … something I would file as a bug, however if it is wontfix, then this should be documented somewhere …
I just took a look at more combinations:
import tensorflow as tf
from tensorflow.python.framework.errors_impl import NotFoundError

dtypes = set([dtype for dtype in tf.dtypes.__dict__.values() if isinstance(dtype, tf.dtypes.DType)]) - {tf.resource, tf.variant}

for dtype in dtypes:
    a = tf.zeros(1, dtype=dtype)
    try:
        print(dtype, a == a)
    except NotFoundError:
        print(dtype, 'operator == not implemented')

> TF_CPP_MIN_LOG_LEVEL=3 python test.py
<dtype: 'float32'> tf.Tensor([ True], shape=(1,), dtype=bool)
<dtype: 'float64'> tf.Tensor([ True], shape=(1,), dtype=bool)
<dtype: 'int32'> tf.Tensor([ True], shape=(1,), dtype=bool)
<dtype: 'uint8'> tf.Tensor([ True], shape=(1,), dtype=bool)
<dtype: 'int16'> tf.Tensor([ True], shape=(1,), dtype=bool)
<dtype: 'int8'> tf.Tensor([ True], shape=(1,), dtype=bool)
<dtype: 'string'> tf.Tensor([ True], shape=(1,), dtype=bool)
<dtype: 'complex64'> tf.Tensor([ True], shape=(1,), dtype=bool)
<dtype: 'int64'> tf.Tensor([ True], shape=(1,), dtype=bool)
<dtype: 'bool'> tf.Tensor([ True], shape=(1,), dtype=bool)
<dtype: 'qint8'> tf.Tensor([ True], shape=(1,), dtype=bool)
<dtype: 'quint8'> tf.Tensor([ True], shape=(1,), dtype=bool)
<dtype: 'qint32'> tf.Tensor([ True], shape=(1,), dtype=bool)
<dtype: 'bfloat16'> tf.Tensor([ True], shape=(1,), dtype=bool)
<dtype: 'qint16'> operator == not implemented
<dtype: 'quint16'> operator == not implemented
<dtype: 'uint16'> operator == not implemented
<dtype: 'complex128'> tf.Tensor([ True], shape=(1,), dtype=bool)
<dtype: 'float16'> tf.Tensor([ True], shape=(1,), dtype=bool)
<dtype: 'uint32'> operator == not implemented
<dtype: 'uint64'> operator == not implemented

So qint16, quint16, uint16, uint32, uint64 don't even have an equality operator implemented … that makes those datatypes very rudimentary.

@csachs I added a PR #38288 for uint16, uint32, and uint64 for tf.math.equal and tf.math.not_equal.

@hjfreyer
I am not seeing any issue with TF version ,1.15,2.x.Please, find the gist here.Please,verify once and close the issue.Thanks!

@ravikyram
The problems raised in my comment remain open.
Furthermore, there seems a regression, in earlier versions:
tf.zeros(1, tf.qint16) worked, now it doesn't.
Should I open another issue?

@csachs The tf.zeros issue is being addressed in PR #41421 (tf.zeros uses FillOp implicitly).

@csachs
The tf.zeros issue is being addressed in PR #41421 also got merged. Can you please verify once.Thanks!

Added a PR #41795 to cover qint8/quint8/qint16/quint16 for tf.math.[equal|not_equal].

@csachs
The tf.zeros issue is being addressed in PR #41421 also got merged. Can you please verify once.Thanks!

Thank you @ravikyram , using version 2.4.0-dev20200728 , the tf.zeros issue is fixed.
However the larger code snippet above does not run (producing a new error); I guess it will resolve with https://github.com/tensorflow/tensorflow/pull/41795 .

Most of the dtypes in https://github.com/tensorflow/tensorflow/issues/26069#issuecomment-604608722 are already supported now except for tf.qint32 (with tf.zeros). Added a PR #46313 to add tf.qint32 for tf.zeros.

Most of the dtypes in https://github.com/tensorflow/tensorflow/issues/26069#issuecomment-604608722 are already supported now except for tf.qint32 (with tf.zeros). Added a PR #46313 to add tf.qint32 for tf.zeros.

The support of tf.qint16 and tf.quint16 for tf.stack is being added in #46404

The support of tf.qint16 and tf.quint16 for tf.stack is being added in #46404

@hjfreyer,
With @yongtang's PRs, many operations support uint64 now (Tensorflow Version 2.4.1). Please find the Gist of the Working Code. Thanks!


can not select kernel in jupyter notebook when ssh to WSL

版本: 1.77.0-insider (user setup)
提交: b9226e1ccc11625bcb42b55efb795e07ee533bb0
日期: 2023-03-24T18:57:27.096Z
Electron: 19.1.11
Chromium: 102.0.5005.196
Node.js: 16.14.2
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.22621
沙盒化: Yes
Steps to Reproduce:

SSH to WSL
open an .ipynb file
click the "select kernel"
can not display any option for long time

Sorry you are running into this issue, please could you share the following logs
Please could you enable logging as follows:

Open settings & go into Jupyter->Logging
Change the value to verbose
Reload VS Code,
Attempt to repro the issue & then copy the output from the Jupyter output panel.

Closing this issue as its been over 4 weeks, since the information was requested.
We'll be happy to reopen the issue when the requested information has been provided.


Dark scales of grey becomes greenish after conversion

Hello !
We've got an issue where converting dark images yields aberrant colors that did not exist in the input (but not obvious, since those are very dark tones)
I can't exactly pinpoint whether this is a texconv issue, or an issue inherent to the BC codec which we can't do anything about ?
But if it is, I don't really understand how BC could reasonably be used so widely, so something doesn't quite fit here
The original .tif image

The resulting BC3_UNORM output, where the dark grey/brown in some places suddenly get a greenish hue that comes from nowhere

I've tried a range of command line options so far, but none have solved the issue
Any help would be greatly appreciated !

This is likely an artifact of the BC algorithm. Remember that in BC1-3, the RGB end-points are 5:6:5 which tends to make things 'greenish' in edge cases.
If you are targeting Feature Level 11.0 or better hardware, BC7 is a better choice.
Otherwise, you can try -bc:u to use a non-perceptually weighted evaluation, although perhaps you already tried that.

Another possible work-around is for me to implement 'custom' weights per this issue

I don't know if your particular image could benefit from this, but there's also another possible optimization for cases where the 4x4 block all contains the same pixel value. See this issue

This issue with all texconv bc1-3 compression. I tried NVTT and other noname dds compressors - no such issue
Texconv just unuseful for bc1-3 compression while this issue not fixed
Exampless:
Bc_1 texconv\nvtt\uncompressed(for test)
https://drive.google.com/file/d/1PRPPyTCNH5KZrQCvwV1aGTh0KiN-TCyn/view?usp=sharing

I see it with this latest test case. I don't see in legacy D3DX9 compression.

NVTT has the single color optimization, so that's something I should do sooner than later. That said, this is mostly for performance of compression more than correctness.
That said, legacy D3DX9 texconv and dxtex do not result in the same 'green-ness' DirectXTex texconv seems to produce. I notice the enabling the BC1-3 dithering (-bc d) seems to help. I'm trying to see if that's the difference here are not.

Thx, walbourn
I'll try and report

I'll keep looking to see if there's some other difference between the legacy D3DX9 and DirectXTex DXTn compressor that could account for thi.

Looking closely at the D3DX9 compressor results, it really does look to me like dithering is the key difference, so -bc d should be the answer.
In fact, from a "root-mean-square error" metric, the result of the modern texconv with -bc d is better (PSNR 44.663095 dB) vs. the older D3DX9 compressor (PSNR 42.847420 dB). Without dithering, the new texconv has the same as the old D3DX9 PSNR 42.847420 dB). Of course, PSNR isn't the same as a perceptual difference metric.


CONFIG SET requirepass mypass

First of all, I type the following command："config+set+requirepass+1234",
Then enter the command "config+rewrite".Now the password is permanent.
Could I please without manually delete the config file, how to remove the password

I pushed an update to the master branch that allows for config+set+requirepass to reset the password. Thank you for reporting this issue.


I want to use a cache when I am offline

Hello.
When I retrieve images from the server, I get it normally if it is online, and when I am offline, I will try to display it if there is a cache, is it possible?

https://github.com/pinterest/PINRemoteImage/blob/master/Source/Classes/PINCache/PINCache%2BPINRemoteImageCaching.m This is useful @soushu Come on


[ui/ux]: AIM, Accounts pagination

Is there an existing issue for this?

[X] I have searched the existing issues

Summary
Implement pagination inside AIM -> Account list.
I have invited 29 account and thats seems ugly, maybe will be good implement search and pagination for this list?
The same at Team Members.
Why should this be worked on?
My team can be more then 100 peoples, and I think thats will be hard to manage it...

Great point! That part was changed ages ago. I will prioritize it!
Raw draft in progress version:

It is released in the latest version.


(Feature): Add command and functionality to parse/decode signed JWT in Web5 CLI

🚀 Goal
Add a new feature to the Web5 Rust CLI that allows users to parse or decode JSON Web Tokens (JWTs).
🔑 Tasks

[ ] Create a new command for parsing/decoding JWTs (e.g., web5 jwt decode)
[ ] Implement the logic to decode and display the header, payload, and signature of a JWT
[ ] Add options to format the output (e.g., pretty-print JSON)
[ ] Implement error handling for invalid JWTs
[ ] Add appropriate documentation to README for the new command
[ ] Write tests to ensure the feature works correctly
[ ] Update the CLI's help information to include the new command

🌟 Resources

Current Web5 Rust CLI README
Web5 Rust CLI Source Code
Web5 Documentation on parsing signed JWT
Web5 CLI built in Go for reference
JWT.io
RFC 7519: JSON Web Token (JWT)

⚡  Getting Started

Comment ".take" on this issue to get assigned
Fork the repository and create a new branch for this task
Update the documentation as described in the tasks
Submit a pull request with your changes
Respond to any feedback during the review process

💭 Questions?
If you have any questions or need clarification, please comment on this issue or join our Discord community.
Happy coding! 🎉

HECK YEAH.
.take

Hey hey @Marvellous111 . Thanks for your enthusiasm. This issue wont be available until Oct 1st for Hacktoberfest. Can you do the .take comment on that date and it will actually auto assign for you after that date? Thank you!

.take

hey @Marvellous111 . Are you still interested in this issue? If so, try commenting the keyword .take (not in the code ticks. Just doing this to avoid assigning the issue to me)
Thank you!

.take

hey @Marvellous111 . Are you still interested in this issue? If so, try commenting the keyword .take (not in the code ticks. Just doing this to avoid assigning the issue to me)
Thank you!

Yes, I am working on it.
On Tue, Oct 8, 2024 at 1:22 PM anurag verma @.***>
wrote:

hey @Marvellous111 https://github.com/Marvellous111 , Have you been
working on this issue?
—
Reply to this email directly, view it on GitHub
https://github.com/TBD54566975/web5-rs/issues/327#issuecomment-2399694309,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BGQVZFKYT4NPZ6BNIUJJNITZ2PE6XAVCNFSM6AAAAABNKWDC3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJZGY4TIMZQHE
.
You are receiving this because you were mentioned.Message ID:
@.***>


Enable Travis CI Builds on x86_64 and i686

Enable Travis CI building on x86_64 and i686 based systems.
Closes #22.

Closing this in favor of continuing to support only x86_64.


Typo Key Vault Authentication Fundamentals Article

There is a typo in the python example on the article Key Vault Authentication Fundamentals.
The typo is:
ENTER YOUR CLIEND SECRET HERE
Screenshot:

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

ID: 87c888fe-b125-df75-7c4f-09d831275ab1
Version Independent ID: a4bfe0cc-8fe1-1249-0aa2-e27a96f55251
Content: Azure Key Vault authentication fundamentals
Content Source: articles/key-vault/general/authentication-fundamentals.md
Service: key-vault
Sub-service: general
GitHub Login: @ShaneBala-keyvault
Microsoft Alias: sudbalas

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

Thanks! I made a pull request to fix that. https://github.com/MicrosoftDocs/azure-docs-pr/pull/136478


Data feeding into the CNN model should be normalised or not?

Hello there,
I have checked the notebook examples, such as the MNIST example. The test data set you feed into the CNN model is not normalised (it is still between o and 255). Does that mean the CNN model you loaded is trained using the not normalised data or in the library it has an implicit  normalised function? I have a model trained on the normalised data, so should I use the original test data or normalised data to feed to the normal?
Thanks
Yan

Hi @Yanjiayork, you are correct that the model that I loaded was not trained on normalized data. If you have a model trained on normalized data, you should definitely normalize the data when using your model.

Avanti

Hi Avanti,
Thank you very much. That is very helpful. I have another question is about calculating the contribution scores. I understand task_idx represents the index of the node in the output layer that we wish to compute scores. In my case, I only have one node, i.e. sigmoid. Does this mean the calculated contribution score is against whatever the output is? In other words,  the contribution score is not against class 0 or 1 specifically? If so, is it possible to know the contribution score against class 0 and against class 1 respectively without changing the output layer to 2 nodes?
Many thanks
Yan

Hi Yan,
A positive contribution to the logit of the sigmoid can be interpreted as a positive contribution to class 1 (which is equivalent to a negative contribution to class 0). Similarly, a negative contribution to the logit of the sigmoid can be interpreted as a positive contribution to class 0 (which is equivalent to a negative contribution to class 1). To see this mathematically, note the equivalence between a sigmoid and a two-class softmax:

For a sigmoid with a logit of x, the probability of class 1 is: 1/(1 + e^-x)
For a softmax where the logit for class 0 is x0 and the logit for class 1 is x1, the probability of class 1 is e^x1 / (e^x1 + e^x0)
Note that 1/(1 + e^-x) = (e^0 / (e^0 + e^-x)). Thus, a sigmoid with a logit of "x" is equivalent to a softmax where the logit for class 0 is -x and the logit for class 1 is "0".
Also note that (e^0 / (e^0 + e^-x)) = (e^x / (e^x + e^0)). Thus, a sigmoid with a logit of "x" is ALSO equivalent to a softmax where the logit for class 0 is "0" and the logit for class 1 is "x".

Does that make sense?


improve tab handle

now tab  button will move focus to next or previous line or even to next focus node in widget tree.

Thanks for the code contribution.
I will make sure to distribute it in the next version.

Released PlutoGrid 5.3.0.
tabKeyAction property added to PlutoGridConfiguration.
The default value is normal, and when set to moveToNextOnEdge, pressing the tab key in the last cell moves to the first cell in the next row. Opposite for Shift + Tab keys.
Thank you.


Enhance 'site remove' supporting deletion o365 group connected site. Closes #1561

Enhance 'site remove' supporting deletion of o365 group connected site.

Enhance 'site remove' supporting deletion o365 group connected site. Closes #1561

Linked Issue

Closes #1561

Awesome! We'll have a look at it asap 👏

Merged manually. Thank you! 👍


Make the library compatible with the latest version of Google Cloud SDK

Google.Api.Gax.Grpc did a major version update with several changes, see https://github.com/googleapis/gax-dotnet/releases/tag/Google.Api.Gax-4.0.0. As a result, the Ads client library isn't compatible with the latest version of Cloud SDK. To match the behaviour, we will make the library compatible with the latest version of Google Cloud SDK.

Upgrade the library to use Grpc.Net.Client by default. Fallback is available for Grpc.Core.Api. See https://grpc.io/blog/grpc-csharp-future/ for additional reasons why this change is required.
Bump the dependency requirement to .netstandard2.1 to match the latest Google Cloud SDK.
Bump all the nuget dependencies to match the requirements of Google.Api.Gax.Grpc.
Since this change is backwards incompatible, we should do a major version update of Google.Ads.Gax, Google.Ads.GoogleAds.Core and Google.Ads.GoogleAds libraries.

We are currently blocked because Grpc.Net.Client doesn't expose a setting for setting either Proxy or the max size of trailing metadata. See  https://github.com/grpc/grpc-dotnet/issues/1842.
This in turn is due to an overflow bug in .NET runtime. https://github.com/dotnet/runtime/issues/73848

Fixed in v14.0.0.


changed.bs.select	Not Passing The Right Params To Event Handler Function

$('#my_select').on('changed.bs.select', function (e, clickedIndex, newValue, oldValue) {
        console.log('clickedIndex');
        console.log(clickedIndex);
        console.log('newValue');
        console.log(newValue);
        console.log('oldValue');
        console.log(oldValue);
          // do something...
        });

prints the following:

clickedIndex
1
newValue
true
oldValue
false

When I look through the source code where the changed event is triggered, I see this:
// Trigger select 'change'
          if ((prevValue != that.$element.val() && that.multiple) || (prevIndex != that.$element.prop('selectedIndex') && !that.multiple)) {
            // $option.prop('selected') is current option state (selected/unselected). state is previous option state.
            that.$element
              .trigger('changed.bs.select', [clickedIndex, $option.prop('selected'), state])
              .triggerNative('change');
          }

One would expect prevValue and that.$element.val() to be passed to the event instead of $option.prop('selected') and state

newValue and oldValue refer to the value of the changed option - either true or false - to see whether the option was changed to be selected or unselected, not the value of the select itself. However, oldValue is a bit redundant, as it's obviously always the opposite of newValue. It would also make more sense to refer to newValue as selected and oldValue as unselected to improve clarity. It would make more sense to also pass in the select's previous value. Passing in the select's current value is unnecessary, as it can easily be retrieved with $(this).val().

@caseyjhol, thanks a lot for your prompt response.
You are right, selected and unselected would be more descriptive, and it's also true that since one is the opposite of the other, passing only one of them would streamline the code/api.

Thanks for this clearing up. I also thought oldValue would give the actual val. One can see how that would be handy.


Copying of labels/annotations from Task to TaskRun is unreliable

Expected Behavior
The Task labels should be copied to the TaskRun
Actual Behavior
If there is a conflict (which is not uncommon when there are multiple controllers such as tekton-results, tekton-chains etc all reconciling on TaskRuns) Tekton does not retry, it just logs a warning and the labels are missing. This breaks multi-platform builds in RHTAP which use labels to identify multi platform tasks.
Steps to Reproduce the Problem
It's hard to reproduce consistently, but the code is here: https://github.com/tektoncd/pipeline/blob/7069889e796b0b12e12a3d1095a5f1a3d98c2739/pkg/reconciler/taskrun/taskrun.go#L304
You can see that is just logs a warning instead of returning an error to retry. Note that I am not familiar with this code so I am not 100% sure if the obvious solution of just returning the error is the correct one.

@stuartwdouglas it does return an error afterward, few lines later https://github.com/tektoncd/pipeline/blob/7069889e796b0b12e12a3d1095a5f1a3d98c2739/pkg/reconciler/taskrun/taskrun.go#L308.
The issue is usually different than this (but same results). Any controller that watches and mutate the labels of a TaskRun or PipelineRun can overwrite what another did. This is a very similar issue than https://github.com/tektoncd/pipeline/issues/5297 (that was fixed by https://github.com/tektoncd/pipeline/pull/5597/files that makes the race less likely but still possible).

Ah, I missed that the error is returned, but I still think that it is unlikely to be a coincidence that the labels failed to copy on a task that had that log message. Looking through the log that message is not very common, so it seems very likely to be related.
That said if the copying is going away then I am going to need to come up with another solution anyway, so I am happy for this to be closed.


set the scrollbar over the leftside

Hi, i would like to set the scrollbar in left position without using css properties like direction:rtl
there is another way to do it?.
For example via plugin properties: "$(selector).mCustomScrollbar({ option: value });"
Thanks.

+1

+1


ModuleNotFoundError: No module named 'pkg_resources'

🔍 Before submitting the issue

[X] I have searched among the existing issues
[X] I am using a Python virtual environment

🐞 Description of the bug
Failed to run the following example from documentation
import pyvista as pv
from ansys.tools.visualization_interface import Plotter

mesh = pv.Cube()
# Create a plotter
pl = Plotter()
# Add the mesh to the plotter
pl.plot(mesh)
# Show the plotter
pl.show()

Traceback (most recent call last):
  File "d:\Research\visualization\ansys-tools-visualization-interface\visualization-interface.py", line 2, in <module>
    from ansys.tools.visualization_interface import Plotter
  File "D:\Repos\ansys-tools-visualization-interface\src\ansys\tools\visualization_interface\__init__.py", line 25, in <module>
    import pkg_resources
ModuleNotFoundError: No module named 'pkg_resources'

📝 Steps to reproduce

Install local development version with virtual environment.
run the code snippet provided with description section.

💻 Which operating system are you using?
Windows
📀 Which ANSYS version are you using?
NA
🐍 Which Python version are you using?
3.12
📦 Installed packages
about-time==4.2.1
aiohttp==3.9.5
aiosignal==1.3.1
alive-progress==3.1.5
ansys-api-fluent==0.3.22
ansys-api-platform-instancemanagement==1.1.0
ansys-fluent-core==0.20.1
ansys-fluent-visualization==0.9.0
ansys-platform-instancemanagement==1.1.2
-e git+https://github.com/ansys/ansys-tools-visualization-interface@92495cf670d3d75c5c5a288ea50629acc6f56ecf#egg=ansys_tools_visualization_interface
ansys-units==0.3.2
attrs==23.2.0
beartype==0.17.2
certifi==2024.2.2
charset-normalizer==3.3.2
contourpy==1.2.1
cycler==0.12.1
docker==6.1.3
fonttools==4.51.0
frozenlist==1.4.1
grapheme==0.6.0
grpcio==1.63.0
grpcio-health-checking==1.48.2
idna==3.7
importlib_metadata==7.1.0
kiwisolver==1.4.5
lxml==4.9.4
matplotlib==3.9.0
more-itertools==10.2.0
msgpack==1.0.8
multidict==6.0.5
numpy==1.26.4
packaging==24.0
pandas==1.5.3
pillow==10.3.0
platformdirs==3.11.0
pooch==1.8.1
protobuf==3.20.3
psutil==5.9.8
pyparsing==3.1.2
PySide6==6.7.0
PySide6_Addons==6.7.0
PySide6_Essentials==6.7.0
python-dateutil==2.9.0.post0
pytz==2024.1
pyvista==0.43.8
pyvistaqt==0.11.0
pywin32==306
PyYAML==6.0.1
QtPy==2.4.1
requests==2.31.0
scooby==0.10.0
shiboken6==6.7.0
six==1.16.0
trame==3.6.0
trame-client==3.0.3
trame-server==3.0.0
trame-vtk==2.8.8
trame-vuetify==2.5.0
urllib3==2.2.1
vtk==9.3.0
websocket-client==1.8.0
websockets==12.0
wslink==2.0.2
yarl==1.9.4
zipp==3.18.2

Not sure what is the root cause of the issue. However, reinstalling the module with a new virtual environment resolved the issue.

Python 3.12 does not provide pkg_resources by default. If it is not included as a dependency, it should be added.
See https://docs.python.org/3/whatsnew/3.12.html#summary-release-highlights and search for "setuptools" or "pkg_resources"

This was fixed by https://github.com/ansys/ansys-tools-visualization-interface/pull/51 , I was getting the project version the wrong way

And thanks for opening the issue @abhishekchitwar 😄


Move React to peerDependencies

It's incorrect to put React in dependencies because this causes duplicate React installation in react-youtube/node_modules when doing npm install.

Thanks, appreciate it. Still getting the hang of all this!

Thank you for sharing. It's a lovely component and the code is very clean.


teams: <IP_ADDRESS>60 -> <IP_ADDRESS>857

Motivation for this change
New release appeared for download.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
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 nixpkgs-review --run "nixpkgs-review wip"
[x] 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)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Been using this for a week now and it works just fine :+1:

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

1 package built:

teams

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/316


Update .ko.yaml

Update to base-debian12
Open questions?

[ ] Does fulcio still actually need cgo or libssl, could we just use base-nossl... instead?
[ ] Could we actually just run in non-root mode?

cc: @jku

I don't know any reason we need root. @bobcallaway @cpanato Are you aware of any reason?

Can you also change it in https://github.com/sigstore/fulcio/blob/dd9a1050eb7a7b885ffb0a661eabdf32931b4a1a/.goreleaser.yml#L5?

@cpanato what's the testing strategy for this change? should I swap to the nonroot tag

I've switched to nonroot. I tested locally with ko build ., pulled the generated container, and verified I could start and query the CA.

sorry, i am a bit busy with company work
this looks good to me as well


MSL: Why do names starting with '_' followed by a digit e.g. "_1PixelColor" get changed to _m?

Hi,
Do you reserve names starting with '_' followed by a digit for something? from what I've seen these names are valid MSL, this is kind of a hidden gotcha, spent today debugging why our UI is misbehaving, only to find out that calling:
spvc_compiler_get_member_name(spvCompiler, bufferResource.base_type_id, j); on a variable named  _1PixelClipInvViewreturns an empty string. It seems that the names are changed to "_m" followed by their index int the UBO, so it looks intentional, however haven't found this documented anywhere.
The reflection result seems off to me, but I might not know the full context.
(Edit: accidentally submitted the issue a bit early so adding a repro on shader playground http://shader-playground.timjones.io/9734fd726901260175252c5c3a9bc812, can spend some time on a better reproduction shader if necessary)

Normally when that happens, it's because the SPIR-V doesn't have an OpName or OpMemberName for the object in question, but in your example, I see that the generated SPIR-V indeed has those. I wonder why SPIRV-Cross stripped them away...

Also, the version of SPIRV-Cross on Shader Playground is really old. Does this still happen with current SPIRV-Cross?

_$digit is indeed reserved by the implementation, and such names will be ignored. As they are used to translate IDs which do not have a name, and need to be reserved. Members are _m$digit. It might be possible to be a little smarter to not block names like these since they won't conflict, but this is a rather special case ...

I'm on holiday now FWIW, so PR-ing it would be a faster way to get this fixed.

These names might be culled away already in parsing stage, which is not strictly necessary, albeit convenient. If you only need to know the name before compilation for reflection, it should be possible to defer the name pruning after parsing, but before compilation.

Ok, thanks for the details!

Does this still happen with current SPIRV-Cross?

The commit I'm using is quite recent (24 days old) so most likely

I'm on holiday now FWIW, so PR-ing it would be a faster way to get this fixed.

That's fine, we can wait for now :), this bug is not too time critical as we haven't yet shipped the code which uses SPIRV-Cross. In the meantime we can work around the issue at the source level since we only use these names in a few places, hopefully there aren't other reserved patterns...


add a response body close

Signed-off-by: Allen Sun<EMAIL_ADDRESS>

Updated this part. PTAL @stevvooe @ijc

LGTM
@allencloud Thanks for the PR!

Codecov Report

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

@@           Coverage Diff           @@
##           master    #1537   +/-   ##
=======================================
  Coverage   42.61%   42.61%
=======================================
  Files          24       24
  Lines        3318     3318
=======================================
  Hits         1414     1414
  Misses       1581     1581
  Partials      323      323

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 fe9d6a4...c6d5595. Read the comment docs.


Fix 'tqdm' object is not subscriptable" error in huggingface.py when batch size is auto

Issue:
When batch size is set to auto, the loglikelihood_tokens function throws the error "tqdm object is not subscriptable" because tqdm(re_ord.get_reordered(), disable=(disable_tqdm or (self.rank != 0))) is passed to the utils.chunks function.
Fix:
My change instead calls utils.chunks with re_ord.get_reordered() as the input and then wraps the output chunks with tqdm.
Testing:
Error encountered benchmarking GPT-2 on lambada_openai and other datasets. Confirmed change fixed error on those datasets.
Note:
Made the same change to greedy_util function, which had nearly identical code. Did not directly encounter or test an error with the greedy_util function.

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


Only can connect using data

PiVPN Issue Template

Issue
I can only connect to the vpn on my data. I can not use any WIFI. I get this error when i use my vpn client.
Read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Have you searched for similar issues and solutions?
I have not seen any that have the same issue

Console output of curl -L install.pivpn.io | bash
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   178  100   178    0     0    399      0 --:--:-- --:--:-- --:--:--   400
100 51064  100 51064    0     0  62127      0 --:--:-- --:--:-- --:--:-- 62127
:::
::: sudo will be used for the install.
::: Update option selected.
::: Verifying free disk space...
:::
::: Checking apt-get for upgraded packages.... done!
:::
::: Your system is up to date! Continuing with PiVPN installation...
::: Using IP address: MyLocalIp
::: Using interface: enxb827ebe8521e
::: Using User: pi
::: Using protocol: udp
::: Using port: MyPort
:::
::: Static IP already configured.
:::
::: Checking for existing base files...
:::    Checking /etc/.pivpn is a repo... OK!
:::     Updating repo in /etc/.pivpn... done!
:::
::: Stopping OpenVPN service... done.
:::
::: Installing scripts to /opt/pivpn... done.
::: Building CA...
Generating a 2048 bit RSA private key
................................................................................................+++
......................................+++
writing new private key to '/etc/openvpn/easy-rsa/pki/private/ca.key.aWUheQilil'
-----

::: CA Complete.

Note: using Easy-RSA configuration from: ./vars
rand: Use -help for summary.
Generating a 2048 bit RSA private key
................+++
...........................+++
writing new private key to '/etc/openvpn/easy-rsa/pki/private/server_7lFXxksRGKeOcsTb.key.fCrloji6Vw'
-----
Using configuration from /etc/openvpn/easy-rsa/openssl-1.0.cnf
Can't open /etc/openvpn/easy-rsa/pki/index.txt.attr for reading, No such file or directory
1995543968:error:02001002:system library:fopen:No such file or directory:../crypto/bio/bss_file.c:74:fopen('/etc/openvpn/easy-rsa/pki/index.txt.attr','r')
1995543968:error:2006D080:BIO routines:BIO_new_file:no such file:../crypto/bio/bss_file.c:81:
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName            :ASN.1 12:'server_7lFXxksRGKeOcsTb'
Certificate is to be certified until Oct 12 23:56:45 2028 GMT (3650 days)

Write out database with 1 new entries
Data Base Updated

Note: using Easy-RSA configuration from: ./vars
Using configuration from /etc/openvpn/easy-rsa/openssl-1.0.cnf

An updated CRL has been created.
CRL file: /etc/openvpn/easy-rsa/pki/crl.pem

net.ipv4.ip_forward = 1
run-parts: executing /usr/share/netfilter-persistent/plugins.d/15-ip4tables save
run-parts: executing /usr/share/netfilter-persistent/plugins.d/25-ip6tables save
::: Restarting services...
Synchronizing state of openvpn.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable openvpn
::: done.
:::
::: Update complete!
:::
::: The install log is located at: /etc/pivpn/install.log

Console output of pivpn add or pivpn add nopass
Enter a Name for the Client:  test
Enter the password for the client:
Enter the password again to verify:
spawn ./easyrsa build-client-full test

Note: using Easy-RSA configuration from: ./vars
rand: Use -help for summary.
Generating a 2048 bit RSA private key
..........................................+++
.....................+++
writing new private key to '/etc/openvpn/easy-rsa/pki/private/test.key.mYANcnNPLP'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
Using configuration from /etc/openvpn/easy-rsa/openssl-1.0.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName            :ASN.1 12:'test'
Certificate is to be certified until Oct 12 23:57:39 2028 GMT (3650 days)

Write out database with 1 new entries
Data Base Updated
spawn openssl rsa -in pki/private/test.key -aes128 -out pki/private/test.key
Enter pass phrase for pki/private/test.key:
writing RSA key
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
Client's cert found: test.crt
Client's Private Key found: test.key
CA public Key found: ca.crt
tls-auth Private Key found: ta.key

========================================================
Done! test.ovpn successfully created!
test.ovpn was copied to:
  /home/pi/ovpns
for easy transfer.

I have looked around and could not find anything

Have you tried from the same wifi network as the pivpn?

Yes i get the same error it only works on my phones Data

There is no point to connect from the same network (think about what a VPN use case is), and most likely your router is blocking the connection anyways. Try from a different wifi network.

I have tryed the wifi at work as well as at the mall in my city. I get the same error.

It seems as if when my phones client is on wifi it cant connect to the server. I checked the openvpn logs and it only shows up when i use my LTE.

So the raspberry pi log /var/log/openvpn.log does not show anything at the time your phone is supposed to connect via wifi? Can you post the PHONE log of a failed attempt?

Changed to a low tcp port works fine now


chore: adding shell style and apt command

pip is not available by default.
testing on Ubuntu 20.04 with the Ubuntu package installed by apt.

Error visible on vault mode when trying to run the node mode command :
node_server  localhost
The NodeKeyClient server is running on port 39898
Connected: ('<IP_ADDRESS>', 56356) on Thread-1
----------------------------------------
Exception happened during processing of request from ('<IP_ADDRESS>', 56356)
Traceback (most recent call last):
  File "/usr/lib/python3.8/socketserver.py", line 683, in process_request_thread
    self.finish_request(request, client_address)
  File "/usr/lib/python3.8/socketserver.py", line 360, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/lib/python3.8/socketserver.py", line 747, in __init__
    self.handle()
  File "./vault.py", line 233, in handle
    reply, nkdata = create_send_public_key(nkdata)
  File "./vault.py", line 144, in create_send_public_key
    nkdata["Private"] = nkdata["RSAkey"].export_key()
  File "/usr/lib/python3/dist-packages/Crypto/PublicKey/RSA.py", line 126, in __getattr__
    raise AttributeError("%s object has no %r attribute" % (self.__class__.__name__, attrname,))
AttributeError: _RSAobj object has no 'export_key' attribute
----------------------------------------

Closing it now because I don't have time to progress on it. I will reopen it later.


Multiple reference does not take into account nbPeaks

@lpatiny
i tracked what i pass to your function and this what I found
{targetX: 0, from: 2.4658087130369726, to: 5.152177225911352, nbPeaks: 2}
so I think the problem related to xyXShift function, Can you check it.

@lpatiny
i tracked what i pass to your function and this what I found
{targetX: 0, from: 2.4658087130369726, to: 5.152177225911352, nbPeaks: 2}
so I think the problem related to xyXShift function, Can you check it.


FakeXMLHttpRequest in bower.json to match fake-xml-http-request in package.json

So I can get fixes from the latest published version of FakeXMLHttpRequest.

:+1:


Fixed duplicate leanModal overlays

The bug is by opening opened modals multiple times, it will generate
duplicate overlays. These overlays will not be removed properly.
Fixed:
Updated openModal, added _stackModals array to store references of each
modal. If a modal is opened then it will retrieve overlayID.
Updated closeModal, it removes references of modals when close.
I created a plunk to illustrator bug.
http://embed.plnkr.co/NMosr6KBPlR1NTyX3FLj/
(Somehow Codepen doesn’t run it properly)

Merged latest master branch. I have tested the code with the latest version 0.97.1.

any insight to when/if  this will be merged?


Consider merging our improvements into upstream and remove this fork

There's a bunch of improvements now on the upstream project that we'd need to add.
/cc @max-wittig @bufferoverflow

@max-wittig @bufferoverflow In the context of our discussions yesterday, perhaps it's time to put a milestone to this task.


API Key

The API key needs to be in an env file.

Hello, can i solve this problem ??

Api key will add in env file so i will not visible to anyone because .env is gitignore file.

Hello, can i solve this problem ??

Yes, you can
I'll assign it to you

Api key will add in env file so i will not visible to anyone because .env is gitignore file.

Okay
Awesome
Thanks

@Himanshuraj2918 why did you close the pull request you made?


Fedora 31 777;preexec PS0

Using alacritty on Fedora 31 prints 777;preexec from PS0 in bash.
See the following issue for another terminal emulator for more details/discussions:
https://github.com/TragicWarrior/libvterm/issues/147
System
OS: Linux
Version: alacritty 0.4.1-dev (8a83340)
Linux/BSD: Wayland

@sbennett18 can't repro on fedora 31 using a default bash settings providing by system.
However I feel like this is a duplicate of #2981 and the link you've posted kind of exposes it.

Just out of curiosity, is your TERM set to something that doesn't begin with xterm or vte?  I'm also using a brand new install of Fedora 31.
I only did a cargo build --release and am running the resulting bin from Gnome for now.
The last case statement in /etc/profile.d/vte.sh is the source of the 777;preexec string, and, unsurprisingly, commenting it out prevents this from showing up.

The last case statement in /etc/profile.d/vte.sh is the source of the 777;preexec string, and, unsurprisingly, commenting it out prevents this from showing up.

Do I understand it correctly that this issue only appears with an xterm or vte terminfo then?
First of all it seems pretty clear that it is an upstream issue, since it happens on multiple terminals and is caused by something in the shell profile.
And the other thing is that only the alacritty and alacritty-direct terminfos are supported. So with everything else, you're on your own.

Do you launch Alacritty from a VTE-based terminal? (I.e. do you have the VTE_VERSION environment variable defined?)
Fedora patches VTE to add support for command completion notification on OSC 777, and hook up to using it in /etc/profile.d/vte.sh, given that VTE is detected.
That being said, OSC escape sequences have a well defined generic syntax. Alacritty should silently ignore the ones with unrecognized numbers, without emitting garbage. Otherwise it's impossible to add new OSC features without causing breakage in older Alacritty versions. Trust me, we've been there with VTE :)

My loose understanding is that the Fedora recently adopted Enlightenment's OSC 777 escape sequence for notifications in the terminal.
From this mailing list Add signals proxying an interactive shell's precmd and preexec hooks

Add sequences
OSC 777 ; preexec BEL
OSC 777 ; preexec ST
that can be used from an interactive shell's preexec hook to notify
the terminal emulator that a new command is about to be executed.

I think I'm proposing what @egmontkob said about silently ignoring unrecognized OSC escape sequences.

Fedora patches VTE to add support for command completion notification on OSC 777, and hook up to using it in /etc/profile.d/vte.sh, given that VTE is detected.

Oh we do. Using echo -e "\e]777;preexec\007" (which I assume is what this command does), will not print anything in Alacritty.

Then how come a literal 777;prexec appears, as per the original report? I guess that's what you're also trying to figure out, right? :)

Then how come a literal 777;prexec appears, as per the original report? I guess that's what you're also trying to figure out, right? :)

Oh, it's because of the way they write their escape:
printf "\u009D777;preexec\u009C"

I'm pretty sure the only terminal that is going to work in are the VTE based ones. I'm not sure why they've gone for using the UTF8 encoding for OSC.

Closing this issue since I don't think Alacritty is doing anything 'wrong' here. If there's interest in supporting this escape, we can open a separate issue.

Yup, I also just discovered that they use C1 here.
C1 is quite problematic, especially when combined with UTF-8. xterm deliberately doesn't support it. It's also problematic from security point of view if an application wants to make sure that it doesn't send control characters to the terminal (as part of untrusted data), but it cannot be absolutely certain about the terminal's encoding (it can only assume that the locale is set up correctly). I already regret that I added C1 support in VTE. I think it's fair if you decide not to add C1 support.

Alacritty should never be advertised as VTE-based though, regardless of support for this escape.

VTE-based terminals set $VTE_VERSION, and if you're launching Alacritty from one of them then this variable remains set. You could unset it, but arguably it shouldn't be your job. The proper solution would be if terminals agreed in one common environment variable to identify the terminal (as opposed to $TERM which describes its behavior), e.g. VTE would set TERM_APP=vte and you would overwrite it with TERM_APP=alacritty. But this is another story...

I already regret that I added C1 support in VTE. I think it's fair if you decide not to add C1 support.

It's kinda interesting that it came up in here, since #2981 introduced me to the "problem" of C1 support and handling of different terminal emulators.
I've noticed that almost no terminal emulator other than Alacritty (I don't think I found any), supports the 8-bit non-utf8 encoded C1 escapes by default.
While some (Kitty and VTE at least), support only the UTF-8 encoded ones by default.
@egmontkob Are you aware of why VTE only supports them encoded as UTF-8? Is this a problem with potential character encoding conflicts, or is it just because they're never used?

The proper solution would be if terminals agreed in one common environment variable to identify the terminal (as opposed to $TERM which describes its behavior), e.g. VTE would set TERM_APP=vte and you would overwrite it with TERM_APP=alacritty. But this is another story...

This is a way, way bigger issue, but generally I do not think there's any reason why a terminal emulator should be directly identified at all anyways, right?
Generally we shouldn't query for VTE here, but instead for OSC 777 support, regardless of which terminal emulator it is.

Are you aware of why VTE only supports them encoded as UTF-8?

In VTE, C1 is supported as the U+0080 .. U+009F characters encoded according to the current encoding.
The raw bytes 0x80 .. 0x9F cannot be supported in UTF-8 environment because they conflict with UTF-8, valid printable characters might contain these bytes.

Generally we shouldn't query for VTE here, but instead for OSC 777 support, regardless of which terminal emulator it is.

Yes, but how? There's no good answer. Hence a suboptimal workaround.

I've filed Red Hat 1783802.

Yes, but how? There's no good answer. Hence a suboptimal workaround.

Yeah, it makes sense, but I still feel like if people are willing to check an environment variable for manually comparing terminal emulators, they'd be willing to support some better way of querying if there was one. There's just not an easy solution to that.

I've filed Red Hat 1783802.

That's a good idea to work around this, though in general all terminals where this is run should support VTE. But it doesn't hurt either way.

The raw bytes 0x80 .. 0x9F cannot be supported in UTF-8 environment because they conflict with UTF-8, valid printable characters might contain these bytes.

I'm definitely not very knowledgeable about UTF-8 and unicode, but isn't there a clear destinction between the byte 0x85 for example and the unicode glyph U+0F85?
Since Alacritty has a separate UTF-8 and non-UTF-8 parser, we do actually add a newline when the user does echo -e "\x85", but the glyph echo -e "\u0f85" still shows the correct glyph of course.
That's what you've been talking about, right?
Or is the issue that VTE combines these both in the same parser and thus an introducer of an escape sequence like the 8-bit CSI (0x9b) would cause the parser to stop interpreting unicode and instead start an escape sequence?
Thanks for your help by the way, it's very good to get some insight into how some other terminal emulators handle this.

but isn't there a clear destinction between the byte 0x85 for example and the unicode glyph U+0F85?

Yes there is. In UTF-8 the glyph U+0F85 TIBETAN MARK PALUTA is encoded as three bytes: 0xE0 0xBE 0x85. Notice the last byte, it happens to be 0x85.
Now, you might say that a valid UTF-8 character cannot begin by 0x85, or by any of the single-byte C1, therefore at any moment either there's a next valid UTF-8 character or there's a next valid C1 control byte, it's always unambiguous. But it's about as ugly and fragile as it could be. E.g. control characters would make the otherwise UTF-8 stream no longer valid UTF-8, thus breaking luit and similar charset converting tools (screen and tmux have this functionality built-in as far as I remember, those would break too); you'd need to carefully decide what to do if a sequence is rejected because it's overlong or encodes a UTF-16 surrogate and yet contains a raw C1 byte, would you interpret that as a control character or not; and I'm sure the list of dilemmas or troubles doesn't end here. I definitely would not attempt to do this, sounds like terrible design to me.

@egmontkob Sounds very fair to me. It's important to point out that Alacritty doesn't actually accept the 8-bit escapes like \x9b, but instead just accepts NEL, HTS and DECID. So those are definitely a bit simpler and don't require the complexity of permitting full 8-bit C1 escape sequences.

I don't see a difference between supporting just a few C1's or supporting all of them. If you even support just one, there's already the question: Which format do you exactly support: the single byte 0x85, or U+0085 which becomes two bytes in UTF-8? If the former then you interfere with the UTF-8 encoding in weird ways.

We support only the 0x85 format, however we do not accept them as a CSI introducer for example. It's just the distinction that the C1s are passed to Alacritty from our parser, but the parser itself just passes them through. Though in theory I don't think it would be much of a problem.

IMO it is unfortunate to see people implementing 8-bit C1, especially when there are obvious conflicts with UTF-8 and there are no obvious advantages to using it with modern terminals. Because so few terminals support it by default, hardly anyone uses it. It would be nice if it could just be left to die.

In VTE 209 we decided to keep C1 support as we already have it (i.e. the U+0080 .. U+009F characters encoded in UTF-8 or whatever the current charset is). See over there for our reasons.

Very unfortunate, since this clearly has a negative impact on other terminal emulators. But that's up to VTE of course. Thanks for keeping us updated.

The negative impact on other terminal emulators was not done by mainstream VTE, it was introduced by Fedora's patch. And that still doesn't imply that Fedora is the culprit rather than Alacritty.

As mentioned in that issue, VTE is one of the biggest terminal emulators, so of course that comes with a certain responsibility. So that puts pressure on other terminals that these escapes should be supported too, even though that might not be a good idea.

And that still doesn't imply that Fedora is the culprit rather than Alacritty.

Are you implying that it's Alacritty's fault that it does not work when expecting it to be VTE? I don't think that's a reasonable complaint.

comes with a certain responsibility. So that puts pressure on other terminals that these escapes should be supported too

Following this logic, we shouldn't be able to invent anything new; and even should restrict ourselves to the common features of all other terminals? I'm not buying this.
(By the way, in this story we did not even invent anything new, we just interpreted contradicting specifications in one possible way, following some other terminals.)

Are you implying that it's Alacritty's fault that it does not work when expecting it to be VTE?

It's hard to tell who is the culprit here, probably there isn't a clear answer, or it isn't solely one component responsible.
The entire /etc/profile.d/vte.sh is conceptually broken, but would require buy-in from at least the shells or the distributions to fix, and no one among them cares enough. The file is at the wrong place, and should not be shipped by VTE but be something common for all the terminals (or at least the ones that support OSC 7). Fedora's notification patch is broken in many ways, which was why we didn't accept it to upstream VTE; mind you, fixing it would - again - require support from bash which its author rejected. The choice of C1 rather than C0 in the patch is unfortunate. Having to rely on VTE_VERSION and not having a TERM_APP agreement among terminals is also part of the story. And so is that the bug only occurs if you launch Alacritty from VTE, which can sure happen while one is playing/experimenting/debugging terminals, but presumably shouldn't happen when one picks their favorite terminal and stick to that, no matter what that choice is.
There are many ways the problem could be mitigated, e.g. Alacritty could unset VTE_VERSION, or could implement C1 support at least to the extent that the sequence is recognized and silently dropped, or Fedora could switch to C0 (which bug is still open and I hope they will do it). And indeed one way to mitigate it could be for VTE to drop C1 support, thus forcing Fedora to change to C0, but VTE's main developer convinced me that we should not do this.

Following this logic, we shouldn't be able to invent anything new; and even should restrict ourselves to the common features of all other terminals? I'm not buying this.

I think if something is worthwhile, pushing it is a different story than something that might be less desirable. I also think that just implementing something in a 'popular' terminal like iTerm/VTE and hoping someone buys into it is not the right approach (not saying that's the case here).

It's hard to tell who is the culprit here, probably there isn't a clear answer, or it isn't solely one component responsible.

I'm not much concerned with finding someone to blame personally, since that's not constructive.

Alacritty could unset VTE_VERSION

This would never, ever be an option. If we start with trying to reset things other terminals might set, that story will never end. It's just hacky workarounds all the way down.

Having to rely on VTE_VERSION and not having a TERM_APP agreement among terminals is also part of the story

I still don't think this is a good way to solve this and this is a great issue for showcasing the problems it can cause.

I also think that just implementing something in a 'popular' terminal like iTerm/VTE and hoping someone buys into it is not the right approach

So market leaders shouldn't be allowed to invent, while 'small' ones should? I severely disagree.

I'm not much concerned with finding someone to blame personally, since that's not constructive.

Locating the culprit (in terms of piece of software, not in terms of person to blame) is part of analyzing the situation, which might be an important step towards coming up with a solution.

[Alacritty could unset VTE_VERSION] This would never, ever be an option.

Then I honestly hope you don't mind if the other party is not willing to workaround your problem either. ;)

So market leaders shouldn't be allowed to invent, while 'small' ones should? I severely disagree.

There's a difference between just implementing something and abusing the userbase to force adoption in other terminal emulators and cooperating with other terminal emulators to determine what might be worthwhile adding and standardizing.

Then I honestly hope you don't mind if the other party is not willing to workaround your problem either. ;)

So you're saying the other party, which introduced the problem by adding a non-standardized workaround that clearly doesn't work, should expect others to work around the fact that their newly standardized thing doesn't work? How does that make any sense at all?

There's a difference between just implementing something and abusing the userbase [...]

I don't see how supporting C1 would be abuse at all. We've supported them for 5 years, and we weren't the first to add them. Some other terminals had already supported them in 8-bit and in UTF-8 mode too, and some other had already supported them in 8-bit encodings only.
When it comes to interpreting multiple contradicting specifications to figure out how C1 in UTF-8 is supposed to work, what we ended up doing is perhaps the most sensible resolution to this dilemma (see my comment in the VTE bug); and again, is not something without precedence.
But if I understand correctly, the current problem is not specific to UTF-8, it could easily occur with Latin-1 too, correct?

So you're saying [...]

Please don't blame VTE for someone emitting an escape sequence in Alacritty that Alacritty does not understand. Don't even indirectly blame VTE for this, as in abusing its power or whatever, please.

I don't see how supporting C1 would be abuse at all.

I don't think I would call support for C1 abuse, it's just unfortunately specified, but that's not VTE's fault. This was more a general statement than about C1, the problem is more with the environment variable than the C1 support really.

But if I understand correctly, the current problem is not specific to UTF-8, it could easily occur with Latin-1 too, correct?

The C1 problem wouldn't happen without UTF-8 encoding.

Please don't blame VTE for someone emitting an escape sequence in Alacritty that Alacritty does not understand. Don't even indirectly blame VTE for this, as in abusing its power or whatever, please.

VTE introduced the VTE_VERSION, right? Unless the intention wasn't to identify VTE, this means VTE introduced a non-standard way to identify it meant to be used by applications running inside it, right? If VTE encourages this usage, it seems like the possible hazards probably were considered and it was accepted that it might cause problems for other terminals?
Unless VTE made this environment variable for something else of course and applications just decided to use it on their own. But based on your previous statements it seems like this is the VTE approved way to query for this feature.
Coming back to your point about finding someone to blame, so the problem can be addressed, how would this not partially be VTE's fault, if they encourage a way to query for features which causes problems for other terminal emulators? I can hardly blame Fedora for querying for a feature in the recommended way.

VTE introduced the VTE_VERSION, right?

I believe the vast majority of terminals set an environment variable to identify itself. Even xterm does.

how would this not partially be VTE's fault, if they encourage a way to query for features which causes problems for other terminal emulators?

Do you have a better idea?
I mentioned the idea of TERM_APP, you didn't like that, although that would definitely be an improvement compared to all terminals setting their own variables, and would solve the current issue.
(And please don't come with terminfo because I could point you to a mile long page describing how utterly broken that is. For starter, it doesn't have a slot to denote whether OSC 777 is supported for desktop notification or not. The story goes on with central maintainership, lack of versioning, no ability to forward over ssh, etc.)
You just happen to pick on VTE due to the constellation of several independent issues, namely that VTE uses OSC 7 to preserve the directory when opening a new terminal; in order to do this it ships a shell startup file where it checks for itself (as reliably as it can, i.e. failing when another terminal is launched from VTE); a distribution happens to patch this script and happens to use there something that Alacritty does not support.
It could just as easily happen with pretty much every other terminal, it's mostly accidental rather than by design that only VTE happens to trigger the given problem for you. If Red Hat patches VTE, why doesn't it patch Konsole, Xterm etc. for desktop notification, and add a similar /etc/profile.d/*.sh checking for KONSOLE_VERSION, XTERM_VERSION etc.? You happen to blame mainstream VTE because Red Hat decided to add a new feature to this product, whereas if they added it to Konsole or Xterm instead you would probably just as equally blame Konsole or Xterm.
I don't like VTE_VERSION and the check for it as we currently have it, but I can't think of anything better that we could start using immediately.
Let's mention again that the bug only occurs if someone launches one terminal from another, presumably an extremely rare scenario during normally using a system. Can we just conclude that launching one terminal from another (and I don't mean VTE vs. Alacritty, but pretty much any two terminals) is not a supported setup, since shell startup scripts are not tested and not guaranteed to work as expected?
I'd like to emphasize again that mainstream VTE (which I'm a developer of) does not trigger this problem in Alacritty, it's a modification created by Red Hat / Fedora (which I'm not affiliated with) that triggers it. As you've seen, I've already asked that distribution to change this. We could force them by removing C1 from mainstream VTE, but as I agreed with VTE's main developer, we're not going to do this. The buggy behavior is the result of the constellation of many-many tiny issues, including having C1 UTF-8 support, having a vte.sh because of OSC 7, shells refusing to automatically support OSC 7 by themselves, shells refusing to add the necessary features for a proper desktop notification, Red Hat adding a new sequence using C1 rather than C0, no common environment variable or no other good standard for identifying the terminal or its OSC 777 support, and so on. Yet all I can hear from your comments is that VTE is doing pretty much everything wrong, and even if someone adds a piece of code that results in broken end-user behavior then that's also VTE's fault.
It's the end of the day for me, and unfortunately this thread has become pretty unpleasant to me, listening to how you insist that it's VTE to blame (while you refuse to fix it on your side). I'm not planning to come back to continue this discussion. Thanks for your understanding.

I believe the vast majority of terminals set an environment variable to identify itself. Even xterm does.

I'm not sure if any of those terminal emulators encourages to use this to query for features though?

I mentioned the idea of TERM_APP, you didn't like that, although that would definitely be an improvement compared to all terminals setting their own variables, and would solve the current issue.

Sure, it would be an improvement over VT_VERSION, but it would still come with many of the same issues. It's still just a hack.

You happen to blame mainstream VTE because Red Hat decided to add a new feature to this product, whereas if they added it to Konsole or Xterm instead you would probably just as equally blame Konsole or Xterm.

Yes, I blame VTE for causing issues, because VTE caused the issue, not Konsole or XTerm. If those would be causing the issue, I'd blame them. That makes sense, right? If a cooperation of Terminal X and Distro Y, which uses an unreliable method to determine terminal features, causes problems for other projects, then of course I ask myself why Terminal X and Distro Y have to do things this way. That's only natural I'd say.

I don't like VTE_VERSION and the check for it as we currently have it, but I can't think of anything better that we could start using immediately.

I'm not sure why it has to be used immediately though? Implementing a hacky workaround, just to get things done quicker and as a result affecting everyone else is precisely one of the big problems with this. The solution itself is just one approach of many possible, but rushing it out for a single terminal without sufficient regard for others is what causes troubles, not necessarily the solution itself.

Let's mention again that the bug only occurs if someone launches one terminal from another, presumably an extremely rare scenario during normally using a system. Can we just conclude that launching one terminal from another (and I don't mean VTE vs. Alacritty, but pretty much any two terminals) is not a supported setup, since shell startup scripts are not tested and not guaranteed to work as expected?

This means that now I have to somehow explain to my users though, that it is not possible to launch Alacritty from VTE (or possibly any other terminal emulator), because the other terminal emulator has decided not to support that. Sure, I could just redirect all reports in that regard to VTE, similar to what I have to do because of GNOME CSDs already, but that's certainly not desirable?
I personally don't think making it 'unsupported' to launch one terminal emulator from another is something we should strive for at all. I'd much rather just keep playing nicely with everyone else rather than creating such a mess.

I'd like to emphasize again that mainstream VTE (which I'm a developer of) does not trigger this problem in Alacritty, it's a modification created by Red Hat / Fedora (which I'm not affiliated with) that triggers it.

There's a couple of things that have to play together to cause this issue, that's for sure. And generally I don't think it's a big problem for Alacritty, since we can just tell people that they shouldn't have the VTE environment variable set and we should be good.

Yet all I can hear from your comments is that VTE is doing pretty much everything wrong, and even if someone adds a piece of code that results in broken end-user behavior then that's also VTE's fault.

I don't think I've ever stated that VTE is doing everything wrong. I think VTE is doing something wrong by encouraging the use of an environment variable to identify terminal capabilities  and I don't think fundamentally anyone would disagree with that? It's likely just a question of weighing benefits vs rewards and for me as someone solely negatively impacted by this, it clearly doesn't sound amazing to me.
RedHat certainly should have considered the possibilities of this going wrong, but I'd assume they likely didn't have the expertise to predict this problem (I might have missed it myself if I would have just looked at the code). The only reason why I say that VTE is at least partially responsible for this, is because they use VTE's recommended way to query for a feature and that way to query for the specific feature is not sufficient to positively ID the terminal.

It's the end of the day for me, and unfortunately this thread has become pretty unpleasant to me, listening to how you insist that it's VTE to blame (while you refuse to fix it on your side).

It's unfortunate that you see this as unpleasant, but as previously stated I have no intention of just trying to shift blame.
Though I still do not understand what you mean by me refusing to fix things on my side, since you've suggested yourself that C1 UTF-8 encoding support is something people should rather stay away from and VTE mainly keeps it because it already works. Both supporting C1 UTF-8 and VTE's environment variable would be VTE 'forcing' other projects to implement their features because of the traction it has, which is exactly what VTE is not trying to do if I understood you correctly. So that would mean that Alacritty is doing absolutely nothing wrong.

I'm not planning to come back to continue this discussion. Thanks for your understanding.

Fair enough, I think everything relevant has been iterated on more than enough anyways.

I'm really sorry to see this going the way it did. It doesn't benefit anyone.
I'm with @nicm on this; 8-bit C1 control characters should go away. As seen here, they just complicate things and I think we all would be much better of if terminal emulators stopped supporting them. Especially considering the 7-bit variants are much more commonly used and since both the 8-bit and 7-bit variants need 2 bytes when UTF-8 encoded.
Applications would have one way to do things, not two, or three - if you count single-byte 8-bit C1s and UTF-8 encoded C1s as two different variants. Leaving much less room for errors.
That said, @chrisduerr if you would want to support the UTF-8 encoded variants, I do think the only sane way to do it is to put the UTF-8 decoder before the VT parser, and not make it a part of the VT parser, like it is today. This is the way the VTE guys are doing it. But let me stress that I would prefer you did not add support for it.

Can we just conclude that launching one terminal from another (and I don't mean VTE vs. Alacritty, but pretty much any two terminals) is not a supported setup, since shell startup scripts are not tested and not guaranteed to work as expected?

 To me, it's like saying launching a QT/KDE from Gnome isn't a supported setup.

I do think the only sane way to do it is to put the UTF-8 decoder before the VT parser, and not make it a part of the VT parser, like it is today.

Alacritty does the same, it first parses the content as UTF-8 and goes on in non-UTF-8 mode if it is not valid UTF-8.
What we do not do though is accept CSI/DCS/OSC introducers in UTF-8 or non-UTF-8 mode. We only accept the C0 variants of these, meaning the escape is currently not interpreted as C1, but rather as UTF-8.

From VTE 209:

The latest edition of ECMA-48 is from June 1991, UTF-8 was created in Sep 1992.

I feel like this alone is pretty good evidence that there may be some standardization work to be done here. This work would ideally be done with buy in from the major players in the terminal emulator business, but I suppose there's nothing stopping a "grassroots" standard from forming, as long as it's clear and well thought out.
Without trying to talk about the details specifically, the problem we face is in maintaining backwards compatibility with applications that are unlikely to be able or willing to change (at least not quickly). If we had a game plan for a staged removal of C1 control sequences, I feel like this could be to the benefit of everyone. While I understand we may still have untrusted data in text that causes problems, this would be one less possible case for this to happen (I haven't truly evaluated the risk here myself yet).
It's a very good property of the terminal to allow applications to be very sure that the control sequences they emit will be properly interpreted, regardless of locale. Otherwise we force application developers to manage far more than they are typically able, resulting in broken applications for non-native users. This is no small point.

I suppose there's nothing stopping a "grassroots" standard from forming

I'm not sure that ever goes down pleasantly though.

Without trying to talk about the details specifically, the problem we face is in maintaining backwards compatibility with applications that are unlikely to be able or willing to change (at least not quickly).

Which applications are you talking about here exactly? X11 doesn't support these by default, neither does URxvt iirc. Afaik these are not used by applications yet.

This Fedora thing is the first time I have come across anyone trying to use 8-bit C1. If there are any applications at all that won't work without it they are very rare.

Can we just conclude that launching one terminal from another [...] is not a supported setup

I'm sorry, but this is just plain stupid.

I stated a fact. It does not work, as you can see in this thread. I didn't say "is not supposed to be a supported setup", I said "is not a supported setup". The current situation is bad. Maybe you, or anyone else here feels like working on fixing it?

To me, it's like saying launching a QT/KDE app from Gnome isn't a supported setup.

It's a totally wrong analogy. A better analogy would be to say that launching the KDE desktop from GNOME desktop does not work. Which indeed does not.

I've heard of the ISO 6429 standard, but haven't personally read it, since it seems to cost ~$200

ECMA-48 (which is free) says "The fourth edition [...] was adopted by ISO/IEC [...] as second edition of ISO 6429". So you did not miss anything.