Injected Custom Converters are not used

Hello team.
We are using Dozer 5.4.0 to map beans in our enterprise application, however we are encountering a very serious bug : injected custom converters are not taken into account, actually, only custom converters declared in the mapping files are declared.
We are using Spring, and our custom converters are spring beans, we inject these beans into the Dozer mapper. And we have other custom converters (simple POJO not spring beans) which are declared in the mapping files.
<bean id="wrappedMapper" class="org.dozer.DozerBeanMapper">
    <property name="mappingFiles">
        <list>
            <value>dozer/mappings.xml</value>
        </list>
    </property>
    <property name="customConverters">
        <list value-type="org.dozer.CustomConverter">
            <ref bean="customConverter1" />
            <ref bean="customerConverter2"/>
        </list>
    </property>
</bean>

I have verified and the two custom injected custom converters are actually injected into the dozer mapper instance (in the customConverters field).
But when the mapping is invoked, this line of code in DozerBeanMapper is executed :
getMappingProcessor().map(source, destinationClass);
The mapping processor objects also has the custom converters correctly set in the customConverterObjects. Then it executes this line :
classMap = getClassMap(srcObj.getClass(), destType, mapId);
The class map object's customConverters is null !!
Then this is executed
Class<?> converterClass = MappingUtils.findCustomConverter(converterByDestTypeCache, classMap.getCustomConverters(), srcObj
.getClass(), destType);
which calls classMap.getCustomConverters():
return customConverters != null ? customConverters : globalConfiguration.getCustomConverters();
The customConverters field is null, so it returns the globalConfiguration.getCustomConverters()
In the end, the injected custom converters are not used at all, which is a major issue as we cannot map our beans correctly.
Could you please advise or correct this bug.
Best regards,
Mounir

This seems to be related to a bug I encountered
https://github.com/DozerMapper/dozer/issues/242

@MounirReg ; is this still an issue?

Closing due to inactivity.

A few years passed, and an issue was closed due to inactivity... I still got this problem in 5.5.1 version.

Wow! Just realized that there were many newer version released. But.., Same thing happens in DM 6.4.1
What's the purpose of the "customConverters" property of springs's DozerBeanMapperFactoryBean?

Seeing this same issue now in 6.5.0. Is there any other steps I can take to narrow this down.
I am using the dozer-spring-boot-starter and I can see the customConverters listed in the debugger but System.out calls and break points in my CustomConverter class never get hit

I am also facing same issue in 6.5.0. I have upgraded dozer from 5.1.0 to 6.5. Any pointers to overcome this issue

I've implemented a little bit complicated workaround:
/**
 * Custom Dozer Converter to be included in global configuration at runtime.
 */
public interface DozerCustomGlobalConverter extends CustomConverter
{
    CustomConverterDescription getDescription();
}

/**
 * Common logic for all dozer converters to be included in global configuration.
 */
public abstract class AbstractDozerCustomGlobalConverter<A,B> extends DozerConverter<A, B> implements DozerCustomGlobalConverter
{
    private final CustomConverterDescription description;

    /**
     * Defines two types, which will take part transformation.
     * As Dozer supports bi-directional mapping it is not known which of the classes is source and
     * which is destination. It will be decided in runtime.
     *
     * @param prototypeA type one
     * @param prototypeB type two
     */
    protected AbstractDozerCustomGlobalConverter(final Class<A> prototypeA, final Class<B> prototypeB, final Class<?> type)
    {
        super(prototypeA, prototypeB);
        CustomConverterDescription description = new CustomConverterDescription();
        description.setClassA(prototypeA);
        description.setClassB(prototypeB);
        description.setType(type);
        this.description = description;
    }

    @Override
    public CustomConverterDescription getDescription()
    {
        return description;
    }
}

Example converter

public class UserToLongConverter extends AbstractDozerCustomGlobalConverter<UserReference, Long>
{
    public UserToLongConverter()
    {
        super(UserReference.class, Long.class, UserToLongConverter.class);
    }

    @Override
    public Long convertTo(final UserReference version, final Long aLong)
    {
        return version.getId();
    }

    @Override
    public UserReference convertFrom(final Long aLong, final UserReference version)
    {
        UserReference service = new UserReference();
        service.setId(aLong);
        return service;
    }
}

And to get it all working, I've overridden Spring's DozerBeanMapperFactoryBean:
public class DozerMapperFactoryBean extends ApplicationObjectSupport implements InitializingBean, FactoryBean<Mapper>
{
    private static final Logger LOG = LoggerFactory.getLogger(DozerMapperFactoryBean.class);
    private static final String ERR_MSG = "Another implementation of dozer bean mapper. Consider factory bean refactoring.";

   ...
    private final List<DozerCustomGlobalConverter> customGlobalConverters = new ArrayList<>(0);
   ...

    @Override
    public void afterPropertiesSet() {
        ...
        Map<String, DozerCustomGlobalConverter> contextCustomGlobalConverters
                = getApplicationContext().getBeansOfType(DozerCustomGlobalConverter.class);

        customGlobalConverters.addAll(contextCustomGlobalConverters.values());
boolean customConvertersInjectedSuccessfully = false;
        Exception caughtException = null;

        try
        {
            if(mapper instanceof DozerBeanMapper)
            {
                Field globalConfigurationField = DozerBeanMapper.class.getDeclaredField(("globalConfiguration"));
                globalConfigurationField.setAccessible(true);
                Configuration globalConfiguration = (Configuration) globalConfigurationField.get(mapper);
                globalConfigurationField.setAccessible(false);
                for(DozerCustomGlobalConverter customGlobalConverter : customGlobalConverters)
                {
                    globalConfiguration.getCustomConverters().addConverter(customGlobalConverter.getDescription());
                }
                LOG.info("Loaded {} custom global dozer converters.", customGlobalConverters.size());
                customConvertersInjectedSuccessfully = true;
            }
        }
        catch(Exception e)
        {
            caughtException = e;
        }

        if(!customConvertersInjectedSuccessfully)
        {
            if(caughtException == null)
            {
                throw new IllegalStateException(ERR_MSG);
            }
            else
            {
                throw new IllegalStateException(ERR_MSG, caughtException);
            }
        }
    }


feat: add follow_redirects field to http processor

This allows users to disable the Go HTTP client's default behavior of transparently following 3XX status codes.
This came from a question in the community slack from a user that was trying to use the Location header of a response from the http processor.

Awesome! Extra points for updating the changelog 😎


[Bug Report] Drawer, a new component, has a small problem: the default value of the appendToBody attribute in the document is false, but the default value in the code is true, the modal-append-to-body attribute in the document is not working well, it seems that the props in the code is not received.

Element UI version
2.11.1
OS/Browsers version
Chrome 69.0.3497.92
Vue version
2.6.10
Reproduction Link
https://codepen.io/minions51390/pen/aepEpj
Steps to reproduce
点击按钮，设置modal-append-to-body属性为false后发现dom依然被append到了body里面，
这个链接里面我没有设置append-to-body属性，按照文档上说明append-to-body默认值为false，那么drawer的dom应该被append到class名为drawer-wrapper的div下面但是依旧被append到body下面。
What is Expected?
设置modal-append-to-body属性为false后，dom会被添加到Drawer 的父元素上。
不设置append-to-body属性，dom会被添加到Drawer 的父元素上。
What is actually happening?
modal-append-to-body属性好像没有生效。
不设置append-to-body属性，dom会被添加body上面。

The modal and modal-append-to-body attributes don't work.

@JeremyWuuuuu 看一下。

@ziyoung  Got it.

@Minions51390 @cuevven It's a bug, which will be fixed @ next release. I am so sorry for the bug.

@JeremyWuuuuu 辛苦修复，超喜欢elementUI，很棒很棒的组件库~

@Minions51390 感谢!

#16953
You can watch this PR to track the process.
PR 已提


Add backend support for anonymous voting

Backend part for #473.
After merging this PR new ANON_VOTE option is added and propagated to /config endpoint, and if it's true then anonymous users can cast votes.
As mentioned in README, VOTES_IP should be enabled at the same time to make these new options work.
I've tested it and it works as intended, however, is unavailable from UI without appropriate frontend changes.

Looking good, but it will be nice to have a test covering such a case.


Display Year on x-Axis

Lines Diagram : The x-axis "year" is displayed strangely (months between the years).
Example :

Although technically not wrong (time is continuous), I agree that this is confusing.
Implemenation note: we need to make use of the dimension's specified time interval. Alternatively, we can fall back on the datatype (if it's xsd:gYear or similar).

Btw. with dataKind we have a way to hint what we expect the granularity to be in the data, if set I propose to use it as an override.


PLNSRVCE-255 - sharedSecret for infra-deployments update

Instead of creating a secret in each service namespace, a shared secret is defined. (https://github.com/redhat-appstudio/infra-deployments/pull/350)
this PR adds the shared secret config to update-infra-deployments task, which can be used to update infra-deployments.

this should not merge until we merge https://github.com/redhat-appstudio/infra-deployments/pull/349 minimally
we quite possibly will want also gate this on our sorting out of the 3 minute delay wrt permission application for the pipeline SA that
@sbose78 @Michkov and I have been discussing in slack
let's see if
/hold
is set up for this repo

let's see if
/hold
is set up for this repo

does not look like it :-)

@gabemontero Sure, we could keep this on hold until the #349 is merged.


Bottom part of list visible with many enemies

When there are lots of enemies on screen, the last entries in the list can still be seen. Kobolds, who come in hordes, are particularly adept at this.
Some solutions I can think of:

Slide the list further up.
Make the list invisible after the sliding animation finishes, then visible again when the user wants to display it.
Slide left?

In general I think a more aproppriate place for the ui elements would be the botton left of the screen instead of the top left, with the list sliding down to hide and and up to show.

Oh thats weird, could you provide a save such an encounter?
Or maybe I can figure it out from the code

I've updated the latest release, please see if it helped

definitely looks fixed!


feat: Make idempotent on id

If a fixture contains an id field update the existing record if it exists, otherwise create.
This mirrors the behavior of the typeorm-fixtures-cli

Hi @mainstreet-droe, could you explain a little bit more why you need to update existing data using the fixtures ?
Basically we use it to load data on fresh clean DB so we don't need to push updates.
For updates I would rather implement a kind of load system so that we can load data from the DB and use it in the dataset like created ones.

The desire is in our preview and staging environment setups to run the fixture create with every deploy
I was attempting to make our fixtures idempotent so we could have the option of running the fixture create multiple times and have it not have to recreate the db every time. We use both prisma and typeorm in our code base (don't ask not my call) and the typeorm fixtures do this already so was trying to copy the functionality into prisma
Can you describe this load system a little more?

Changing directions internally so won't need this anymore. Closing


Error with Vitest when trying to import @resourge/shallow-clone

When trying to import a component that uses @resouge/react-form inside a test file, Vitest throws the following error:
SyntaxError: Named export 'shallowClone' not found. The requested module '@resourge/shallow-clone' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:
import pkg from '@resourge/shallow-clone';
const { shallowClone } = pkg;
Reproducible example: https://stackblitz.com/edit/vitejs-vite-de68ru?file=package.json,src%2FAppModel.ts,src%2FApp.tsx,tests%2Findex.test.tsx&terminal=dev
run:
npm run test

See error on Terminal.

Hi, thanks for bringing the error to my atencion.
Monday I will check it out and fix the problem. thanks

Hi, update @resourge/shallow-clone and @resourge/react-form to fix this problem. Thanks for the feedback.


chore(sci-fi): add more room and floors

Added floor-1 with room i.e. 1-A & 1-B & both rooms are extending to 2 sub rooms i.e. 1-A1 1-A2 and 1-B1 1-B2.
NOTE : 1-B1 and 1-B2 are under development.

Ok, I get it. I will take a look at requested changes.
Thanks.

Ya I get it. I will take a look at this. Thanks for the suggestions.

hello @ming-tsai, as per your suggested changes,
the ol(s) are changed to ul(s) and i have added WIP floor where work is in progress.

hello @ming-tsai, as per your suggested changes,
the ol(s) are changed to ul(s) and i have added WIP floor where work is in progress.

Hi @Manas-Tiwari,

Could you unify all WIP file?
You could create a dead line like this one

Yeah sure. I think that's a good idea.

hi ming, as you said, i have added a common WIP file along with a end-of-story file(dead link) wherever i felt the necessity.

thanks for merging. 👍🏽


Provide ability to duplicate a dashboard component

One often wants to duplicate a dashboard component like a query, a table or visualisation as it can be quite time consuming to replicate say a table within the same dashboard manually.

Available in 7.2


[Bug]: Long label of the widgets does not wrap when entered without spaces

Is there an existing issue for this?

[X] I have searched the existing issues

Description
Long label of the widgets does not wrap when entered without spaces found in Datepicker but present in some including Input, Select, Group widgets.
Steps To Reproduce

Drag and drop any widget with labels.
Enter a long text without spaces.
Set it to top align.
Enable Auto Height.
See that the label cuts at the right boundary.

Public Sample App
No response
Version
Cloud

Working fine with the given steps to reproduce, moving to done.


Store folder names in classes

Store folder names in classes instead of writing if/elif statements to make code shorter and easier to update & maintain.

If it works it works ¯_(ツ)_/¯


[Bug] Locale usage with Invoke-DbaDbDataMasking not taken into account after first run

Environmental information

#### PowerShell version:

Name                           Value
----                           -----
PSVersion                      5.1.14393.3053
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.14393.3053
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>

#### dbatools Module version:

Name    : dbatools
Path    : C:\PSRepo\dbatools\dbatools.psm1
Version : 1.0.38

LCID             Name             DisplayName
----             ----             -----------
1036             fr-FR            Français (France)

SQL Server:

Microsoft SQL Server 2016 (SP2-CU4) (KB4464106) - 13.0.5233.0 (X64)   Nov  3 2018 00:01:54   Copyright (c) Microsoft Corporation  Enterprise Edition: Core-based Licensing (64-bit) on Windows Server 2016 Standard 10.0 <X64> (Build 14393: ) (Hypervisor)

/* REPLACE WITH output of @@LANGUAGE */
Français

Report

Host used

[x] powershell.exe
[ ] ISE
[ ] VS Code
[ ] Other (please specify)

Errors Received

None
Steps to Reproduce

Invoke-DbaDbDataMasking -SqlInstance SERVER\INST_NAME -Database DB -FilePath C:\Temp\DataMaskingConfig.json -Confirm:$false -Locale it
=> you get masked italian email adresses / names
2nd run : I change Locale from it (Italy) to fr (France)
Invoke-DbaDbDataMasking -SqlInstance SERVER\INST_NAME -Database DB -FilePath C:\Temp\DataMaskingConfig.json -Confirm:$false -Locale fr
=> you still get masked italian email adresses / names instead of french ones
Expected Behavior

Getting french email adresses / names on 2nd run
Actual Behavior

Got italian email adresses / names instead of french ones on 2nd run
Workaround
Restart Powershell and run Invoke-DbaDbDataMasking -Locale fr at first run

but but... @sanderstad do you have time to work on this?


python3Packages.hstspreload: 2021.10.1 -> 2021.11.1

Motivation for this change
Update to latest upstream release 2021.11.1
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

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

2 packages built:

python38Packages.hstspreload
python39Packages.hstspreload


Arbitration: Decrypt Messages

Once a dispute is created, a buyer or seller should be able to initiate the decryption of any messages between the two parties for the benefit of the arbitrator/jurors.
Edit: This actually may happen entirely in -js and be triggered from some other explicit user action like "create dispute". Related: https://github.com/OriginProtocol/origin-js/issues/301

Resolved by https://github.com/OriginProtocol/origin-dapp/pull/507 ✅


Added BUILD.gn file for flutter_tools on Fuchsia.

/cc @jamesr

But Travis is mad.

Looks like a network error.  Retrying.


Fix sql crash

Fixes #72

Note that you based your changes on the develop branch but are requesting to merge those changes into master, making the merging of this PR also merge the other commit in develop that is not yet on master.

Fixed: all my PRs are now rebased against develop.
Trivial mistake, and trivial to fix since GitHub allows to edit the base of PR in WebUI.


Provide more detailed error text when resource is not found

Prerequisites

[X] Write a descriptive title.
[X] Make sure you are able to repro it on the latest released version
[X] Search the existing issues.

Steps to reproduce
I saw the GA notice go out (good job getting to GA) and tried to update to the latest and accidently forgot to prefix the module name so it was not found. This produced a generic error message that the module was unable to be installed but in reality it failed due to it not existing.
Please update the failed install error text to say why it failed (module not found, etc).
Install-PSResource PSResourceGet -PassThru

Untrusted repository
You are installing the modules from an untrusted repository. If you trust this repository, change its Trusted value by running the Set-PSResourceRepository cmdlet. Are you sure you want to install the
PSResource from 'PSGallery'?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "N"): y
Install-PSResource: Package(s) 'PSResourceGet' could not be installed from repository 'PSGallery'.

Expected behavior
# Module not found error text instead of generic error message

Actual behavior
# Generic error message

Error details
Exception             :
    Type    : Microsoft.PowerShell.PSResourceGet.UtilClasses.ResourceNotFoundException
    Message : Package(s) 'PSResourceGet' could not be installed from repository 'PSGallery'.
    HResult : -2146233088
TargetObject          : Microsoft.PowerShell.PSResourceGet.Cmdlets.InstallPSResource
CategoryInfo          : InvalidData: (Microsoft.PowerShel…s.InstallPSResource:InstallPSResource) [Install-PSResource], ResourceNotFoundException
FullyQualifiedErrorId : InstallPackageFailure,Microsoft.PowerShell.PSResourceGet.Cmdlets.InstallPSResource
InvocationInfo        :
    MyCommand        : Install-PSResource
    ScriptLineNumber : 1
    OffsetInLine     : 1
    HistoryId        : 1
    Line             : Install-PSResource PSResourceGet -PassThru
    Statement        : Install-PSResource PSResourceGet -PassThru
    PositionMessage  : At line:1 char:1
                       + Install-PSResource PSResourceGet -PassThru
                       + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    InvocationName   : Install-PSResource
    CommandOrigin    : Internal
ScriptStackTrace      : at <ScriptBlock>, <No file>: line 1
PipelineIterationInfo :

Environment data
1.0.0
7.4-preview6

Visuals
No response

Thanks @ThomasNieto


Due date from Voyager should be formatted in this repo

This is the method in VoyagerHelpers that modifies the due date to null if the due date is more than 30 days ago.
https://github.com/pulibrary/voyager_helpers/blob/753232f8dd732d991aa95eaa08b6b475c2839549/lib/voyager_helpers/liberator.rb#L699
This logic should live in marc_liberation, for ease of moving to Alma.

Closing as a duplicate of #794


Pod creation fails when name length exceeds 63 characters

Bug description
Pod creation fails when name length is above 63 characters due to service.istio.io/canonical-name label limitation.
Expected behavior
Pod name limits should adhere to k8s spec ( resource names up to 253 chars )
Steps to reproduce the bug
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: xxxxxxxcxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  namespace: istioenablednamespace
  # annotations:
  # sidecar.istio.io/inject: "false"
spec:
  containers:
    - args: ["/bin/sh"]
      image: busybox:1.28
      imagePullPolicy: IfNotPresent
      name: containername
      stdin: true
      stdinOnce: true
      tty: true
  restartPolicy: Never
EOF

The Pod "xxxxxxxcxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" is invalid: metadata.labels: Invalid value: "xxxxxxxcxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx": must be no more than 63 characters

audit logs:
{"op":"add","path":"/metadata/labels/service.istio.io~1canonical-name","value":"xxxxxxxcxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"}

Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
client version: 1.6.3
control plane version: 1.6.3
data plane version: 1.6.3
Server Version: version.Info{Major:"1", Minor:"16+", GitVersion:"v1.16.8-eks-e16311", GitCommit:"e163110a04dcb2f39c3325af96d019b4925419eb", GitTreeState:"clean", BuildDate:"2020-03-27T22:37:12Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}
How was Istio installed?
istioctl/operator
Environment where bug was observed (cloud vendor, OS, etc)
EKS ( 1.16.8 )

I ran into this as well with airflow worker pods.  For a workaround, I've assigned an app.kubernetes.io/name label to the workers after inspecting how the canonical-name label is assigned: https://github.com/istio/istio/blob/a70e4f93d8f6cf891a0b9b9284a35aa7e3f87dbb/pkg/kube/inject/webhook.go#L612 .

That's actually the same approach we decided on for now, also first encountered it with airflow workers and airflow initiated SparkApplication submissions

I ran into this as well with airflow worker pods. For a workaround, I've assigned an app.kubernetes.io/name label to the workers after inspecting how the canonical-name label is assigned:
https://github.com/istio/istio/blob/a70e4f93d8f6cf891a0b9b9284a35aa7e3f87dbb/pkg/kube/inject/webhook.go#L612
.

Thanks this, much appreciated, it resolved an issue for us when upgrading to Airflow 1.10.12 with pods requiring istio.

I ran into this as well with airflow worker pods

Hi, could you explain how did you run it?

@rodrigoabdo Sure, lets say you have some config like this
k = KubernetesPodOperator(namespace='default',
                          image="ubuntu:16.04",
                          cmds=["bash", "-cx"],
                          arguments=["echo", "10"],
                          labels={"foo": "bar"},
                          secrets=[secret_file, secret_env, secret_all_keys],
                          ports=[port]
                          volumes=[volume],
                          volume_mounts=[volume_mount]
                          name="test",
                          task_id="task",
                          affinity=affinity,
                          is_delete_operator_pod=True,
                          hostnetwork=False,
                          tolerations=tolerations,
                          configmaps=configmaps
                          )

The fix was simply to amend the labels section so it looks as follows:
 labels={"foo": "bar", "app.kubernetes.io/name": "some_name"},

That's what seemed to resolve it for us.

I imagine this has been fixed in a newer version of istio, despite being closed from being stale?


(vscode) Support version check

Description

Before trying to install/upgrade check version number
Motivation and Context

Avoid closing/reinstalling vscode if user is trying to upgrade all packages and vscode has properly already updated because of background downloader.
How Has this Been Tested?

Tested it with choco pack and cinst --source . vscode -y -f
Tried repacking it giving bogus vscode path and script proceeded to reinstalling.
Screenshot (if appropriate, usually isn't needed):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Migrated package (a package has been migrated from another repository)

Checklist:

[ ] My code follows the code style of this repository.
[ ] My change requires a change to documentation (this usually means the notes in the description of a package).
[ ] I have updated the documentation accordingly (this usually means the notes in the description of a package).
[ ] All files are up to date with the latest Contributing Guidelines
[ ] The added/modified package passed install/uninstall in the chocolatey test environment.
[x] The changes only affect a single package (not including meta package).

Original Location

Original Repository
Open Issues Add the different issues underneath, and tick those that are fixed in this PR

[ ] Issue 1 link
[ ] Issue 2 Link

[ ] Include the link to the opened PR that removes the package from the original location
[ ] The migration guidelines have been followed

:white_check_mark: Package verification completed without issues. PR is now pending human review

:white_check_mark: Package verification completed without issues. PR is now pending human review

I think  you could only (Get-UninstallRegistryKey 'Microsoft Visual Studio Code').DisplayVersion.

Oh interesting tip 👍

:white_check_mark: Package verification completed without issues. PR is now pending human review

:white_check_mark: Package verification completed without issues. PR is now pending human review


how can i save the model as same as your released lstm model?

https://blog.metaflow.fr/tensorflow-how-to-freeze-a-model-and-serve-it-with-a-python-api-d4f3596b3adc

Could you give me the (lstm,gray and rgb) model before released ,i want to continue training on the basis of your model

You can load these released files, and continue training. They just do not have intermediate gradients.

yes,i  had a try with your released files,but the error happened
NotFoundError (see above for traceback): Restoring from checkpoint failed. This is most likely due to a Variable name or other graph key that is missing from the checkpoint. Please ensure that you have not altered the graph expected based on the checkpoint. Original error:
Key Variable not found in checkpoint
[[Node: save/RestoreV2 = RestoreV2[dtypes=[DT_INT32, DT_FLOAT, DT_FLOAT, DT_FLOAT, DT_FLOAT, ..., DT_FLOAT, DT_FLOAT, DT_FLOAT, DT_FLOAT, DT_FLOAT], _device="/job:localhost/replica:0/task:0/device:CPU:0"](_arg_save/Const_0_0, save/RestoreV2/tensor_names, save/RestoreV2/shape_and_slices)]]

You can first do a random initialization, just like training from scratch.
Then you load our released model. And continue tranining
After that, I think you may get rid of these errors.

i can load my model successfully,but when load the released model the error happend.i used the following code .it's not ok in the stage of training .
    checkpoint_dir = './checkpoints/lstm'
    ckpt_name = 'deblur.model-523000'
    self.saver.restore(sess, os.path.join(checkpoint_dir, ckpt_name))     # error happened

thank you very much,the problem has been solved. the model i saved includes the gradients


Feat/add gemini insight option

Fixes #9
Changes made:

Adds enableGeminiInsights as an optional parameter in Fern client with default value to false
Modifies the required struct and adds the corresponding test case

Should we merge this?

@ANIRUDH-333 , I dont have write access to this repo so unable to merge this PR.
@mailprak could you help?

Resolved the conflicts. @mailprak can you please merge this?


Else branch with conditional let allows undefined variables

Minimal example:
if let <yes test> = none {
	print(test)
} else {
	print(test)
}

This causes a runtime error:
...
  File "...\N-lang\python\scope.py", line 162, in get_
variable
    raise NameError("You tried to get a variable/function `%s`, but it isn't def
ined." % name)
NameError: You tried to get a variable/function `test`, but it isn't defined.

I suspect that the type checker uses the same scope for both the if and else branch, so the variables bound by the conditional let seem to be available in the else branch by the type checker.

Hmm, sounds like we just... separate the scopes

probably

Fixed as of PR #86


DL: Add model_arch column to model data table

JIRA: MADLIB-1347
This PR adds the 'model_arch' column to the model data table so that
predict and evaluate can directly get the model_arch from the model data
table instead of the model arch table.
We have made changes to the predict code in this commit but the changes
for evaluate will be done in a future PR.
Co-authored-by: Nikhil Kak<EMAIL_ADDRESS>

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/madlib-pr-build/916/

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/madlib-pr-build/920/


What would be the best way to bind a controller which does not have to be called from the widget

I have a widget that needs to trigger an audio fragment every 5 seconds.
class TheGroupNotificationView extends StatefulWidget {
  static AudioCache player = new AudioCache();
  static const alarmAudioPath = "audio/alerts/beep.wav";

  TheGroupNotificationView();

  @override
  _TheGroupNotificationViewState createState() => _TheGroupNotificationViewState();
}

class _TheGroupNotificationViewState extends State<TheGroupNotificationView> {
  Timer timer;

  @override
  void initState() {
    super.initState();
    _onTick();
    timer = Timer.periodic(Duration(seconds: 5), (Timer t) => _onTick());
  }

  void _onTick() {
    TheGroupNotificationView.player.play(TheGroupNotificationView.alarmAudioPath);
  }

  @override
  void dispose() {
    timer?.cancel();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return Text('the build method doesnt matter');
  }
}

The timer needs to be disposed when the widget is disposed. How would I make this statefull widget into a stateless widget by using a GetController or a RxController?
Since this has nothing to do with building the widget, and needs to be bound to the widgets lifetime. I have no clue how to do this. So it's mostly about the timer, not so much about the audio.

You can use simples as that
class TimerController extends RxController {
  static AudioCache player = new AudioCache();
  static const alarmAudioPath = "audio/alerts/beep.wav";

  @override
  void onInit() {
    super.onInit();
    _onTick();
    timer = Timer.periodic(Duration(seconds: 5), (Timer t) => _onTick());
  }

  void _onTick() {
    TheGroupNotificationView.player.play(
      TheGroupNotificationView.alarmAudioPath,
    );
  }

  @override
  void onClose() {
    timer?.cancel();
    super.dispose();
  }
}

The RxController has lifetime methods too.
When o call this RxController, the onInit will be called and when the controller is no longer needed the onClose will be called. (There is more life time methods)
So you can create a RxController like that and use in your widget or whatever you want (in the man you can use too

@Katekko answered your question.
Read about the lifecycle of controllers in the documentation, onInit and onClose can most often replace initState and dispose.
As it is a support question, already answered, I am closing this.

I'll move these type of questions to stackoverflow. My b.
But just to be clear it was not about how to make the controller but on how to put it.


[QUESTION] Cross-region logs in a single Sink

hello everyone, and thanks for sharing this solution.
while reading this repository readme and the doc page CloudWatch Unified Cross Account
one question is still not answered clearly:
Q: cross-account cross-region logs to a single-account single-region is still not possible out of the box?
my understanding of OAM Sink and Link is that they are bound to a single region, correct?
isn't possible to create a Sink (us-east-1) and Link multiple regions (ap-southeast-2, eu-west-2) to the same Sink (us-east-1)?

Yes that's right. The Sink and Link have to be in same region. I'm adding this as part of Limitations section.

Users can still do cross-account and cross-region Observability from central Monitoring account. Please see this documentation for  cross-account and cross-region monitoring.
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Cross-Account-Cross-Region.html

thank you so much for answering @pmvrak 💪
the link you provided states in the beginning:
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Cross-Account-Cross-Region.html

CloudWatch also offers a cross-account, cross-Region CloudWatch dashboard. This functionality provides you with cross-account visibility to your dashboards, alarms, metrics, and automatic dashboards. It does not provide cross-account visibility for logs or for traces.

Logs are not included in this cross-account cross-region solution from CloudWatch.

Sink+Link are bounded by region and you can have only a single Sink per account
Logs aren't included in the Cross-account cross-Region CloudWatch console (from the link above).

This results in me still being required to export logs with CloudWatch Destination + Kinesis Stream and centralize them in a single-region in a Monitoring Account. This diagram illustrates what I'm doing at the moment:

From the Monitoring account above, I can access the alarms, metrics, and automatic dashboards via cross-account sharing (the link you shared), but the logs I need to manually forward them to the monitoring account single-region.

Hi Eduardo, yes thats the right approach. Nice architecture diagram and flow. Also on a side note an would also suggest to look at this OpenSearch solution which can be better suited as well as well which uses OpenSearch for central processing of your logs. So its can be a combination of OAM plus the Centralized logging solution using OpenSearch together?

Just wanted to confirm something, if anyone sees this:

Sink+Link are bounded by region and you can have only a single Sink per account

This no longer seems to be the case in practice. It appears that you can now have a single sink aggregate data across many source accounts from multiple regions, which you can then link by doing, for example:
aws oam link --sink-arn arn:aws:oam:region:account-id:sink/sink-name --source-account-id<PHONE_NUMBER>33 --source-regions us-east-1,us-west-2

Notice the sink name (which can be shared across regions in the monitoring account, regardless of sink ARN) and source- regions

Can anyone confirm if this is true at scale? The documentation still seems to suggest you can only have 1 sink per region, but it clearly looks to be incorrect. Not sure if I'm misunderstanding something.
I also asked Amazon Q about this, and got the following:
It is possible to have a CloudWatch Observability Access Manager sink in multiple regions for a single account. When creating the sink, you can associate it with one or more regions in that account. The sink will then aggregate data from all of the linked regions.
Some key points:

A single sink can be linked to all supported regions in the target/monitoring account.
The same sink name must be configured in each source region that will send data to the sink.
All observability data, including metrics, logs and traces, will be centrally available in the monitoring account regardless of which regions it originated from.

This allows monitoring an application that spans regions from a single consolidated view without having to worry about regional boundaries.
Try it out yourself, seems to be legit, but would love official confirmation.

@sweldon could you confirm which API you are trying to use?
the AWS OAM CLI do'nt have a aws oam link command:
https://awscli.amazonaws.com/v2/documentation/api/latest/reference/oam/index.html
The create-link command (from the documentation link above), only accepts a single region:
  create-link
--label-template <value>
--resource-types <value>
--sink-identifier <value>
[--tags <value>]
[--cli-input-json | --cli-input-yaml]
[--generate-cli-skeleton <value>]
[--debug]
[--endpoint-url <value>]
[--no-verify-ssl]
[--no-paginate]
[--output <value>]
[--query <value>]
[--profile <value>]
[--region <value>]
[--version <value>]
[--color <value>]
[--no-sign-request]
[--ca-bundle <value>]
[--cli-read-timeout <value>]
[--cli-connect-timeout <value>]
[--cli-binary-format <value>]
[--no-cli-pager]
[--cli-auto-prompt]
[--no-cli-auto-prompt]

following the current v2 API definitions, the quote:

Sink+Link are bounded by region and you can have only a single Sink per account

is still the current behaviour of OAM

that said, in Jan 2024, CloudWatch Logs released the "account level subscription filter":
https://aws.amazon.com/about-aws/whats-new/2024/01/amazon-cloudwatch-logs-account-level-subscription-filter/
https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SubscriptionFilters-AccountLevel.html
with that, you can have a single subscription in your account to send logs to the centralized account (no need for multiple sinks anymore)
i wrote a guide about it on:
CloudWatch Strategies for Cross-Account and Cross-Region Log Aggregation
https://blog.awsfundamentals.com/cloudwatch-logs-strategies-for-cross-account-and-cross-region-aggregation

HI @oieduardorabelo, thank you for the reply! Apologies I used the wrong CLI example there (Amazon Q led me astray), but regardless, I just confirmed that I was able to create 2 sinks in 1 account, 1 in us-east-1, and 1 in us-east-2. I was then able to create links to both of those sinks from an account, in the respective regions. Am i misunderstanding this? Are these actually one sink, just bounded by region? They have different ARNs, so I wouldnt think that would be the case. For my use case, I am OK with switching between regions in the global monitoring account, but just want to confirm the "one sink per account" concept here.
Monitoring Account, 2 sinks in 2 regions
➜  ~ aws oam list-sinks --region us-east-1
{
    "Items": [
        {
            "Arn": "arn:aws:oam:us-east-1:<accountid>:sink/<sinkid>",
            "Id": "<sinkid>",
            "Name": "observabilitySink"
        }
    ]
}

➜  ~ aws oam list-sinks --region us-west-2
{
    "Items": [
        {
            "Arn": "arn:aws:oam:us-west-2:<accountid>:sink/<sinkid>",
            "Id": "<sinkid>",
            "Name": "observabilitySinkUsWest2"
        }
    ]
}

Source Account, linked to 2 regional sinks in the same monitoring account
➜  scripts aws oam list-links --region us-east-1
{
    "Items": [
        {
            "Arn": "arn:aws:oam:us-east-1:<sourceaccountid>:link/<linkid>",
            "Id": "<linkid>",
            "Label": "<label>",
            "ResourceTypes": [
                "AWS::ApplicationInsights::Application",
                "AWS::Logs::LogGroup",
                "AWS::CloudWatch::Metric",
                "AWS::XRay::Trace"
            ],
            "SinkArn": "arn:aws:oam:us-east-1:<monitoringaccountid>:sink/<sinkid-us-east-1>"
        }
    ]
}

➜  scripts aws oam list-links --region us-west-2
{
    "Items": [
        {
            "Arn": "arn:aws:oam:us-west-2:<sourceaccountid>:link/<linkid>"",
            "Id": "<linkid>"",
            "Label": "test-link-us-west-2",
            "ResourceTypes": [
                "AWS::Logs::LogGroup"
            ],
            "SinkArn": "arn:aws:oam:us-west-2:<monitoringaccountid>:sink/<sinkid-us-west-2>"
        }
    ]
}

Thank you again for the awesome links provided, excellent and very informative blog post. Much appreciated.

@sweldon holy shit man, yes, it does work!! 🤯
i tested in multiple independent AWS accounts and with a new AWS Organization
the centralized monitoring account can have:

1 Sink per Region (not per account as described in the documentation)
We can create a Sink in us-east-1, ap-southeast-2, eu-west-1 etc

this pattern is now possible with Sink+Link:

not sure if that is a bug, but it does work 😄
i can even use log insights across accounts for the same region, in the monitoring account:

i still need to test the limits in the source account, as described in:
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_limits.html

OAM source account links
Each source account can be linked to as many as 5 monitoring accounts
This quota can't be changed.

If this quota still applies in the account level, it means we can only connect 5 regions of the 33 regions aws have
but for the monitoring account, now we can aggregate cloudwatch metrics, logs, traces and application insights 🥳
with everything in the same account, we can create cross-region dashboards in the monitoring account to have an overview across regions
fantastic discovery!

@oieduardorabelo 👏 👏 👏  Glad I could help and thanks for the confirmation! Quick follow-up:

Each source account can be linked to as many as 5 monitoring accounts
...
If this quota still applies in the account level, it means we can only connect 5 regions of the 33 regions aws have

Couldn't you still link all 33 regions to their respective regional sinks in 1 monitoring account? It doesn't appear that accounts are limited to linking to 5 sinks, but 5 accounts as a whole. So i feel like 1 monitoring account is enough to service all regions for all of your source accounts, correct?
Also just wanted to let you know that there is a small typo in the new diagram, top right orange "cross-account eu-west-1 aggregation" should be "ap-southeast-2" I think 😃


Non-pinned Versions for Supporting Libraries

Is your feature request related to a problem? Please describe.
Since many folks will use this library in conjunction with other Python libraries, it is best practice to not pin exact versions but to instead try to allow for a certain base version we have tested with and up. This allows folks to deploy Cape in places where they might need or use a higher or lower library version than the one we normally use.
Describe the solution you'd like
It would be nice to figure out some lower level requirements and use the >= in the requirements file so folks can have variance in their versions. This would also solve our deployment issue on CoLab! We should then also add a call for folks to report any bugs they find with newly released versions of libraries.
Describe alternatives you've considered
We can continue to pin versions and this will be okay for folks that don't have a lot of other Python libraries installed and running.
Additional context
This came in as a feature request from a recent user interview and from my own use of Cape Python on GCP!

Follow ups are:

@kjam to check at what versions we need for CoLab
@bendecoste found ability to pin to minor versions and up without having the next major version do a breaking change. https://stackoverflow.com/questions/8795617/how-to-pip-install-a-package-with-min-and-max-version-range

Maybe this isn't quite closed up yet. Need some investigation into the colab versions needed.


RateLimitFilter - enhance exposeHeaders to support "ietf rate limit h…

smaller PR from #767 .
comply draft-ietf-httpapi-ratelimit-headers. enhance exposeHeaders parameter, true to output rate limit header fields.
update testcase.

Thanks for the PR. I have applied a modified version to 12.0.x, 11.0.x, 10.1.x and 9.0.x.


feat: generalize all app sync integration hooks

#113 was not merged into the right branch. Recreating to merge again.

Was approved in #113 , only change here was a rebase on main (dep upgrades)


How does Karma config section for systemjs overlay/interract with the systemjs.config file used for loading an app?

Can you help me understand how the karma.con.jsf:: systemjs object relates to the system.config.js::System.config({}) object ?
The karma.config::system.js object references the system.config.js file:
karma.config.js
module.exports = function (config) {
    basePath: projectRoot,
    urlRoot: '',
    hostname: 'localhost',
    frameworks: [ ...],
    plugins: [...],
    files: [],
    systemjs: {                             // <---
        configFile: 'system.config.js',     // <---
        files: [...  ],
        config: {
            transpiler: 'traceur',
            baseUrl: '/',
            paths: {                          // <---
                'asset':  'location'          // <---
                ...
            }
        }
        testFileSuffix: '.spec.js'
    },
    preprocessors: { ... },
    reporters: [...],
    browsers: [...]
    port: 9876,
    runnerPort: 9100
}

system.config.js
System.config({
    baseURL: '/', //relative to index.html location
    paths: {                                 // <---
         'asset':  'location'               // <---
    },
    meta: { ... },
    map: { ... }
});

They both have baseUrl and paths objects for denoting location of dependencies.  Does the karma config object override the system.config.js settings?
I have configured the system.config.js to locate my dependencies within a deployable build folder.
I would like to have the karma systemjs settings look for those same dependencies in their 'natural habitat' whether that be bower_components or node_modules.  This way the unit/integration tests can run against the raw source files, while the e2e and manual testing would run against the pre-compiled app in the build folder.  This would be ideal.  Is this possible?
Lastly, if you have time, I would welcome a discussion about project structures and efficiency.  I am trying to find a structure that will work well for today and migrate easily for tomorrow (When ES6 and Angular 2.0 are mainstream).
Thanks,
Kendrick

Values are merged 'from' the config defined in "systemjs.configFile" (ie. system.config.js) into the config defined in "systemjs.config".
Any properties that already exist in "systemjs.config" are maintained.
"paths", "map", and "meta" go through the same process.
You can see the code here - it's pretty simple:
https://github.com/rolaveric/karma-systemjs/blob/master/lib/index.js#L46-L62
So what you're asking for is definitely possible - I reuse the same "system.config.js" for dev, testing, and bundling.  I only make minor tweaks for testing (eg. Include angular-mocks) and bundling (eg. Set baseURL to './', since it's looking at the file system).
As for project structure... my advice would be to leverage SystemJS as much as possible.
For instance, I used to use the 'gulp-angular-templatecache' plugin to read my HTML templates and load them into an angular module that then loads them into $templateCache.
Now I just use the 'text' plugin for SystemJS, and pass that variable directly to 'template' rather than 'templateUrl' in my routes and directives.
Take that, plus built in minification and sourcemaps: I've just killed off something like 5 gulp plugins that I would have had to pipe together.
In this case I'm also only including what I KNOW is being used.

Ok, so system.config.js is merged with karma.conf.js::systemjs{}, with the settings in system.config.js taking precedence (overwriting any identical settings in karma.conf.js).
With this then how do you run the tests in a different layout than their native runtime?
What I mean is;

for dev time I want to run tests against the pre-compiled src files accessing the library dependencies directly from node_modules and bower_components.

For localhost server and e2e tests I want to host the compiled app in a build folder with all assets and dependencies collected locally, hence systemjs would be looking in the local /js/lib folder, not in the bower_components or npm_modules folders.

For production I want a deployable asset, either a zip of the minified build folder, or a minified bundle of all assets in the build folder.  The paths would probably be similar to the locahost folder, only referenced as such from within the bundle.

In each of the 3 cases the location of the assets and dependencies changes (btw 2 & 3 the change is from loose-leaf to minified bundle).  The Biggest difference is having Karma-systemjs pre-compile all my source files, along with tests, and execute the tests from memory rather than having to compile them to disk and then load them back in from disk.
I am getting confused on the precedence of the various path settings:

basePath
baseURL
urlRoot

It seems that if I want to import my modules without using long relative paths: i.e.
import app from '../../../app.module'
rather than
import app from 'client/src/app/modules/app.module'
I need to have a root that I can start from that is common in all 3 environments (test, build, prod).  I was trying to use the client/src/modules folder for this.  With this I can have a nested controller or directive that depends on something in a cousin folder, by starting the path at modules I can walk in from there, and if the path is relative local just use the import ./folder/file  import format.

with the settings in system.config.js taking precedence
No, it's the reverse.  system.config.js properties are only copied into karma.conf.js:systemjs.config if that property does not already exist.
I am getting confused on the precedence of the various path settings:
If I'm reading the Karma source code correctly, the basePath is where the HTTP server sets it's base/ folder from.  And if you try to include a file which isn't inside that folder (eg. ../someFile.js), it goes under absolute/.
baseURL is what SystemJS uses for all module names that aren't: a) Already found in map or paths in system.config.js, or b) Start with ./ or ../ which are relative to the current module.
urlRoot lets you change the root path for Karma in the browser. eg. You could set it to "/karma/" and you'd find your files under "/karma/base/".
It's only useful in very specific circumstances. I'd leave it as "/".
I need to have a root that I can start from that is common in all 3 environments...
Well under normal circumstances, you're going to need to reference 3 types of modules: source code, unit tests, and third-party libraries.
So your baseURL needs to encompass all 3 of these unless you reference them in the map or paths of your system.config.js with absolute paths.
eg. You may use map for third-party libraries because you expect to use a CDN, or just don't want to write import 'node_modules/lodash/lodash.js' 500 times.
I tend to stick to "/" for the baseURL, change the System.import(mainModule) according to the environment, use relative module names (ie. Start with ./ or ../) for everything that's going to stay in the same relative structure, and use map for everything else (eg. third party libraries, files created at build time, etc.).

@rolaveric I have found another issue with the merge behavior of dependencies.  This is a snippet from our karma config.systemjs.config
                meta: {
                    // HACK: should be:
                    // 'ud.videojs-ready': { deps: [] }
                    // but the merge function is treating deps as an object and merging the
                    // dependencies instead of clobbering
                    'ud.videojs-ready': { deps: "angular" }
                }

@newduke Hmmm, I'm not sure what's the best solution for that.
I suppose we normally want to merge objects - adding or overwriting property values.
Arrays are few and far between.  According to SystemJS docs, only bundles, depCache, and meta.deps.
So it should be fair to say that objects are merged and arrays get clobbered, so something like this for Line 153:
_.merge(kConfig, kSystemjsConfig.config, function(objectValue, sourceValue) {
  if (_.isArray(sourceValue)) {
    return sourceValue;
  }
});

Does that work for you?

@rolaveric That works for me.  Thanks for the fix!

Don't thank me yet - I still need to implement it.


Not getting 410 even days after deleting the app

I am not getting 410 status from apns from the past several days and yet haven't succeeded.
Wherein I am able to get 400 for the wrong token.
Also, I tried both development as well as production environment (via TestFlight).
I am using Aws lambda function as my backend and iOS 13.
Here is code.
const apn = require('apn');
exports.handler = async (event) => {

let optionsAPNS = {
    token: {
         key: "./AuthKey_T********5.p8",
         keyId: "T********5",
         teamId: "N*********A"
       },
       production: true
     };

 let apnProvider = new apn.Provider(optionsAPNS);

 let body = event['body'] ? JSON.parse(event['body']) :
 {deviceToken:"94b2f7a2f0c1b158edb2835ccd316592d5d8945892d2b13de143cb4198269d11"};
 let deviceToken = body.deviceToken;

    var note = new apn.Notification();
    note.topic = "my-bundle-id";
    note.contentAvailable = 1;
    note.sound = "";
    note.pushType = 'background';

    const resdultData =  await apnProvider.send(note, deviceToken);

    let response = {
            "statusCode": 200,
            "headers": {},
            "body": JSON.stringify(resdultData),
            //"body": r,
            "isBase64Encoded": false
        };

    return response;
  };

Please suggest what am I doing wrong or how can I get 410

Hi.
I'm also struggling with the same issue. I'm currently testing with 2-3 days old invalid tokens and haven't been able to get any errors back. Would expect to see 410 error at some point.
There are apparently two interfaces for Apple APN push available; the new HTTP/2 interface, and a legacy binary interface. Can someone verify which one is used by node-apn? For the legacy binary interface additional "feedback service" is apparently needed to get those errors. But this should be somehow already supported by node-apn as the wiki says. Is there something a developer needs to do specifically to enable the feedback service?
Thanks for any information on this.

I am trying to figure out when to delete the VOIP tokens. It seems like when getting 410 is the right time to delete the existing voip tokens in our server. But it seems we are not getting that error code. Is there a problem with the library?


add .prettierrc or linter

Please add a prettierrc or a linter or any conf you want so IDEs can follow the maintainers configuration

Thank you! Good QOL improvement.


Add support for fixture arrays.

This patch adds support for arrays:
$ fony -t '{"tags": ["word", 3]}'
{
  "tags": [
    "oklu",
    "odikabi",
    "coan"
  ]
}

I used the ["<chanceType>", <count>] format, but if you have a better idea I take it.

This is an awesome addition. Thanks @n1k0!


OnlySameNamespace defautling to true needs to be reconsidered

Currently inside the RouteNamespaces struct is as follows:
// RouteNamespaces indicate which namespaces Routes should be selected from.
type RouteNamespaces struct {
	// NamespaceSelector is a selector of namespaces that Routes should be
	// selected from. This is a standard Kubernetes LabelSelector, a label query
	// over a set of resources. The result of matchLabels and matchExpressions
	// are ANDed. Controllers must not support Routes in namespaces outside this
	// selector.
	//
	// An empty selector (default) indicates that Routes in any namespace can be
	// selected.
	//
	// The OnlySameNamespace field takes precedence over this field. This
	// selector will only take effect when OnlySameNamespace is false.
	//
	// Support: Core
	//
	// +optional
	NamespaceSelector metav1.LabelSelector `json:"namespaceSelector,omitempty"`

	// OnlySameNamespace is a boolean used to indicate if Route references are
	// limited to the same Namespace as the Gateway. When true, only Routes
	// within the same Namespace as the Gateway should be selected.
	//
	// This field takes precedence over the NamespaceSelector field. That
	// selector should only take effect when this field is set to false.
	//
	// Support: Core
	//
	// +kubebuilder:default=true
	OnlySameNamespace *bool `json:"onlySameNamespace,omitempty"`
}

Currently this is in GatewayClass but is being moved to Gateway with #285.
The problem here is that we are resorting to true by default design with OnlySameNamespace being. True by default is usually not the most friendly API for the end user.
We should reconsider and make sure if we really want to do this.

/cc @robscott @jpeach @bowei @danehans

The problem here is that we are resorting to true by default design with OnlySameNamespace being. True by default is usually not the most friendly API for the end user.

One of these fields has to be set. I don't know that there is a reasonable default for NamespaceSelector, so OnlySameNamespace has to be defaulted.
However, maybe we should default this at the usage site rather than in the type itself?


Axel has been upgraded to version 2.17.10, but SSL is still reporting an error Initializing download: https://universal-setup.ams3.digitaloceanspaces.com/setup_2^20.key SSL error: certificate verify failed (null) Error: Child process exited with code 1

Axel has been upgraded to version 2.17.10, but SSL is still reporting an error
Initializing download: https://universal-setup.ams3.digitaloceanspaces.com/setup_2^20.key
SSL error: certificate verify failed
(null)
Error: Child process exited with code 1

What happens if you have to open corresponding url (https://universal-setup.ams3.digitaloceanspaces.com/setup_2%5E20.key) with your browser? Can you download the file from there?

What happens if you have to open corresponding url (https://universal-setup.ams3.digitaloceanspaces.com/setup_2%5E20.key) with your browser? Can you download the file from there?

Yes, I can download files from this URL

Yes, I can download files from this URL

如果必须使用浏览器打开相应的URL（https://universal-setup.ams3.digitaloceanspaces.com/setup_2^20.key），会发生什么情况？您可以从那里下载文件吗？

Yes, I can download files from this URL

如果必须使用浏览器打开相应的URL（https://universal-setup.ams3.digitaloceanspaces.com/setup_2^20.key），会发生什么情况？您可以从那里下载文件吗？

Yes, I can download files from this URL

And if you run axel manually from the command line, can you download any file from other https hosts?

And if you run axel manually from the command line, can you download any file from other https hosts?

并且，如果您从命令行手动运行axel，可以从其他https主机下载任何文件吗？
No, this will cause an error:
root@ubuntu02:~/wz# axel -n 1 https://universal-setup.ams3.digitaloceanspaces.com/setup_2^20.key
Initializing download: https://universal-setup.ams3.digitaloceanspaces.com/setup_2^20.key
SSL error: certificate verify failed
(null)

并且，如果您从命令行手动运行axel，可以从其他https主机下载任何文件吗？
No, this will cause an error:
root@ubuntu02:~/wz# axel -n 1 https://universal-setup.ams3.digitaloceanspaces.com/setup_2^20.key
Initializing download: https://universal-setup.ams3.digitaloceanspaces.com/setup_2^20.key
SSL error: certificate verify failed
(null)

And if you run axel manually from the command line, can you download any file from other https hosts?

The same error will be reported when downloading other HTTPS files using Axel. It should be the problem of downloading and installing Axel, I use Ubuntu system, I need to check again why there is such error, please let me know if you have a solution for this part. Thank you for your

And if you run axel manually from the command line, can you download any file from other https hosts?

The same error will be reported when downloading other HTTPS files using Axel. It should be the problem of downloading and installing Axel, I use Ubuntu system, I need to check again why there is such error, please let me know if you have a solution for this part. Thank you for your

并且，如果您从命令行手动运行axel，可以从其他https主机下载任何文件吗？

The highest version of apt-get in Ubuntu is 2.17.5, but 2.17.10 is not available. I used Axel 2.17.10 on the CentOS system for the installation. If that doesn't work is there no other way****

并且，如果您从命令行手动运行axel，可以从其他https主机下载任何文件吗？

The highest version of apt-get in Ubuntu is 2.17.5, but 2.17.10 is not available. I used Axel 2.17.10 on the CentOS system for the installation. If that doesn't work is there no other way****

并且，如果您从命令行手动运行axel，可以从其他https主机下载任何文件吗？

The highest version of apt-get in Ubuntu is 2.17.5, but 2.17.10 is not available. I used Axel 2.17.10 on the CentOS system for the installation. If that doesn't work is there no other way？

并且，如果您从命令行手动运行axel，可以从其他https主机下载任何文件吗？

The highest version of apt-get in Ubuntu is 2.17.5, but 2.17.10 is not available. I used Axel 2.17.10 on the CentOS system for the installation. If that doesn't work is there no other way？

并且，如果您从命令行手动运行axel，可以从其他https主机下载任何文件吗？
不，这将导致错误：
root @ ubuntu02：〜/ wz＃axel -n 1 https：//universal-setup.ams3。 digitaloceanspaces.com/setup_2%5E20.key
初始化下载：https : //universal-setup.ams3.digitaloceanspaces.com/setup_2%5E20.key
SSL错误：证书验证失败
（空）

并且，如果您从命令行手动运行axel，可以从其他https主机下载任何文件吗？

The highest version of apt-get in Ubuntu is 2.17.5, but 2.17.10 is not available. I used Axel 2.17.10 on the CentOS system for the installation. If that doesn't work is there no other way

并且，如果您从命令行手动运行axel，可以从其他https主机下载任何文件吗？
不，这将导致错误：
root @ ubuntu02：〜/ wz＃axel -n 1 https：//universal-setup.ams3。 digitaloceanspaces.com/setup_2%5E20.key
初始化下载：https : //universal-setup.ams3.digitaloceanspaces.com/setup_2%5E20.key
SSL错误：证书验证失败
（空）

并且，如果您从命令行手动运行axel，可以从其他https主机下载任何文件吗？

The highest version of apt-get in Ubuntu is 2.17.5, but 2.17.10 is not available. I used Axel 2.17.10 on the CentOS system for the installation. If that doesn't work is there no other way

并且，如果您从命令行手动运行axel，可以从其他https主机下载任何文件吗？

The maximum version of apt-get axel on Ubuntu is 2.4, and the maximum version of apt-get axel installed with source code is 2.17.5. I use version 2.17.10 of CentOS for installation, if this does not work, there is no other way? Can only build ZKSync using CentOS?

并且，如果您从命令行手动运行axel，可以从其他https主机下载任何文件吗？

The maximum version of apt-get axel on Ubuntu is 2.4, and the maximum version of apt-get axel installed with source code is 2.17.5. I use version 2.17.10 of CentOS for installation, if this does not work, there is no other way? Can only build ZKSync using CentOS?

Personally I use 2.17.5 and it works for me, however 2.17.10 is recommended due to some problems observed with earlier versions.
On ubuntu you can build the latest axel version from source if required.
You may also google for your problem with axel, maybe it's something common and can be fixed easily.

Personally I use 2.17.5 and it works for me, however 2.17.10 is recommended due to some problems observed with earlier versions.
On ubuntu you can build the latest axel version from source if required.
You may also google for your problem with axel, maybe it's something common and can be fixed easily.


[proposal]: implement a method that could create a sub-range proof from the existing Proof

The current implementation of Proof allows to prove the inclusion of leaves only within the boundaries which were used during proof creation. In case we need a smaller proof for the same row, we have to traverse the tree and collect subtree roots again. But in fact, having proof and leafHashes are enough to recompute the new proof in place, without tree traversing.
Having a row that contains 8 shares(leaves), where the first 6 shares have the same namespace.ID:
+-----+-----+-----+-----+-----+-----+-----+-----+
| s0  | s1  | s2  | s3  | s4  | s5  | s6  | s7  |
+-----+-----+-----+-----+-----+-----+-----+-----+

Proof for this row will be:
Proof {
  start = 0
  end = 6
  nodes = [][]byte {subtreeRoot([s6;s7]}
}

At some point we need the proof for [s2;s4), so instead of traversing the tree and getting proof for these indexes, we can recompute using existing proof.
	//
	//                                        Node0_8                                  Tree Root
	//                            /                            \
	//                        /                                 \
	//                  Node0_4                             Node4_8                    Non-Leaf Node
	//               /            \                     /                \
	//             /                \                 /                    \
	//       Node0_2             Node2_4         Node4_6              Node6_8          Non-Leaf Node
	//      /      \            /     \           /    \               /     \
	// Node0_1   Node1_2   Node2_3  Node3_4   Node4_5  Node5_6  Node6_7   Node7_8      Leaf Hash
	//     1         2          3        4       6       7           8        9        Leaf namespace
	//     0         1          2        3       4       5           6        7        Leaf index

If we'll take a look at this picture, to prove [s2;s4), we would need Node0_2(we can compute it by hashing s0 and s1), Node4_6(we can compute it by hashing s4 and s5) and Node6_8(already have it in proof.nodes).
This feature will be very helpful for blob service v0.1(cc @nashqueue), where we can have multiple blobs per namespace within the row, but the final indexes for the proof we can have only after fetching and verifying shares.

@vgonkivs  As discussed previously, the idea of extracting proofs for smaller ranges from namespace proofs for larger ranges makes sense to me. 👍


erroro in logs

https://curation.pombase.org/dumps/latest_build/logs/log.2018-05-24-22-57-12.manual-1-1-orths-output
can't find feature in Chado for SPAC1D4.09
the gene is SPAC1D4.09c
but I don't know where SPAC1D4.09 has been used?

It's in pombe-embl/orthologs/conserved_one_to_one.txt:
SPAC1D4.09    RTF2

wow OK, that must be a new error check! I haven't edited that file for ages? (or I forgot!)

fixed. I clearly had changed it recently, it was the first line!


fishPlugins.fzf-fish: 9.2 -> 9.5

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/fishplugin-fzf.fish/versions.
meta.description for fishPlugins.fzf-fish is: "Augment your fish command line with fzf key bindings"
meta.homepage for fishPlugins.fzf-fish is: "https://github.com/PatrickF1/fzf.fish"
meta.changelog for fishPlugins.fzf-fish is: ""
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 9.3 in filename of file in /nix/store/a4gnbplgm0vhxln620yagcj0by04p9gz-fishplugin-fzf.fish-9.3

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
fishPlugins.fzf-fish

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/a4gnbplgm0vhxln620yagcj0by04p9gz-fishplugin-fzf.fish-9.3 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

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

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/a4gnbplgm0vhxln620yagcj0by04p9gz-fishplugin-fzf.fish-9.3
ls -la /nix/store/a4gnbplgm0vhxln620yagcj0by04p9gz-fishplugin-fzf.fish-9.3/bin

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

1 package built:

fishPlugins.fzf-fish

Maintainer pings
cc @pacien for testing.

Failed on darwin (and prev 9.2):
$ nix build .#fishPlugins.fzf-fish
...
error: builder for '/nix/store/pc8m42rgz4iwhq62wk0fprhwfvr82m5d-fishplugin-fzf.fish-9.3.drv' failed with exit code 15;
       last 10 log lines:
       > configuring
       > building
       > running tests
       > gpg-connect-agent: failed to create temporary file '/private/tmp/nix-build-fishplugin-fzf.fish-9.3.drv-0/tmp.5EQyTwP5Hp/.gnupg/.<....>': No such file or directory
       > gpg-connect-agent: can't connect to the gpg-agent: No such file or directory
       > gpg-connect-agent: error sending standard options: No agent running
       > Script started, output file is /dev/null
       > script: fish: No such file or directory
       >
       > Script done, output file is /dev/null
       For full logs, run 'nix log /nix/store/pc8m42rgz4iwhq62wk0fprhwfvr82m5d-fishplugin-fzf.fish-9.3.drv'.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/fishplugin-fzf.fish/versions.
meta.description for fishPlugins.fzf-fish is: "Augment your fish command line with fzf key bindings"
meta.homepage for fishPlugins.fzf-fish is: "https://github.com/PatrickF1/fzf.fish"
meta.changelog for fishPlugins.fzf-fish is: ""
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 9.4 with grep in /nix/store/c4hi62nsdrdd39azk94sv5wykn6hh5y8-fishplugin-fzf.fish-9.4
found 9.4 in filename of file in /nix/store/c4hi62nsdrdd39azk94sv5wykn6hh5y8-fishplugin-fzf.fish-9.4

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
fishPlugins.fzf-fish

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/c4hi62nsdrdd39azk94sv5wykn6hh5y8-fishplugin-fzf.fish-9.4 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

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

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/c4hi62nsdrdd39azk94sv5wykn6hh5y8-fishplugin-fzf.fish-9.4
ls -la /nix/store/c4hi62nsdrdd39azk94sv5wykn6hh5y8-fishplugin-fzf.fish-9.4/bin

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

1 package built:

fishPlugins.fzf-fish

Maintainer pings
cc @pacien for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/fishplugin-fzf.fish/versions.
meta.description for fishPlugins.fzf-fish is: "Augment your fish command line with fzf key bindings"
meta.homepage for fishPlugins.fzf-fish is: "https://github.com/PatrickF1/fzf.fish"
meta.changelog for fishPlugins.fzf-fish is: ""
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 9.5 with grep in /nix/store/h9njai7iigaiqhyr0sskqridiy3f9ryn-fishplugin-fzf.fish-9.5
found 9.5 in filename of file in /nix/store/h9njai7iigaiqhyr0sskqridiy3f9ryn-fishplugin-fzf.fish-9.5

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
fishPlugins.fzf-fish

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/h9njai7iigaiqhyr0sskqridiy3f9ryn-fishplugin-fzf.fish-9.5 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

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

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/h9njai7iigaiqhyr0sskqridiy3f9ryn-fishplugin-fzf.fish-9.5
ls -la /nix/store/h9njai7iigaiqhyr0sskqridiy3f9ryn-fishplugin-fzf.fish-9.5/bin

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

1 package built:

fishPlugins.fzf-fish

Maintainer pings
cc @pacien for testing.

error: builder for '/nix/store/f071yxwin0g103q93pmid013zzzi8kic-fishplugin-fzf.fish-9.5.drv' failed with exit code 1;
       last 10 log lines:
       > ok 28 doesn't clobber FZF_DEFAULT_OPTS
       >
       > 1..28
       > # pass 24
       > # fail 4
       > warning: notify_post() failed with status 9. Uvar notifications may not be sent.
       > warning: notify_post() failed with status 9. Uvar notifications may not be sent.
       > warning: notify_post() failed with status 9. Uvar notifications may not be sent.


Can only get last 32 hours data using the API endpoint

Describe the bug
According to the documentation you should be able to get the last three days worth of data using the API endpoint and after that you need to use the timemachine endpoint.
Expected behavior
Should be able to query data from the last three days using the API endpoint
Actual behavior
Can only query up to the last 32 hours of data before getting a "Requested time too early, please use https://timemachine.pirateweather.net" error message
API Endpoint
Production
Location
Ottawa, Ontario
Other details
@alexander0042 Is the API endpoint only going to store the last 32h of data now? If so then we need to update the docs to reflect the change
Troubleshooting steps

[X] I have searched this repository and Home Assistant Repository to see if the issue has already been reported.
[X] I have read through the API documentation before opening this issue.
[X] I have written an informative title.

@alexander0042 I changed the docs to reflect how long the API is storing past data for since I haven't gotten a response and I don't want to mislead anyone. If it's going to be 32h going forwards then I can close this so lmk.


Reapply "Add support for kueue component"

This reverts commit 1d915ec15be7cd3acc1a715c7377202c149f9034 (#1200).
Kueue is planned to be back in RHOAI 2.8 [1].

[1] https://issues.redhat.com/browse/RHOAIENG-3234

Thank you for your review guys! Merging.


Better implementation of node_coordinates(::LagrangeSpace)

@raar1 @Cmurilochem
This should fix the issue with node_coordinates we discussed today


Add DSC resource Package Set

To keep it consistent with cChoco, add the DSC resource PackageSet, to install a list of packages.

That said, I'm not a fan of this idea because:

If it would be a DSC Composite Resource, it could live outside this module if required (less code to maintain). Someone splatting an array of Hashtable would leverage most of the benefits here.
If it's its own DSC Resource, the logic for multiple package could be harder. Most of the benefit could be added by using caching to file.
Similar outcome could be done with a Choco meta package

Not a fan of this feature for reasons above. Closing.


Avoid suggesting interesting functions outside the subject project

I noticed Fuzz introspector may suggest new fuzz targets from linked libraries. It does not seem productive as the user is intending to fuzz the subject project.
Here is an example for libarchive where targets from libxml2 are being suggested as well:
https://storage.googleapis.com/oss-fuzz-introspector/libarchive/inspector-report/20220321/fuzz_report.html#Remaining-optimal-interesting-functions

I think this is perhaps a duplicate/related of https://github.com/ossf/fuzz-introspector/issues/116 ? I don't think that fuzz-introspector should try and automatically analyse what corresponds the code that matters to the users, instead the users should specify themselves what matters, and one goal is to exclude functions from third parties. It's now possible to exclude functions using a config file https://github.com/ossf/fuzz-introspector/blob/068070c57dcf837c4b222cdd063d22a82d5e2cd8/llvm/lib/Transforms/FuzzIntrospector/FuzzIntrospector.cpp#L255

Also see the references of that issue, e.g. https://github.com/ossf/fuzz-introspector/issues/35#issue-1125806643

Also see the references of that issue, e.g. #35 (comment)

Nice, that make sense.


[BUG] "wait_for_component()" Error when working with "asyncio.wait()"

The solution is found when I created a thread for this issue, so can you be kind to update?
wait_tasks = [
    asyncio.create_task(
        bot.wait_for('on_message_create',
                     check=message_check,
                     timeout=300),
        name="message"),
    asyncio.create_task(
        bot.wait_for_component(
            components=button_actionrow,
            check=component_check,
            timeout=300),
        name="component")
]

done, pending = await asyncio.wait(wait_tasks, return_when=asyncio.FIRST_COMPLETED)

Resolved as of 1.0.3


containers not routable

We have been experimenting with Weave for the past couple of months and every now and then, we see some connectivity issues even among containers on the same host.
We run Weave on ECS (I ll get into the setup on a need to know basis), so containers are started via the ECS agent (although even when manually started, the problem persists).
This is the output of weave status:
Version: 1.8.2 (up to date; next check at 2017/01/13 05:49:56)

        Service: router
       Protocol: weave 1..2
           Name: c2:c4:77:4f:bb:55(<hidden>.compute.internal)
     Encryption: disabled
  PeerDiscovery: enabled
        Targets: 1
    Connections: 1 (1 established)
          Peers: 2 (with 2 established connections)
 TrustedSubnets: none

        Service: ipam
         Status: ready
          Range: <IP_ADDRESS>/8
  DefaultSubnet: <IP_ADDRESS>/8

        Service: dns
         Domain: weave.local.
       Upstream: <IP_ADDRESS>
            TTL: 1
        Entries: 11

        Service: proxy
        Address: unix:///var/run/weave/weave.sock

        Service: plugin
     DriverName: weave

and weave status dns:
ecs-agent    <IP_ADDRESS>        67f94dc87ca7 c2:c4:77:4f:bb:55

ecs-agent    <IP_ADDRESS>      ad48ef8c2484 ca:62:02:d8:53:9d

scope        <IP_ADDRESS>        16ca4cb7868e c2:c4:77:4f:bb:55

scope        <IP_ADDRESS>  16ca4cb7868e c2:c4:77:4f:bb:55

scope        <IP_ADDRESS>      0dfa24e2baa2 ca:62:02:d8:53:9d

scope        <IP_ADDRESS>   0dfa24e2baa2 ca:62:02:d8:53:9d

secure-store-svc <IP_ADDRESS>       bbcd9c070313 c2:c4:77:4f:bb:55

store-svc <IP_ADDRESS>       dccc5e03adf2 c2:c4:77:4f:bb:55

store-svc <IP_ADDRESS>       daffb7793090 ca:62:02:d8:53:9d

tenant-svc   <IP_ADDRESS>       07beebb75e13 c2:c4:77:4f:bb:55

However, containers appear to be unreachable from one another.
e.g  dial tcp <IP_ADDRESS>:8080: getsockopt: no route to host"
I could use some help in debugging this

this is the full weave report http://pastebin.com/raw/v6h2JTFm

Inside one of the containers that cannot talk, if you run ip addr and ip route, what do you see?

tenant-svc:/# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
40: eth0@if41: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
    link/ether 02:42:ac:11:00:05 brd ff:ff:ff:ff:ff:ff
    inet <IP_ADDRESS>/16 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:acff:fe11:5/64 scope link
       valid_lft forever preferred_lft forever
42: ethwe@if43: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1410 qdisc noqueue state UP
    link/ether 1a:b5:41:88:cc:a2 brd ff:ff:ff:ff:ff:ff
    inet <IP_ADDRESS>/20 scope global ethwe
       valid_lft forever preferred_lft forever
    inet6 fe80::18b5:41ff:fe88:cca2/64 scope link
       valid_lft forever preferred_lft foreve

tenant-svc:/# ip route
default via <IP_ADDRESS> dev eth0
<IP_ADDRESS>/20 dev ethwe  src <IP_ADDRESS>
<IP_ADDRESS>/16 dev eth0  src <IP_ADDRESS>
<IP_ADDRESS>/4 dev ethwe

Ok, it has the right interface and route; I think that message can also mean arp has no entry for the address.
What is the OS?  Is it possible you hit something like #2601?

It's possible. We indeed run a "suspect" version of CoreOS
VERSION=1185.5.0
VERSION_ID=1185.5.0
BUILD_ID=2016-12-07-0937
PRETTY_NAME="CoreOS 1185.5.0 (MoreOS)"

Apologies for all the hand-holding, but I want to make sure I understand the current state:
Is there an obvious way to see of this is what we are hitting ?
I see some "un-mastered" entries via
ip link show type veth | grep vethwe | grep -v master
19: vethwepl3622@if18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue state UP mode DEFA
ULT group default
27: vethwepl26741@if26: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue state UP mode DEF
AULT group default
35: vethwepl30663@if34: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue state UP mode DEF
AULT group default
43: vethwepl30160@if42: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue state UP mode DEF
AULT group default
47: vethwepl754@if46: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue state UP mode DEFAU
LT group default
55: vethwepl9573@if54: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue state UP mode DEFA
ULT group default
~~~~

b) what do I need to do to fix it ? Should I expect this to be fixed in a more recent version of CoreOS or do I need to alter systemd-networkd configuration (or both)?

I am confused because the Weave ticket is still open, but the corresponding CoreOS ones are closed.

Thanks for your patience

@abatsakis I like your grep line - I was checking indirectly via /sys/devices/virtual/net/weave/brif
A feature has been added to systemd-networkd to state that an interface should not be managed, and CoreOS have updated their config to add that option: https://github.com/coreos/coreos-overlay/pull/2300.  I don't know exactly which version of CoreOS that went into, but the current 'stable' stream post-dates it by a month.
It is likely that adding the Unmanaged=yes option on device type veth is enough to fix the main symptom with Weave Net, but further investigation is required to know whether other issues remain.  Hence #2601 is still open.

fair enough... I ll make the change and report back if the issue persists

for completeness I am adding the output of networkctl. Still testing the fix
ip-192-168-51-138 / # networkctl
IDX LINK             TYPE               OPERATIONAL SETUP
  1 lo               loopback           carrier     configured
  2 eth0             ether              routable    configured
  3 docker0          ether              routable    configured
  8 datapath         ether              degraded    configuring
 10 weave            ether              routable    configuring
 11 dummy0           ether              degraded    configuring
 13 vethwe-datapath  ether              degraded    configured
 14 vethwe-bridge    ether              degraded    configured
 15 vxlan-6784       ether              degraded    configuring
 19 vethb5eac35      ether              degraded    configured
 21 vethwepl3672     ether              degraded    configured
 23 veth1547a21      ether              degraded    configured
 25 vethwepl4118     ether              degraded    configured
 27 veth5d497dc      ether              degraded    configured
 29 vethwepl4538     ether              degraded    configured
 31 vethe163102      ether              degraded    configured
 33 vethwepl7840     ether              degraded    configured

Thanks @abatsakis - let us know how it goes.

@abatsakis did you get anywhere?

I haven't seen this issue since, but we don't have a truly automated mechanism to test this and so I am slowly building confidence

OK, thanks; I will close this issue for now but feel free to re-open if there is more to discuss.


schema spec should include standard method of schema version determination

Recommend that we document a standard method to determine, from an H5AD or CXG:

is the dataset conforming to a Corpora schema?
And if so, which version?

In addition, we need to formalize which versions must be supported by our code for backward compat.
There are varied "version sniffing" algos implemented (eg, in single-cell-explorer backend), which are needed to multiplex old Corpora specs (eg, to extract various metadata).

This is part of the way there, no? https://github.com/chanzuckerberg/single-cell-curation/blob/main/schema/2.0.0/schema.md#uns-dataset-metadata

how so?  It is completely different than earlier versions, so at a minimum we need to define precedence...
(which isn't hard - I'd just rather we were intentional and explicit, so each SW module doesn't do something different)

See my comments in wrangling. Both 2.0.0 and 1.1.0 define a mechanism for introspecting the version. For 1.1.0 - https://github.com/chanzuckerberg/single-cell-curation/blob/main/schema/1.1.0/corpora_schema.md#schema-version. For 2.0.0 - see Arathi's comment above.
It sounds like you want to define a software "policy" that uses these mechanisms, but that should not be in the schema specification.
Further, the cellxgene-schema was a complete rewrite and does not support 1.1.0. Following re-curation, the portal will remove all references to legacy schemas.
I'm probably missing some subtlety here because it's Monday and Day 0 for me after vacation ;-)

Closed per conversation with @bkmartinjr ... and conclusion of wrangling thread.


Using systemd-strategy works for the latest raspian os.

See more info https://github.com/ansible/ansible/issues/76124

This fix works. I'll merge it. If i leave the use option unspecify it also works.


Issue with updateChildren method of src/core/vdom/patch.js and with removeVnodes method

Hello,
it seems that i have an issue with the updateChildren method
this method does not seems to care about keep alive, and seems to call removeVnodes in my case
and is removing keep alive components that should stay
https://github.com/vuejs/vue/blob/4063f3ce9bfba0132ade75ad5f907c923a561304/src/core/vdom/patch.js#L404
i tried to reproduce with jsfiddle but i failed to do so, it seems to be deeply related to vuejs core and i don't understand it so much, so i can't reproduce, this is the jsfiddle i'm working on : http://jsfiddle.net/lk77/0opq3ucx/71/
my component is deactivated and then destroyed

it seems related to a v-if that is unrelated but share the same parent, it seems that a sibling higher in the parent tree, with a v-if on it, can cause the keep-alive to break and the component to be destroyed.
thanks.

Hello,
i cant use the issue helper since i need assistance for the reproduction, but there is indeed an issue.


Multiple date time instances on mobile when using trigger for modal

Current behavior

When we use trigger for modal on Job Details page, closing date time modal shows empty modal
Expected behavior

When using trigger, only one modal should get opened
Steps to reproduce the issue

Can you handle fixing this bug by yourself?

[ ] YES
[ ] NO

Environment details

Browser:
OS:
Code Version:

Additional information

not able to reproduce


About accelerated networking Limit

[Enter feedback here]
In the document below, we are guiding that accelerated networking is supported starting from 4 vCPU on VMs that support HT (Hyperthread).
https://docs.microsoft.com/en-us/azure/virtual-network/create-vm-accelerated-networking-powershell#limitations-and-constraints

However, the document guides that accelerated networking is supported from Standard_D2_v31 (2vCPU) to Single NIC, and it was confirmed that the accelerated network is enabled even when the actual VM size is deployed and tested.
https://docs.microsoft.com/en-us/azure/virtual-machines/dv3-dsv3-series#dv3-series

As a result of deploying a VM, it was tested to support accelerated networking on a single NIC even with 2vCPU.

In a VM that supports HT, it is guided to enable accelerated networking only when it has 4vCPU or higher. but It has been confirmed that accelerate networking is possible even on VMs with 2vCPUs based on real HT.
Are there any internal changes?

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

ID: e4be8e45-460a-fab4-519b-32d83382005c
Version Independent ID: 36a002a6-5813-da00-0a57-068eeaf491cf
Content: Create Windows VM with accelerated networking - Azure PowerShell
Content Source: articles/virtual-network/create-vm-accelerated-networking-powershell.md
Service: virtual-network
GitHub Login: @gsilva5
Microsoft Alias: gsilva

@gsilva5 Could you please look into this? Thank you!

#please-close


New App: LA metro transit line stop times

Description
Use the transitapp API to get departure times for LA metro trains at a specific stop.

Copilot

🤖 Generated by Copilot at f43844a
Summary
🚇🕒📝

This pull request adds a new applet called LA Metro Stop, which shows the departure times for LA metro trains. It includes the applet code in la_metro_stop.star and the manifest file in manifest.yaml. The applet code uses various modules and functions to fetch and display the transit data.

LA Metro Stop
New applet for Tidbyt
Shows train departure

Walkthrough

Create a new applet for displaying LA metro train departure times (link, link)

Add the main applet code in la_metro_stop.star that uses modules, constants, functions, and logic to handle API requests, caching, rendering, encryption, and schema validation (link)
Add the manifest file in manifest.yaml that contains the metadata and configuration for the applet, such as its id, name, summary, description, author, file name, and package name (link)

I have read the CLA Document and I hereby sign the CLA

recheck


Scripts Converting Megatron_T5 to HF_T5

Hello guys, could you please provide any script that can convert megatron t5 into hf t5 model? Especially when TP and PP is not equal to 1.

cc @pacman100

Hello, this is not currently available and we need considerable interest from users to prioritise it.

Got it, thanks!


[zh] Umbrella - reference/kubernetes-api/config-and-storage-resources

This is an umbrella issue for API reference docs that are out of sync for zh localization. The difference is captured on 2022-06-07, so the list may become outdated soon. Please do run the scripts/lsync.sh again before working on any file below.
Could @tengqm give me a favor to check if the sequence below is applicable or not? I'm not sure the dependency-related issue that may cause a merge-request failed to build.

[ ] config-1 @windsonsea572  content/en/docs/reference/kubernetes-api/config-and-storage-resources/config-map-v1.md

[ ] config-2 @windsonsea543  content/en/docs/reference/kubernetes-api/config-and-storage-resources/csi-driver-v1.md

[ ] config-3 @windsonsea503  content/en/docs/reference/kubernetes-api/config-and-storage-resources/csi-node-v1.md

[ ] config-4594  content/en/docs/reference/kubernetes-api/config-and-storage-resources/csi-storage-capacity-v1.md

[ ] config-5846  content/en/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-claim-v1.md

[ ] config-61401  content/en/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1.md

[ ] config-7576 content/en/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1.md

[ ] config-8507  content/en/docs/reference/kubernetes-api/config-and-storage-resources/storage-class-v1.md

[ ] config-9687  content/en/docs/reference/kubernetes-api/config-and-storage-resources/volume.md

[ ] config-10905  content/en/docs/reference/kubernetes-api/config-and-storage-resources/volume-attachment-v1.md

It may take some time to localize these files and the word count is for your reference as follows:

/language zh

/triage accepted
/language zh

/assign

/retitle [zh] Umbrella - Resync reference/kubernetes-api/

/retitle [zh] Umbrella - Resync reference/kubernetes-api/config-and-storage-resources

Wow...that's a lot of work to do !!!

Thanks you all. All files in this issue are successfully localized and merged.
/close


Make it easier to switch versions of Docker

Switching between various versions of Docker should be as easy as switching between consoles. There should be a ros engine command that supports subcommands similar to ros console.

Verified in v0.6.0-rc1 that this is working. Will file separate issues for bugs/enhancement requests.


[C++] PyArrow's csv reader yields different results than the default pandas

Describe the bug, including details regarding any error messages, version, and platform.
Platform: Ubuntu 20.04
Version: 11.0 and 12.0 (w/ pandas 1.4.1 and 2.0.1)
Hello, I've posted this issue on the pandas board as well, and they've asked me to put it here too:
"""
user_id,value
1225717802.1679841607,33
"""

import pandas as pd
a = pd.read_csv("bug.csv", dtype={"user_id": str})
b = pd.read_csv("bug.csv", dtype={"user_id": str}, engine="pyarrow")

print(a.user_id.iloc[0]) #<PHONE_NUMBER>.1679841607
print(b.user_id.iloc[0]) #<PHONE_NUMBER>.1679842

assert a.user_id.dtype == b.user_id.dtype # <- both are strings
assert a.user_id.iloc[0] == b.user_id.iloc[0] # <- this fails

It seems that under the hood pyarrow.read_csv handles strings (explicitly asked as strings) differently than expected, in the sense that there is some automatic conversion happening first before the explicit string conversion takes place. In this case it is first interpreted as a float, truncated because of precision issues and just then reconverted to string type.
Component(s)
Python

The behaviour you notice is indeed from casting what has been read/parsed as a float afterwards to string. However, if you use pyarrow's csv reader directly and using the column_types argument, this is done properly:
>>> from pyarrow import csv
>>> csv.read_csv("bug.csv")
pyarrow.Table
user_id: double
value: int64
----
user_id: [[1225717802.1679842]]
value: [[33]]

>>> csv.read_csv("bug.csv", convert_options=csv.ConvertOptions(column_types={"user_id": pa.string()}))
pyarrow.Table
user_id: string
value: int64
----
user_id: [["1225717802.1679841607"]]
value: [[33]]

So I assume this is actually a bug in pandas after all (in how pandas integrates with the pyarrow csv reader, and how it translates its own arguments to arguments passed to pyarrow). Therefore closing this issue, and will re-open the one on the pandas side (https://github.com/pandas-dev/pandas/issues/53269)