multiplicative_replacement() implementation of delta inconsistent with interpretation

The implementation of multiplicative replacement imputes delta in a misleading way. The delta imputed should be proportional to the detection limit, not just the number of features. Otherwise, you could end up with some misleading results of imputation unless if the number of features is in the order of thousands. For your reference, the imputation paper is here.
For example:
from sckbio.stat.composition import multiplicative_replacement, closure

# This also works on count data directly
def multiplicative_replacement2(mat, delta=None):
    r"""Replace all zeros with small non-zero values
    It uses the multiplicative replacement strategy [1]_ ,
    replacing zeros with a small positive :math:`\delta`
    and ensuring that the compositions still add up to 1.
    Parameters
    ----------
    mat: array_like
       a matrix of proportions where
       rows = compositions and
       columns = components
    delta: float, optional
       a small number to be used to replace zeros
       If delta is not specified, then the default delta is
       :math:`\delta = \frac{1}{N^2}` where :math:`N`
       is the number of components
    Returns
    -------
    numpy.ndarray, np.float64
       A matrix of proportions where all of the values
       are nonzero and each composition (row) adds up to 1
    Raises
    ------
    ValueError
       Raises an error if negative proportions are created due to a large
       `delta`.
    Notes
    -----
    This method will result in negative proportions if a large delta is chosen.
    References
    ----------
    .. [1] J. A. Martin-Fernandez. "Dealing With Zeros and Missing Values in
           Compositional Data Sets Using Nonparametric Imputation"
    Examples
    --------
    >>> import numpy as np
    >>> from skbio.stats.composition import multiplicative_replacement
    >>> X = np.array([[.2,.4,.4, 0],[0,.5,.5,0]])
    >>> multiplicative_replacement(X)
    array([[ 0.1875,  0.375 ,  0.375 ,  0.0625],
           [ 0.0625,  0.4375,  0.4375,  0.0625]])
    """
    mat = np.array(mat)
    z_mat = (mat == 0)

    num_feats = mat.shape[-1]
    tot = np.sum(z_mat, axis=-1, keepdims=True)

    if delta is None:
        delta = np.min((np.min(mat[mat > 0])*.55, (1. / num_feats)**2))

    zcnts = 1 - ((tot * delta)/mat.sum(axis=-1, keepdims=True))
    if np.any(zcnts) < 0:
        raise ValueError('The multiplicative replacment created negative '
                         'proportions. Consider using a smaller `delta`.')
    mat = np.where(z_mat, delta, zcnts * mat)
    return mat.squeeze()

X = closure(np.array([0, 1, 2, 4, 8, 16, 32, 64, 128]))

X

#array([ 0.        ,  0.00392157,  0.00784314,  0.01568627,  0.03137255, 0.0627451 ,  0.1254902 ,  0.25098039,  0.50196078])

multiplicative_replacement(X)

#array([ 0.01234568,  0.00387315,  0.00774631,  0.01549262,  0.03098523, 0.06197047,  0.12394093,  0.24788187,  0.49576374])

multiplicative_replacement2(X)

#array([ 0.00215686,  0.00391311,  0.00782622,  0.01565244,  0.03130488, 0.06260977,  0.12521953,  0.25043906,  0.50087812])

Right - multiplicative imputation is generally awkward in this realm.  Typically we are dealing with counts, where there is no detection limit (which is specified by delta).  The default delta is not ideal when you have a smaller number of features, which is why there is the option to impute based on the user choice of delta.
I'm not entirely sure about the merits of adding in this sort of functionality in -- it's not clear me what an appropriate detection limit would be.  We also know that there are number of much better imputation methods (see this paper).

The implementation that I provided here multiplicative_replacement2() works on actual count data, it closes to the sum of the composition vector specified. In the implementation previously, you assume a closure to 1, so it actually only works only on relative abundance data, or sample vectors that sum to 1.
Also, delta is the value that you replace 0 values with. In the version currently implemented, the delta can be set to a value that is greater than the smallest value in your matrix, an estimation of the detection limit. I specify the detection limit to be the minimum of the input matrix, and then multiply that value simply by .55 which, is what was recommended in the original paper linked in the description. Furthermore, I kept the imputation of delta that was previously provided, and took the minimum of the two imputed deltas to be on the safe side.
Simply put, if my count vector is x = [0, 1, 2, 4, 8, 16, 32, 64, 128], I shouldn't replace 0 with a value that is greater than 1. This can happen in the original implementation, as shown in the example.
The new approach that you provided is interesting, but it requires dense longitudinal data for subjects, and also requires Bayesian prior assumptions. This doesn't work in cross-sectional studies, and is difficult to define a dense sampling.


unclear tip

Is there an existing issue outlining your problem?

[X] I have searched the existing issues and they do not solve my problem.

Describe your issue.
How do I theme images and SVGs? don't clarify, that it don't work if you don't add any generic in svg, but almost all(I think) do this as first step.

it don't work if you don't add any generic in svg

Please clarify, I don't know what you mean by this.

don't work:
.some {
  @svg: escape('<svg fill="blue" width="300" height="130" xmlns="http://www.w3.org/2000/svg"><rect width="200" height="100" x="10" y="10" rx="20" ry="20"/></svg>');
  background-image: url("data:image/svg+xml,@{svg}");
}

work:
.some {
  @svg: escape('<svg fill="@{mauve}" width="300" height="130" xmlns="http://www.w3.org/2000/svg"><rect width="200" height="100" x="10" y="10" rx="20" ry="20"/></svg>');
  background-image: url("data:image/svg+xml,@{svg}");
}

Yep. That's an issue with Stylus/Less really. Feel free to open a PR explaining this if you want.

Yes, "whole point of adding the SVG is changing the colors", but first step is just add it somehow. And for new users of Stylus(like me) this error is stange, because I follow docs.

Right, but this isn't an issue with our instructions it's an issue with the parser. As I said feel free to raise a PR.

did I need to make branch in fork for this pull request?

did I need to make branch in fork for this pull request?

It helps to make it on a separate branch but technically you can make it from the main branch.


OutputFileMode must be string

With version 2.4.0 the app can no longer be started, since the output file mode needs to be an octal, and can't be a string.
The error thrown is
File "/usr/local/lib/python3.10/site-packages/prometheuspvesd/cli.py", line 177, in _write chmod(self.config.config["output_file"], self.config.config["output_file_mode"]) TypeError: 'str' object cannot be interpreted as an integer

Argh... Yeah, I missed adding the required octal int cast, sorry. PR created to fix it, Im going to yank the 2.4.0 release and will prepare a new one tomorrow.

Thanks a lot for your work on this tool, I really like it and it helps me a lot with my setup :)

Your welcome :) Thank you too for all the contributions, ideas and reports.


Update ReadMe

Update the Readme with next update info and current version no.

@Gallimathias,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by Microsoft. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

Thank you!

I'm happy to do that. So no problem :)


add specs for onPageChange hook

please review and consider merging if specs qualify for valid testing of the onPageChange hook

Nice @vice2000 ! :+1:


⚠ ClamAV has degraded performance

In 746edf2, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 49 ms

Resolved: ClamAV performance has improved in 4eff7f5.


Script Errors for MISRA23_6.5.2 Reported on Linux

*** Inspection Error*** File: /jenkins/workspace/Testing/CodeCheck/Nightly/scitools/plugins/CodeCheck/Published Standards/MISRA C++ 2023/MISRA23_6.5.2/check.upy: Inspected File: /jenkins/workspace/Testing/CodeCheck/Nightly/samples/gitahead-Linux/gitahead/build/release/src/cred/cred_autogen/mocs_compilation.cpp: Error: Traceback (most recent call last):
File "/jenkins/workspace/Testing/CodeCheck/Nightly/scitools/plugins/CodeCheck/Published Standards/MISRA C++ 2023/MISRA23_6.5.2/check.upy", line 81, in check
while lex.line_begin() == ref.line():
^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'line_begin'
*** Inspection Error*** File: /jenkins/workspace/Testing/CodeCheck/Nightly/scitools/plugins/CodeCheck/Published Standards/MISRA C++ 2023/MISRA23_6.5.2/check.upy: Error: Traceback (most recent call last):
File "/jenkins/workspace/Testing/CodeCheck/Nightly/scitools/plugins/CodeCheck/Published Standards/MISRA C++ 2023/MISRA23_6.5.2/check.upy", line 81, in check
while lex.line_begin() == ref.line():
^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'line_begin'
*** Inspection Error*** File: /jenkins/workspace/Testing/CodeCheck/Nightly/scitools/plugins/CodeCheck/Published Standards/MISRA C++ 2023/MISRA23_6.5.2/check.upy: Inspected File: /jenkins/workspace/Testing/CodeCheck/Nightly/samples/gitahead-Linux/gitahead/build/release/src/watcher/watcher_autogen/mocs_compilation.cpp: Error: Traceback (most recent call last):
File "/jenkins/workspace/Testing/CodeCheck/Nightly/scitools/plugins/CodeCheck/Published Standards/MISRA C++ 2023/MISRA23_6.5.2/check.upy", line 81, in check
while lex.line_begin() == ref.line():
^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'line_begin'

Looks good, thank you Kenneth


Small issues with undeploy.xml

I found this resource whilst reading through my copy of the 'Force.com Enterprise Architecture' (So far, so excellent). Before than i had just live with the free 'extras' that SF provides with a new DEV org. Nice to have an easy way to get rid of these elements. Whilst using it though I hit three problems:
1. Account.SLA__c
In the Dev org I created there was a field on Account called 'SLA__c'. This was being used by a Case Assignment Rule called Standard and a Case Escalation Rule called Standard, so the SLA__c field could not be removed. Deleting these two rules resolved the issue
2. Java 8 Version Issue
Initially I tried to run it with Java 8. Unfortunately this failed with the following error:
ReferenceError: "importPackage" is not defined in  at line number ...
It turns out that the issue is with Java 8 which no longer supports 'importPackage' since Rhino has been replaced by Nashorn. I've not tested it, but this suggests a workaround:
http://stackoverflow.com/questions/22502630/switching-from-rhino-to-nashorn
In my case I switched to Jave 7 and it worked OK.
3. SF Domain
On line 822 there is a reference to a Salesforce Domain. For my org I had to edit this to work with the org domain which in my case was different from emea.
I hope the above is useful.
Thanks for a great book.
Alan

Hi:

Hi @elukaweski

Thanks @afaubel for the feedback, glad your enjoying the book so far!
As referenced in the book the Ant tools have been taken from the FinancialForce repo here. It looks like the latest versions of these files have fixed your issues, so worth taking a look at those.

Hi @afawcett
Thanks for that. Yep, that solved all of the issues I found. Just goes to show I should read the whole book and not just dip into the bits I think I need to read :-)

Ha no worries, enjoy the rest of your read, please feel free to drop a review on Amazon as well. :+1:


[BUG] [Ubuntu] [PostgreSQL] Apply command fails after upgrading from v1.0.x LTS to v1.3.0

Describe the bug
I'm not able to re-apply configuration after upgrading the cluster from v1.0.x LTS to v1.3.0.
It fails on TASK [postgresql : Extensions | repmgr | Install package(s)]. There is an issue with downgrading repmgr-common package.
Reproduced on Ubuntu.
2022-01-17T19:37:30.2731957Z[38;21m19:37:30 INFO cli.engine.ansible.AnsibleCommand - TASK [postgresql : Extensions | repmgr | Install package(s)] *******************
2022-01-17T19:37:31.2189394Z[31;21m19:37:31 ERROR cli.engine.ansible.AnsibleCommand - fatal: [ci-10to13azubflannel-postgresql-vm-1]: FAILED! => {"cache_update_time":<PHONE_NUMBER>, "cache_updated": false, "changed": false, "msg": "'/usr/bin/apt-get -y -o \"Dpkg::Options::=--force-confdef\" -o \"Dpkg::Options::=--force-confold\"      install 'repmgr-common=5.2.1-*'' failed: E: Packages were downgraded and -y was used without --allow-downgrades.
", "rc": 100, "stderr": "E: Packages were downgraded and -y was used without --allow-downgrades.
", "stderr_lines": ["E: Packages were downgraded and -y was used without --allow-downgrades."], "stdout": "Reading package lists...
Building dependency tree...
Reading state information...
The following packages will be DOWNGRADED:
  repmgr-common
0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 3 not upgraded.
", "stdout_lines": ["Reading package lists...", "Building dependency tree...", "Reading state information...", "The following packages will be DOWNGRADED:", "  repmgr-common", "0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 3 not upgraded."]}
2022-01-17T19:37:31.3099865Z[31;21m19:37:31 ERROR cli.engine.ansible.AnsibleCommand - fatal: [ci-10to13azubflannel-postgresql-vm-0]: FAILED! => {"cache_update_time":<PHONE_NUMBER>, "cache_updated": false, "changed": false, "msg": "'/usr/bin/apt-get -y -o \"Dpkg::Options::=--force-confdef\" -o \"Dpkg::Options::=--force-confold\"      install 'repmgr-common=5.2.1-*'' failed: E: Packages were downgraded and -y was used without --allow-downgrades.
", "rc": 100, "stderr": "E: Packages were downgraded and -y was used without --allow-downgrades.
", "stderr_lines": ["E: Packages were downgraded and -y was used without --allow-downgrades."], "stdout": "Reading package lists...
Building dependency tree...
Reading state information...
The following packages will be DOWNGRADED:
  repmgr-common
0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 3 not upgraded.
", "stdout_lines": ["Reading package lists...", "Building dependency tree...", "Reading state information...", "The following packages will be DOWNGRADED:", "  repmgr-common", "0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 3 not upgraded."]}

EDIT: repmgr-common package in version 5.3.0 is installed as dependency by epicli v1.0 LTS as there is no fixed version (it's been introduced in v1.2: https://github.com/epiphany-platform/epiphany/blob/v1.2/core/src/epicli/data/common/ansible/playbooks/roles/postgresql/tasks/extensions/replication/packages.yml#L10)
[ubuntu@ec2-1-1-1-1 ~]$ apt-cache policy repmgr-common
repmgr-common:
  Installed: 5.3.0-1.bionic+1
  Candidate: 5.3.0-1.bionic+1
  Version table:
 *** 5.3.0-1.bionic+1 100
        100 /var/lib/dpkg/status
     4.0.3-1 500
        500 http://eu-west-1.ec2.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages

How to reproduce
Steps to reproduce the behavior:

Deploy v1.0.1 cluster with 2 PostgreSQL vms and repmgr enabled.
Upgrade OS to Ubuntu 20.04 (this can be helpful: https://github.com/epiphany-platform/epiphany/blob/develop/ci/ansible/playbooks/os/ubuntu/upgrade-release.yml)
Upgrade epicli to v1.3.0
Execute apply (v1.3.0)

Expected behavior
The configuration should be applied again with no issues.
Config files
Environment

Cloud provider: [all]
OS: [Ubuntu]

epicli version: v1.3.0, develop
Additional context

DoD checklist

[ ] Changelog updated (if affected version was released)
[ ] COMPONENTS.md updated / doesn't need to be updated
[ ] Automated tests passed (QA pipelines)

[ ] apply
[ ] upgrade

[ ] Case covered by automated test (if possible)
[ ] Idempotency tested
[ ] Documentation updated / doesn't need to be updated
[ ] All conversations in PR resolved
[ ] Backport tasks created / doesn't need to be backported

The issue is that in LTS we install the latest repmgr-common package as a dependency and not a fixed one. Starting from v1.2 we fix the version.
:heavy_check_mark: Tested:

upgrade from v1.0.1 + re-apply v1.3
upgrade from v1.2.0 + re-apply v1.3
apply v1.3 + re-apply v1.3


Shortcode to generate responsive images

Last one for today :) I really like the speed of bearblog, hope we can make it even better while maintaining the speed!
To make an ultrafast blog you want no images, but if you need or want images anyway, this shortcode generates the lowest resolution required for optimal viewing on any device. Backwards compatible with legacy devices so nobody gets hurt.
Based on

https://dev.to/stereobooster/responsive-images-for-hugo-dn9
https://alexlakatos.com/web/2020/07/17/hugo-image-processing/
https://github.com/gohugoio/hugo/blob/master/tpl/tplimpl/embedded/templates/shortcodes/figure.html

P.S. this also fixed content layout shift without having to explicitly specify dimensions manually on each image.

P.S. this also fixed content layout shift without having to explicitly specify dimensions manually on each image.


Add Postgres support for the Socket Factory.

The core code in SslSocketFactory is reused as is.
The main difference between the MySQL implementation and the Postgres
implementation is that the user has to specify the instance name via the
socketFactoryArg property instead of a custom property as the Postgres
socket factory does not have access to the params.
There needs to be some cleanup in the code to move the common code out
of the 'mysql' package, but I'll leave it to a separate CL to keep this
small.
We also need to consider moving this code to a more 'generic' repo as
this one is mysql-specific, but that's a larger unertaking left to a
separate exercise.

LGTM

:shipit:


InjectTemplateListener - returnn api proper view

InjectTemplateListener  - injectTemplate : set $preferRouteMatchController view config param if exists. This way apigility rest service can return proper view per api .
prefer_route_match_controller should be set at the config route to true  :
'route' => '/sales[/:sales_id]',
'defaults' => array(
'controller' => 'Ecommerce\V1\Rest\Sales\Controller',
'prefer_route_match_controller'=>true
),
controller_map should be set at the config view_manager also .
'controller_map' => array(
'Ecommerce\V1\Rest\Sales\Controller' => 'ecommerce/sales'
),
AcceptableViewModelSelector - notice fix

Could someone help me to understand why the unit test get failed please ?
It happens only at php 7 and I saw that it happens to other people pull requests ....

Thanks, @karborator !


Added getter and setter methods for extra colors (Pearlescence and Ri…

I have added getter and setter methods to Vehicle class for Vehicle pearlescence and Vehicle rim colors.
According to native-db comments, RimColors are equivalent to VehicleColors, so I'm using the existing VehicleColor enum.
Pearlescence is an int and we don't have yet any enum for it, so it will return an int on getter and expect an int on setter.

I've found that Rim Color setter may not be working as expected so I'll review it and send a new Pull Request later.

I've found that Pearlescence setter is not working properly so I'm closing and I'll pull again later.


Hide Jump to Next Panel Corresponding Position

Hi,
is it possible to hide Jump to Next Panel Corresponding Position in right-click context menu?

Sorry currently not, but I think it could be done by adding some setting as a feature toggle. But thanks anyway for your suggestion. By the way, may I ask what's the reason that the "Jump to Next Panel Corresponding Position" is annoying in your context please?

Mainly because it is positioned at the top of the list and I accidentally always press it instead of "Go to Definition" :laughing:


Feature: Add support for custom attestation predicate types but this time while verifying attestation

Description

We added this support for uploading attestation to the registries in PR #504  but we haven't added this support for verifying attestations against claims yet, so we have to add this support for it too.
https://github.com/sigstore/cosign/blob/main/pkg/cosign/verifiers.go#L47
cc: @dlorenc @Dentrax

maybe we can discuss a bit about the feature because I'm so excited to start working on this issue. @dlorenc 🤩

This plan sounds good to me!
It would be fun to try to integrate with cue as well for richer, custom validation of the predicate after the signature and subject have been matched.

We created a discussion on the cue repo: https://github.com/cue-lang/cue/discussions/1252
What we want to do is we need to convert given enforcement flags (as proposed here by @developer-guy) into an in_toto model, and then we easily generate an enforcement action. Implementation process will be quite easy after, I guess.

based on the discussion that is started by @Dentrax, we finally found a way to validate the JSON against policy files written by Cuelang.  Here is the code sample we followed:
package main

import (
	"cuelang.org/go/cue"
	"cuelang.org/go/cue/cuecontext"
	cuejson "cuelang.org/go/encoding/json"
	"io/ioutil"
)

func main() {
        ctx = cuecontext.New()
	cueBs, _ := ioutil.ReadFile("policy.cue")
	v := ctx.CompileString(string(cueBs), []cue.BuildOption{}...)

	input := `{
              "foo": {
                      "bar": {
		           "baz": 10,
                            "taz":  "I'm not integer"
	              }
               }
         }`
	err := cuejson.Validate([]byte(input), v)
	if err != nil {
		panic(err)
	}
}

and the policy file policy.cue:
foo: bar: {
	baz: <11
	taz: int
}

if you run the code snippet above, you will get an error:
panic: foo.bar.taz: conflicting values int and "I'm not integer" (mismatched types int and string)

So, what we propose is that we will get these policy files behind the flag something like -policy policy.cue, then we will verify the predicate against these policy files, which means that users can define this flag more than once like -policy validate1.cue -policy validate2.cue.
Would you like to give us a hand @verdverm?
PTAL @erkanzileli @dlorenc @Dentrax

@developer-guy I sure would
Are there other comm channels like chat or video that get used? I have some questions on the example and probably need to get up to speed on Sigstore / Cosign

please feel free to join us from Slack and let's have a chat 🙏 @verdverm

Copying @mpvl and @myictv who might be interested in following this as well.


Instantiating from a simpler format?

Is there a way to instantiate a layout from a simpler kind of format, which just shows the position and size of each View.
(this ignores colours, which would have to be passed via JSON somehow)
So a four-view layout (2 by 2) could be expressed like so,
// json, numbers are percentages
{
    "views": [
        {
            "width": 50,
            "height": 50,
            "x": 0,
            "y": 0
        },
        {
            "width": 50,
            "height": 50,
            "x": 50,
            "y": 0
        },
        {
            "width": 50,
            "height": 50,
            "x": 0,
            "y": 50
        },
        {
            "width": 50,
            "height": 50,
            "x": 50,
            "y": 50
        }
    ]
}

// swift
struct SView: Identifiable, Codable, Hashable {
    var id = UUID()
    let width: CGFloat
    let height: CGFloat
    let x: CGFloat
    let y: CGFloat

    enum CodingKeys: String, CodingKey {
        case width, height, x, y
    }
}

I don't think so, at least in the 4x4 case you are showing. The notion of splitting two views is at the heart of what SplitView is doing, so the layout is always between 2 views. It would need to be done by splitting two views at a time to produce a 4x4:
HSplit(
    left: { VSplit(top: { Color.green }, bottom: { Color.blue} ) },
    right: { VSplit(top: { Color.red }, bottom: { Color.yellow }) }
)

or
VSplit(
    top: { HSplit(left: { Color.green }, right: { Color.red} ) },
    bottom: { HSplit(left: { Color.blue }, right: { Color.yellow }) }
)

The top 4x4 has a single splitter that slides horizontally, and the bottom has one that slides vertically. I'm guessing you want each side within the 4x4 to be independently slidable, though, not this.

If one of these two layouts is what you're after, then it would be pretty simple to set up your own view that took the data from your struct and computed the proper fractions, etc, hiding that complexity.


Formatting especially long argument lists with short arguments

rustfmt would like to format the following:
let _ = vec![
            9, 0, 0, 0,
            9, 1, 0, 1,
            9, 2, 1, 0,
            9, 3, 1, 1,
            9, 4, 3, 5,
            9, 7, 0, 1,
            0
        ];

like
let _ = vec![9,
            0,
            0,
            0,
            9,
            1,
            0,
            1,
            ...
        ];

This is not very helpful normally, but in my case those groupings have a particular meaning, so I turned off formatting on the item. Looking at it more I feel like there could be a better default for such a code block. Perhaps preferring to list multiple arguments for each line up to a character limit before going to the next line. Or maybe even detecting an edge case like this and not modifying the code therein.

I think this is something you would use #[rustfmt_skip] for.

#[rustfmt_skip] requires rust nightly which I am not using. But #[cfg_attr(rustfmt, rustfmt_skip)] works which is what I did. It just isn't ideal to have to do formatting manually for long argument lists, and sprinkling pragmas all over the place is less than ideal.

I don't want to suggest that the right answer is to change/restructure your code, but one of the reasons we'd originally ignored cases like this was that we hoped such code could look like:
let _ = vec![
            (9, 0, 0, 0),
            (9, 1, 0, 1),
            (9, 2, 1, 0),
            (9, 3, 1, 1),
            (9, 4, 3, 5),
            (9, 7, 0, 1),
        ];

But at the same time, I can understand that you might need to interface with some API that doesn't work that way.
It'd be nice if there was a semantically insignificant grouping mechanism you could use for that, as a hint that certain sets go together. You might consider making a macro for that, which allows you to provide sets of what look like 4-tuples, and automatically translate them and add the trailing 0. rustfmt would then format it accordingly, and it'd be more readable.
But at the same time, it might be worth considering a rustfmt attribute like #[rustfmt(group(4))]

For my particular case it is just a coincidence that they look like 4-tuples. The 9 is a command that takes three arguments, there are a number of other commands that take a different number of arguments. And those arguments can be derived from different values. So my code looks like:
let _ = vec![
        add, reg_min+0, 0, 0,
        add, reg_min+0, 1, 1,
        eq, reg_min+1, reg_min+0, 3,
        jt, reg_min+1, 3424,
        noop,
        out, 69,
        halt,
]

I had simplified it to keep some distracting details from getting involved, but it appears that I simplified it too much. It is looking like this might just be too weird to deal with.

That is to say, I am not seeking some perfect formatting rule. Just better handling of long argument lists.

Ooh, thanks for that code example. I have similar code in an emulator project with vectors of variable-length machine code bytes that I format as one instruction per line, and I hadn't considered how rustfmt would format it before.
In cases like that, where the number of elements per line is very semantic and human-chosen, I think it's fair to require a "rustfmt skip" attribute. We should make it more concise than #[cfg_attr(rustfmt, rustfmt_skip)], though.

Sure, I've done the same thing, writing machine code in an array.

So it seems that the consensus is to use cfg_attr. Which is fine for such specific structuring. It is sort of annoying that the smallest unit I can place that attr on is a function and not the declaration causing me problems.

@Alex-Addy When this feature is stabilized, attributes will be able to apply to single statements.

Oh, in fact, the statements part is already stabilized, because this successfully compiles: https://play.rust-lang.org/?gist=80c1aa6ff33a3aa9a9bc7c895d495f93&version=stable
However, rustfmt ignores the rustfmt_skip on a statement. We should open an issue for that.

Opened https://github.com/rust-lang-nursery/rustfmt/issues/1810.

@Alex-Addy it should be in rustfmt-nightly already (if you are not using the nightly rustfmt, uninstall the non-nightly version, cargo install rustfmt-nightly, if you are using nightly already you can update by using install --force

It looks like I can't compile that with the stable compiler. I get this error:
error[E0554]: #[feature] may not be used on the stable release channel
  --> /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/rustfmt-nightly-0.2.1/src/lib.rs:11:1
   |
11 | #![feature(rustc_private)]

I'm closing this issue as it is pretty much resolved to my satisfaction. I'll be watching for statements to hit stable.


Framer Studio violates expected coffeescript behavior

The code below works perfectly in coffeescript. But when using Framer Studio's print method it will throw TypeError: undefined is not a object (evaluating 'v.constructor').
Object::test = (props...) -> v.constructor for p, v of @
alert/print { a: 1, b: 2, c: [1,2], d:{pt:true, pf:false}, e:'test', f:false }.test()

Is it a bug?

This is kind of a bug, but I don't think we're ever going to fix it.
Extending Object in JavaScript is a pretty dangerous thing to do, because pretty much everything is an Object. There are serval places in the Framer Library where we iterate all the properties of an object expecting certain values.
One of these iterations is causing this bug.
If you absolutely need to do this, be prepared that your function can be called at any time, in any context and scope/binding. And even if you account for that, it may change the behaviour of the Framer Library in unexpected ways.
I'm closing this now, if you have more to add here please feel free to do so.

Alright thanks for the tip.


⚠ SceneTime has degraded performance

In be263db, SceneTime ($ST) experienced degraded performance:

HTTP code: 200
Response time: 3986 ms

Resolved: SceneTime performance has improved in 5171d83 after 8 minutes.


Test "middle"-decoder

PR to test middle decoder as discussed here.
test_middle_decoder.c file is added with images source font and RLE function

test_middle_decoder.h seems missing.

test_middle_decoder.h seems missing.

Effectively, I just added source images and RLE function, just for you to use it wherever your want. So, for that test_middle_decoder.c, the header would only declare this function:
extern lv_res_t          ICON_LVGL_runLength  (lv_img_decoder_t * decoder, lv_img_decoder_dsc_t * dsc);

I've tested and found some issue:

You need to call the built in open at the end
You need to tell that you can't process INDEXED_4 format to let it to built-in functions
I replaced the BOOL_E types with bool to compile it.

Now it works well for me:
    lv_img_decoder_t * decoder = lv_img_decoder_create();
    lv_img_decoder_set_open_cb(decoder, ICON_LVGL_runLength);
    lv_img_decoder_set_info_cb(decoder, lv_img_decoder_built_in_info);
    lv_img_decoder_set_read_line_cb(decoder, lv_img_decoder_built_in_read_line);
    lv_img_decoder_set_close_cb(decoder, lv_img_decoder_built_in_close);

    extern const lv_img_dsc_t RLE_ICONS[];
    lv_obj_t * img = lv_img_create(lv_scr_act(), NULL);
    lv_img_set_src(img, &RLE_ICONS[0]);

    extern const lv_img_dsc_t LVGL_GRADIENT_image[];
    img = lv_img_create(lv_scr_act(), NULL);
    lv_img_set_src(img, &LVGL_GRADIENT_image[1]);
    lv_obj_set_pos(img, 30, 30);

You need to tell that you can't process INDEXED_4 format to let it to built-in functions

Making this change works perfect for me. 😉

You need to call the built in open at the end

This is working for me without making call to the function lv_img_decoder_built_in_open(decoder, dsc);. Do you know why could this be possible? Maybe because of the change from LV_IMG_CF_USER_ENCODED_0 to LV_IMG_CF_ALPHA_4BIT. I do not fully understand the image drawing flow, but it seems reasonable what you purpose.

I replaced the BOOL_E types with bool to compile it.

Sorry for that, I am use to use BOOL_E enum and did not realize.

Making this change works perfect for me. wink

Great! :slightly_smiling_face:
I'll integrate the changes in master soon.

This is working for me without making call to the function ...

Actually, it's really possible because lv_img_decoder_built_in_open does nothing with ALPHA_X images. While I was trying to finding the issues I added it because it is logical to really open the image the preprocessed image.

Sorry for that, I am used to use BOOL_E enum and did not realize.

No problem.

Actually, it's really possible because lv_img_decoder_built_in_open does nothing with ALPHA_X images. While I was trying to finding the issues I added it because it is logical to really open the image the preprocessed image.

That is why, now I understand.
Feel free to merge any changes you want and make changes yourself!

I update the master manually.
One thing has changed: you need to add a custom info function too because from now the built-in supports only the built-in formats.
It worked for me:
lv_res_t ICON_LVGL_runLength_info(lv_img_decoder_t * decoder, const void * src, lv_img_header_t * header)
{
    (void)decoder; /*Unused*/

    lv_img_src_t src_type = lv_img_src_get_type(src);
    if(src_type == LV_IMG_SRC_VARIABLE) {
        lv_img_cf_t cf = ((lv_img_dsc_t *)src)->header.cf;
        if(cf != LV_IMG_CF_USER_ENCODED_0) return LV_RES_INV;

        header->w  = ((lv_img_dsc_t *)src)->header.w;
        header->h  = ((lv_img_dsc_t *)src)->header.h;
        header->cf = ((lv_img_dsc_t *)src)->header.cf;
        return LV_RES_OK;
    } else {
        return LV_RES_INV;
    }
}

Seems perfect to me 👍
I can't test it until monday though. I'll let you know then.

Working perfect 👍
I close the pull request.
Thanks!

Awesome! Thank you for the feedback!


How exactly am I supposed to use partials?

I was using hexo-renderer-hbs but needed more functionality so I decided to try this plugin. However, the documentation is sparse and gives only one weird example of calling partials: {{theme.author}}.
I changed the name of my partials folder (I had an underscore, which gave plenty of errors saying partials couldn't be found), but now I don't see any of my partials. The rest of my blog renders though.

Nvm, I'm dumb. Been staring at code too long.


panic: values with embedded slices uncomparable errors

Please see the stack trace here: https://travis-ci.org/opencontainers/image-spec/builds/132403826, described by opencontainers/image-spec#84.
Looks like pkg/errors#27 introduced or exposed a new error type that uses a slice and thus cannot be compared without introducing a panic. We picked this change up through an update to blackfriday, but this could happen anywhere.
While I understand that this library is based on concepts of no longer using sentinel values, this is already a common practice in existing code. There is also limited ways for a caller to avoid the panic.
I suggest that errors with a slice value use a pointer to the error value to avoid this trap in the future. For example, instead of building a stack{}, use &stack{}. This will ensure that existing code can make error comparisons while new code can begin to adopt this great package.

Thanks. I didn't consider that. I'll fix this immediately.

@davecheney Cheers!
I had never seen this either...

@davecheney Thanks for the quick fix!


Improve spacing between srcset widths

Description
In this changeset I derive an improved increment ratio for srcset generation from the width tolerance.
Before this patch the widths increase at a regularly-exponential rate until the second-largest width, then the largest width is equal to the maximum width. In all but some very particular cases this will mean the largest two widths are much more closely spaced than the others, in terms of the exponential scale at least. It is possible to have candidate widths of 8190 and 8192 pixels, for example, if the right minWidth, maxWidth, and widthTolerance values are chosen. (Obviously this is an extreme case.)
Checklist: Bug Fix

[x] Each commit follows the Conventional Commit format: e.g. chore(readme): fixed typo. See the end of this file for more information.
[x] All existing unit tests are still passing (if applicable)
[x] Add new passing unit tests to cover the code introduced by your PR (no brand-new tests, but adjusted affected existing ones and added a new clause to the test I added as part of #184 since the new code is no longer susceptible to the previously-failing case)
[x] Update the readme
[ ] Update or add any necessary API documentation (n/a)
[x] Add some steps so we can test your bug fix

Steps to Test
I think the changes to the tests already cover this, but as a realistic example where the difference is easier to see:
client.buildSrcSet('image.jpg', {}, {widthTolerance: 0.1, minWidth: 320, maxWidth: 1440})

Before the change:
320,384,460,552,664,796,956,1146,1376,1440
1600 +----------------------------------------------------------------------+
     |             +             +              +             +             |
     |                                                                      |
1400 |-+                                                             A    +-|
     |                                                        A             |
     |                                                                      |
     |                                                                      |
1200 |-+                                               A                  +-|
     |                                                                      |
     |                                                                      |
1000 |-+                                                                  +-|
     |                                          A                           |
     |                                                                      |
 800 |-+                                 A                                +-|
     |                                                                      |
     |                           A                                          |
 600 |-+                                                                  +-|
     |                    A                                                 |
     |                                                                      |
     |             A                                                        |
 400 |-+    A                                                             +-|
     |                                                                      |
     |             +             +              +             +             |
     +----------------------------------------------------------------------+

(this plot looks more bumpy than it really is due to ascii; the only important part is the sudden change in direction for the last value)

After the change:
320,378,448,528,624,738,872,1030,1218,1440
1600 +----------------------------------------------------------------------+
     |             +             +              +             +             |
     |                                                                      |
1400 |-+                                                             A    +-|
     |                                                                      |
     |                                                                      |
     |                                                        A             |
1200 |-+                                                                  +-|
     |                                                                      |
     |                                                 A                    |
1000 |-+                                                                  +-|
     |                                                                      |
     |                                          A                           |
 800 |-+                                                                  +-|
     |                                   A                                  |
     |                                                                      |
 600 |-+                         A                                        +-|
     |                                                                      |
     |                    A                                                 |
     |             A                                                        |
 400 |-+    A                                                             +-|
     |                                                                      |
     |             +             +              +             +             |
     +----------------------------------------------------------------------+

Note
I've built this on top of #184 since that was a bug I found while writing this and they touch some of the same code. As such, you may not need to review all commits; only the last two are strictly relevant. I can rebase it to be straight on top of main if you like.

I just identified a bug with this, where if I specify an odd maxWidth I can get a repeated value. Working on it.

I take it from the lack of comments so far that this hasn't been reviewed yet, so I'm going to meld my fix to the existing commits.

The failing set of cases included min 1000, max 1001. In this case it decided 1 step is necessary, decided on the increment factor, then calculated the next stop as being (in this case) something like 1000.99999 due to floating point error. Then ensureEven rounded that to 1000, which was the same as the previous width we stored in the array.
I fixed this with a check for whether the running fractional width rounds to the target width. If so, it doesn't run ensureEven.

Hey @tremby! @imgix would really like to thank you so much for the activity on this repo! Unfortunately this is a change that we are not on board with, and I'd like to explain a bit why, because we value our contributor's contributions and don't want you to think that we are just dismissing this without reason.
Firstly, we place large weight on changes to this behaviour, since this would require changes to ~20 of our libraries, since we require 100% consistency across all our SDK libraries for the srcset generation feature. This is important for cache performance.
Mainly, I think the fundamental problem with this PR for us is that it shifts the goal of the srcset feature away from the goal it was designed for, to an arbitrary goal. Our original goal with this srcset feature was to achieve a suitable trade-off between visual performance, bandwidth usage, and cache hits. This is the reasoning between the width tolerance of 8%, which was very intentionally chosen.  Therefore, it's important for us that the widths scale up according to this increment percentage every time, because this will ensure optimal performance across the majority (99%) of browser widths and images.
If we were to adopt this PR, we would be shifting our goal towards something like "smoothness of the srcset widths curve", or "making sure that every value is correctly spaced from every other value", rather than the aforementioned goal. This is not a trade-off we are willing to make, as we value the original goal of this feature, even if that causes small irregularities.
We do understand that the issue you raised is an issue/"bug" with our srcset-generation logic, but as with most problems, no solution is perfect, and in this case this is a trade-off we feel that should make.
Furthermore, I think the irregularity at the top end of the srcset range is a small issue since it will only affect a very small subset of users. Also, I think the goal of optimizing for this 100-8192px range is the wrong way to look at it. Honestly the 8192px hard limit is a constraint of the imgix API, and this will be changed in the future. It would be bad for cache performance in the future that when we change this, all the widths would change and thus all the caches would be invalidated. Instead, it is more important for us that these images remain in the cache, independent of this hard limit.
And, finally, another small reason why I didn't like this change is because it makes the program not directly follow the developer's input. Right now, the width tolerance is very direct and easy to understand for developers - "If I set width_tolerance to 0.10, that means each width will increase by 10% every time", whereas with this change, they would no longer have control over how much the widths would change every time, which could be frustrating, and we don't want to take this clarity away from them.
Anyway! That was a bit of a wall of text, but I would like to thank you again for investigating this real issue in our logic, and working on a fix for us! We really do appreciate it, and we are welcome to review/discuss any other changes in the future that you might think would improve our libraries.

I'm rather confused about this decision.

this would require changes to ~20 of our libraries, since we require 100% consistency across all our SDK libraries for the srcset generation feature.

Show me the libraries and I could do the legwork for you!

This is the reasoning between the width tolerance of 8%, which was very intentionally chosen.

But that's just a default, and it's overrideable by the developer. In my opinion it's a much-too-small default (I'd be interested to understand exactly how 8% was decided upon), but that's not the point anyway. The fact is that my changes result in the exact same number of steps being produced as before the change. So I'm not sure what you're getting at here.

Therefore, it's important for us that the widths scale up according to this increment percentage every time, because this will ensure optimal performance across the majority (99%) of browser widths and images.

I don't follow your logic here at all. The developer chooses the minWidth, maxWidth, and widthTolerance. In light of that, how does setting the default tolerance to 8% "ensure optimal performance"? Why would the same number of steps but smoothly spaced (which would perhaps mean the step is 7.5% rather than 8% for a given minWidth and maxWidth) change that performance?
(Though I absolutely agree that performance is important (and don't think this change is harming it in any way) I can't help but be surprised about the level of weight you're putting on it here given both the (very low in my opinion) 8% default tolerance and the categorical ignorance of cacheability and performance over in your React background image component! https://github.com/imgix/react-imgix/issues/672)

If we were to adopt this PR, we would be shifting our goal towards something like "smoothness of the srcset widths curve", or "making sure that every value is correctly spaced from every other value", rather than the aforementioned goal.

Again I don't follow. I don't see how this change affects "visual performance, bandwidth usage, and cache hits" other than if somebody updates and so their srcset changes, and so there are some cache misses the first time each size is requested. Again, I'll point out that the same number of steps are being generated under this algorithm. The way I see it your initial goals are still all met, and additionally the spacings are smooth, which can only be an improvement.

Furthermore, I think the irregularity at the top end of the srcset range is a small issue since it will only affect a very small subset of users.

Surely nobody intentionally leaves maxWidth at the default of 8192 pixels? As I've mentioned in other tickets, the default settings cause most images to be upscaled enormously, which no matter which way you look at it is a horrible waste of resources both on your server side and for the user.
The irregularity at the top end of the srcset range would affect many more users where maxWidth has been set to something reasonable (i.e. the actual width of the source image). So I don't think the bug should be discounted for the reason you give.

Also, I think the goal of optimizing for this 100-8192px range is the wrong way to look at it.

There's no optimization for that particular range in this code. I wonder if you misunderstood how the code works?

Determine how many steps would be generated using the given widthTolerance precisely -- this is the number of steps the library currently generates before this patch. This is fast, done with a couple of logarithms; no iteration.
Adjust the scale factor to produce that same number of steps smoothly. This is also fast, done with an exponent (nth-root).

Nothing to do with the 100-8192 range is hardcoded.

It would be bad for cache performance in the future that when we change this, all the widths would change and thus all the caches would be invalidated.

This is fair enough, and would affect existing images for users who upgrade their library. But it's not like everybody's going to do so, and certainly not simultaneously. It's also a one-time thing. You know your infrastructure better than I do, but I'd be surprised if this is a big issue.

And, finally, another small reason why I didn't like this change is because it makes the program not directly follow the developer's input. Right now, the width tolerance is very direct and easy to understand for developers - "If I set width_tolerance to 0.10, that means each width will increase by 10% every time", whereas with this change, they would no longer have control over how much the widths would change every time, which could be frustrating, and we don't want to take this clarity away from them.

I seriously doubt any developer is thinking this way. I don't think many developers care exactly what increment is between the candidate sizes, and I'd wager that many of those who do probably expect a linear increase in widths rather than an exponential one anyway. As I said above I'd expect maxWidth and minWidth are being set in the vast majority of cases anyway, which would mean per image they're getting a different range of candidate widths regardless.
But the option is called "width tolerance", not "precise scale factor". The algorithm both before and after this change works as advertised, and sticks to that given amount of tolerance. My change to the code causes the scale factor to stay the same or to shrink minimally, never increase, so the tolerance the developer requested is always still met.
The existing code does not follow the requested factor for each increment in most cases -- the last gap is usually smaller -- which is exactly what this change addresses.
I wonder if you'll reconsider this.

The only reduced performance I can begin to see here is if more different images are being requested from your server as users resize their browser viewports or use different-sizes devices, after this change compared to before.
Yes, the gaps between candidate images will for the most part be slightly smaller, and so it's possible more different image sizes will be requested, assuming requests for the different candidate widths follow something resembling a bell curve.
But seeing that as "bad" requires the leap in logic that an 8% gap between image widths is acceptable (or perfect -- you did say it was very intentionally chosen) while slightly less than 8% is unacceptable. I really have to question this. If that is indeed the line of thinking, it seems to me the solution would be just to increase the default a little.
If my maths is right, the most the requested ratio can be reduced by my code is to cut it exactly in half (actually a mite under that due to floating point error), and this only happens in precisely the cases where the existing library's code would make exactly three candidates (where in my code numSteps would be calculated as 2), and where the last two are just 1 or 2 pixels apart in width. Example: with minWidth 615 and maxWidth 665 and 8% increases the old code gives 615, 664, 665. The changed code here would give 615, 640, 665. This is an edge case, and in my opinion the second sourceset is much more useful than the first.
This, by the way, is the most realistic example I could find of this edge case, and I brute-force searched the domain of min from 10 to 2000 and max from 20 to 8192 in increments of 5 pixels each, always with 8% requested step. This totals 567,138 possible ranges.
Taking into account only srcsets with 3 or more members (since 2 would heavily skew the results and would be the same before and after this code change anyway), over the entire range I brute-forced just now including the edge cases I mentioned above, the average calculated step was 7.7175%. Surely we can agree that this is not a big change from 8%.
Maybe the piece of the puzzle I'm missing is why 8% is special.
The code for my brute-force search:
const ratios = [];
let minRatio = Infinity;
for (let min = 10; min <= 2000; min += 5) {
	for (let max = 20; max <= 8192; max += 5) {
		if (max <= min) continue;
		var numSteps = Math.ceil(Math.log(max / min) / Math.log(1.08));
		var adjustedIncrementRatio = Math.pow(max / min, 1 / numSteps);
		if (numSteps <= 1) continue;
		ratios.push(adjustedIncrementRatio);
		if (adjustedIncrementRatio <= 1.04) {
			console.log("min", min, "max", max, "steps", numSteps, "ratio", adjustedIncrementRatio);
		}
		if (adjustedIncrementRatio < minRatio) {
			minRatio = adjustedIncrementRatio;
		}
	}
}
console.log("avg over", ratios.length, "sets is", ratios.reduce((acc, r) => acc + r, 0) / ratios.length);
console.log("min is", minRatio);

Hey @tremby
I wanted to start by saying thanks again for the time and effort put into this PR and ensuing discussion. Our team is always excited to have these types of discussions with users, as it helps inform our understanding of how our SDK can be improved. Often times, part of this process requires that our team make choices about contributions based on the larger context that we have at an organizational level. We do our best to incorporate outside-contributions in each project, assuming they are aligned enough with that larger context, but can't promise everything will make it in. So to that end, I ask that you respect the project maintainers' decision not to merge this change and try to understand their position.
I also ask that you please kindly refrain from using a hostile tone when partaking in these discussions. As I said, this type of discourse is very important to us, but will only get so far if there is an aggressive atmosphere. Ultimately we are all working towards the same goal, so let’s try to be respectful even if there are differing ideas about what should/shouldn’t be implemented.


[move-package] Move package cli

This PR builds on PR #9030 and adds CLI support for the package system. It adds support for three basic Move Package commands to the CLI. Currently, these are:

move package build: build the package
move package errmap: build an errmap for the package (and its dependencies)
move package prove: run the Move Prover on the package. Note that the package is currently subject to restrictions in #9030. Prover flags can be passed through this command as well.

This PR does not add unit testing support, that will be a separate PR.
In the process of adding support the Move CLI lib.rs was getting a bit hard to follow, so I refactored the CLI structure so that each subcommand module holds its CLI args and argument handler. This PR does not convert the CLI over to using the package system, nor does it convert over the move-stdlib and diem-framework. These will be done in upcoming PRs.

/land


Segmentation fault (core dumped)

Hey, thanks for your great work! When I run "pip3 -install requirements.txt" I get the following error at the end :
Installing collected packages: six, numpy, h5py, torch, pillow, torchvision, pyyaml, pprint, enum34, future, scipy, opencv-contrib-python, python-dateutil, cycler, kiwisolver, pyparsing, matplotlib, transforms3d, decorator, networkx, PyWavelets, scikit-image, lmdb, setuptools, pycparser, cffi, easydict, plyfile, cython, triangle, glumpy
Successfully installed PyWavelets-1.1.1 cffi-1.11.5 cycler-0.10.0 cython-0.29.17 decorator-4.4.2 easydict-1.7 enum34-1.1.10 future-0.18.2 glumpy-1.0.6 h5py-2.10.0 kiwisolver-1.2.0 lmdb-0.98 matplotlib-3.1.1 networkx-2.4 numpy-1.18.4 opencv-contrib-python-<IP_ADDRESS> pillow-7.1.2 plyfile-0.6 pprint-0.1 pycparser-2.20 pyparsing-2.4.7 python-dateutil-2.8.1 pyyaml-5.3.1 scikit-image-0.13.1 scipy-1.3.1 setuptools-46.4.0 six-1.14.0 torch-1.5.0 torchvision-0.4.0 transforms3d-0.3.1 triangle-20200424
Segmentation fault (core dumped)
I am using Ubuntu 18.04 , Python 3.7 and gcc version 7.5.0 if it matters :)
Would be really nice if someone could help me

The Segmentation fault comes from  pip3 install cffi==1.11.5 , it seems like it is a pip bug. Can be closed


Add redirect URL in login

login page always redirects to the home page after successful login. It would be nice if we redirect user to the page from which he clicked the log-in button.
For example:
Go on any book details page. After that click on the login button, you will now be redirected to the login page. After successful login, you will be redirected to the home page. But you should be redirected to the same book details page which was opened earlier.
You can achieve this functionality by providing route path as "/login/:redirect" and when clicked on the login button it should redirect to "/login/<current_url>". After successful login, redirect page to URL that was passed as <current_url>. If the redirect URL is not present, then redirect the user to the home page.

@DKumar2169 Yes, you can work on this. I have assigned it to you. Feel free to ask any doubt.

okay Thanks
so can you specify what files to changes/access

so can you specify what files to changes/access

You will have to make changes in these files:

App.js
Login.js
Navbar.js
Sidenav.js

I think this would be sufficient. You can explore more and figure out what more files are needed to be changed to implement this feature.

can i work on this?


Feature: Set renderer for inserted item

Right now we can manage how the search results are displayed in the list. I'd like to be able to modify the rendered Html-Output, too.

Sorry for late response @angelak! If you want to add this functionality, I can give you commit access to this repo.


Implement Graylog data logs

Implement graylog for data logs and logs should not be inside admin console
Log paths should be dynamic instead of being hard-coded

To be analysed

@htvenkatesh - please plan to add this in the sprints for February for roadmap v5.0.

Currently not taken up . To be considered for the road map

Added in the Roadmap


Mistakes or not?

Visual Studio warns for some potential issues in the "unitegallery.js" (not minimized) module. Please, check if the following are mistakes:
Function "scaleImageFitParent". There is a couple of assignments (?) which look like conditions instead:
updateCss == true
Function "onTouchEnd". Same as above:
g_temp.isPanActive == false;
Function "hideArrows". The if's trailing semicolon is probably wrong:
if(isMouseInsideImage() == true);
I temporarily patched my cached copy of the module.

HI, thank you (and visual studio :)
Fixed those mistakes, made commit at github. you can download new version
if you want.
On Wed, Jan 13, 2016 at 11:52 AM, Mario Vernari<EMAIL_ADDRESS>wrote:

Visual Studio warns for some potential issues in the "unitegalleryjs" (not
minimized) module Please, check if the following are mistakes:
Function "scaleImageFitParent" There is a couple of assignments (?) which
look like conditions instead:
updateCss == true
Function "onTouchEnd" Same as above:
g_tempisPanActive == false;
Function "hideArrows" The if's trailing semicolon is probably wrong:
if(isMouseInsideImage() == true);
I temporarily patched my cached copy of the module
—
Reply to this email directly or view it on GitHub
https://github.com/vvvmax/unitegallery/issues/50.

Many thanks, but did you checked the last point as well? The latest commit keeps the suspect semicolon: https://github.com/vvvmax/unitegallery/blob/master/package/unitegallery/js/unitegallery.js#L21913
Just to validate it: JavaScript is tricky (too much for me, at least!).

yes, I fixed the last issue as well. weird. But, if the gallery is working
then it's ok, you don't have to worry about it.
On Thu, Jan 14, 2016 at 12:17 PM, Mario Vernari<EMAIL_ADDRESS>wrote:

Many thanks, but did you checked the last point as well? The latest commit
keeps the suspect semicolon:
https://github.com/vvvmax/unitegallery/blob/master/package/unitegallery/js/unitegallery.js#L21913
Just to validate it: JavaScript is tricky (too much for me, at least!).
—
Reply to this email directly or view it on GitHub
https://github.com/vvvmax/unitegallery/issues/50#issuecomment-171595838.


[BUG] Crash: EXC_BAD_ACCESS (KERN_INVALID_ADDRESS)

General information

Superwall version: 3.6.2 (this is the most recent version the crashes are reported from, but I have reports from previous versions as well. Not specific to this Superwall release probably.)
iOS version(s): 17.4.1 (the copied stack trace that is. The crash is reported from various iOS 16.x and 17.x versions so not specific to an iOS version)
Xcode version: 15.4
Devices/Simulators affected: iPhone (recent ones, the crash is not specific to model. eg. 11, 12, 13, 14, 15 pro and max devices included as well)

Describe the bug
This is my number one crash since I adopted Superwall (around early April). I have crash reports affecting 59 users from the past 7 days. As far as I can tell EXC_BAD_ACCESS (KERN_INVALID_ADDRESS) might be related to memory management, for example a race condition. In the crash report the following code is marked as culprit: type metadata accessor for PassthroughSubject<PaywallState, Never>. It happens when the app was already running for a while (I think maybe during a paywall presentation - not sure), not on app launch.
Sample code how I integrated Superwall:
enum FeatureWallPresentationContext: CustomStringConvertible, Hashable, Equatable {

    case context1(isFunny: Bool), context2, context3

    var description: String { "hoho" }
    var superWallCampaign: String { "haha" }
}

private func presentWall(context: FeatureWallPresentationContext) async {
    let superWallCampaignName = context.superWallCampaign
    let handler = PaywallPresentationHandler()
    handler.onDismiss { _ in
    // removed for legibility
    }
    handler.onPresent { _ in
    // removed for legibility
    }
    handler.onError { _ in
    // removed for legibility
    }
    handler.onSkip { _ in
    // removed for legibility
    }
    Superwall.shared.register(event: superWallCampaignName,
                                      params: ["featureWall": context],
                                      handler: handler) {
    // feature to be executed
    }
}

Steps to reproduce
I can't reproduce on my side. If it's a race condition that's very hard unfortunately. Usually the best way to fix is to try to remove the possibility of a race condition by ensuring that the resource is accessed from a single thread at a time (or at least writing happens in a barrier) using GCD, atomic wrappers, Swift actors, etc. Though sometimes can be reproduced with some loops that call the affected code path from many threads at the same time but this is when you feel lucky.
Other Information
Stack trace:
# Crashlytics - Stack trace
# Application: com.adamszedelyi.snapme
# Platform: apple
# Version: 62 (3604)
# Issue: 482322a988472deec232163b2a6fc8ad
# Session: da83a7636c244a279a06dbfa60daa5b0_DNE_0_v2
# Date: Sun May 26 2024 08:51:01 GMT-0700 (Pacific Daylight Time)

com.apple.main-thread
0   libswiftCore.dylib             0x2016b8 _stringCompareInternal(_:_:expecting:) + 504
1   SwiftUI                        0x27d178 OUTLINED_FUNCTION_0 + 32008
2   SwiftUI                        0x278b20 OUTLINED_FUNCTION_0 + 14000
3   SwiftUI                        0x279c0c OUTLINED_FUNCTION_0 + 18332
4   SwiftUI                        0x279558 OUTLINED_FUNCTION_0 + 16616
5   SwiftUI                        0x27b190 OUTLINED_FUNCTION_0 + 23840
6   SwiftUI                        0xcae880 OUTLINED_FUNCTION_20 + 13300
7   SwiftUI                        0x105f814 OUTLINED_FUNCTION_0 + 852
8   SwiftUI                        0xcae880 OUTLINED_FUNCTION_20 + 13300
9   SwiftUI                        0xcadc8c OUTLINED_FUNCTION_20 + 10240
10  SwiftUI                        0x57030c OUTLINED_FUNCTION_39 + 2896180
11  AttributeGraph                 0xc240 AG::Graph::UpdateStack::update() + 512
12  AttributeGraph                 0x2f38 AG::Graph::update_attribute(AG::data::ptr<AG::Node>, unsigned int) + 424
13  AttributeGraph                 0x2810 AG::Graph::input_value_ref_slow(AG::data::ptr<AG::Node>, AG::AttributeID, unsigned int, unsigned int, AGSwiftMetadata const*, unsigned char&, long) + 720
14  AttributeGraph                 0x23a4 AGGraphGetValue + 228
15  SwiftUI                        0xef88b4 OUTLINED_FUNCTION_0 + 33052
16  SwiftUI                        0x570378 OUTLINED_FUNCTION_39 + 2896288
17  AttributeGraph                 0xc240 AG::Graph::UpdateStack::update() + 512
18  AttributeGraph                 0x2f38 AG::Graph::update_attribute(AG::data::ptr<AG::Node>, unsigned int) + 424
19  AttributeGraph                 0x2630 AG::Graph::input_value_ref_slow(AG::data::ptr<AG::Node>, AG::AttributeID, unsigned int, unsigned int, AGSwiftMetadata const*, unsigned char&, long) + 240
20  AttributeGraph                 0xcf9c AGGraphGetInputValue + 248
21  SwiftUI                        0xa9cbf8 OUTLINED_FUNCTION_6 + 228
22  SwiftUI                        0xbeb824 OUTLINED_FUNCTION_5 + 552
23  SwiftUI                        0xbeba50 OUTLINED_FUNCTION_5 + 1108
24  SwiftUI                        0xbebdd4 OUTLINED_FUNCTION_5 + 2008
25  SwiftUI                        0xf1c168 OUTLINED_FUNCTION_13 + 78480
26  SwiftUI                        0xf1bfec OUTLINED_FUNCTION_13 + 78100
27  SwiftUI                        0xf1bc90 OUTLINED_FUNCTION_13 + 77240
28  SwiftUI                        0x18962ac OUTLINED_FUNCTION_12 + 8368
29  SwiftUI                        0xa9d01c OUTLINED_FUNCTION_6 + 1288
30  SwiftUI                        0x18c0674 OUTLINED_FUNCTION_35 + 8364
31  SwiftUI                        0x12493a4 OUTLINED_FUNCTION_0 + 59036
32  SwiftUI                        0x1249170 OUTLINED_FUNCTION_0 + 58472
33  SwiftUI                        0x18962ac OUTLINED_FUNCTION_12 + 8368
34  SwiftUI                        0xc11aac OUTLINED_FUNCTION_19 + 1388
35  SwiftUI                        0xc12294 OUTLINED_FUNCTION_19 + 3412
36  SwiftUI                        0xf1c168 OUTLINED_FUNCTION_13 + 78480
37  SwiftUI                        0xf1bfec OUTLINED_FUNCTION_13 + 78100
38  SwiftUI                        0xf1bc90 OUTLINED_FUNCTION_13 + 77240
39  SwiftUI                        0x18962ac OUTLINED_FUNCTION_12 + 8368
40  SwiftUI                        0x176ce68 block_destroy_helper + 4776
41  SwiftUI                        0x176d8d4 block_destroy_helper + 7444
42  SwiftUI                        0xf1c168 OUTLINED_FUNCTION_13 + 78480
43  SwiftUI                        0xf1bfec OUTLINED_FUNCTION_13 + 78100
44  SwiftUI                        0xf1bc90 OUTLINED_FUNCTION_13 + 77240
45  SwiftUI                        0x18962ac OUTLINED_FUNCTION_12 + 8368
46  SwiftUI                        0xce8000 OUTLINED_FUNCTION_1 + 12628
47  SwiftUI                        0xce8c3c OUTLINED_FUNCTION_1 + 15760
48  SwiftUI                        0xce68b0 OUTLINED_FUNCTION_1 + 6660
49  SwiftUI                        0xbfa9b4 OUTLINED_FUNCTION_1 + 2648
50  SwiftUI                        0xbfb0c4 OUTLINED_FUNCTION_1 + 4456
51  SwiftUI                        0x12493a4 OUTLINED_FUNCTION_0 + 59036
52  SwiftUI                        0x1249170 OUTLINED_FUNCTION_0 + 58472
53  SwiftUI                        0x18962ac OUTLINED_FUNCTION_12 + 8368
54  SwiftUI                        0xce8000 OUTLINED_FUNCTION_1 + 12628
55  SwiftUI                        0xce8c3c OUTLINED_FUNCTION_1 + 15760
56  SwiftUI                        0xce68b0 OUTLINED_FUNCTION_1 + 6660
57  SwiftUI                        0xbfa9b4 OUTLINED_FUNCTION_1 + 2648
58  SwiftUI                        0xbfb0c4 OUTLINED_FUNCTION_1 + 4456
59  SwiftUI                        0x12493a4 OUTLINED_FUNCTION_0 + 59036
60  SwiftUI                        0x1249170 OUTLINED_FUNCTION_0 + 58472
61  SwiftUI                        0x18962ac OUTLINED_FUNCTION_12 + 8368
62  SwiftUI                        0x176ce68 block_destroy_helper + 4776
63  SwiftUI                        0x176d8d4 block_destroy_helper + 7444
64  SwiftUI                        0xf1c168 OUTLINED_FUNCTION_13 + 78480
65  SwiftUI                        0xf1bfec OUTLINED_FUNCTION_13 + 78100
66  SwiftUI                        0xf1bc90 OUTLINED_FUNCTION_13 + 77240
67  SwiftUI                        0x1894940 OUTLINED_FUNCTION_12 + 1860
68  SwiftUI                        0x1896350 OUTLINED_FUNCTION_12 + 8532
69  SwiftUI                        0xe9004c block_destroy_helper + 1448
70  SwiftUI                        0xce8494 OUTLINED_FUNCTION_1 + 13800
71  SwiftUI                        0xce7c90 OUTLINED_FUNCTION_1 + 11748
72  SwiftUI                        0xce8c3c OUTLINED_FUNCTION_1 + 15760
73  SwiftUI                        0xce68b0 OUTLINED_FUNCTION_1 + 6660
74  SwiftUI                        0xbfa9b4 OUTLINED_FUNCTION_1 + 2648
75  SwiftUI                        0xbfb0c4 OUTLINED_FUNCTION_1 + 4456
76  SwiftUI                        0x12493a4 OUTLINED_FUNCTION_0 + 59036
77  SwiftUI                        0x1249170 OUTLINED_FUNCTION_0 + 58472
78  SwiftUI                        0x18962ac OUTLINED_FUNCTION_12 + 8368
79  SwiftUI                        0x176ce68 block_destroy_helper + 4776
80  SwiftUI                        0x176d8d4 block_destroy_helper + 7444
81  SwiftUI                        0xf1c168 OUTLINED_FUNCTION_13 + 78480
82  SwiftUI                        0xf1bfec OUTLINED_FUNCTION_13 + 78100
83  SwiftUI                        0xf1bc90 OUTLINED_FUNCTION_13 + 77240
84  SwiftUI                        0x18962ac OUTLINED_FUNCTION_12 + 8368
85  SwiftUI                        0x176ce68 block_destroy_helper + 4776
86  SwiftUI                        0x176d8d4 block_destroy_helper + 7444
87  SwiftUI                        0xf1c168 OUTLINED_FUNCTION_13 + 78480
88  SwiftUI                        0xf1bfec OUTLINED_FUNCTION_13 + 78100
89  SwiftUI                        0xf1bc90 OUTLINED_FUNCTION_13 + 77240
90  SwiftUI                        0x1894940 OUTLINED_FUNCTION_12 + 1860
91  SwiftUI                        0x1896350 OUTLINED_FUNCTION_12 + 8532
92  SwiftUI                        0xe9004c block_destroy_helper + 1448
93  SwiftUI                        0xce8494 OUTLINED_FUNCTION_1 + 13800
94  SwiftUI                        0xce7c90 OUTLINED_FUNCTION_1 + 11748
95  SwiftUI                        0xce8c3c OUTLINED_FUNCTION_1 + 15760
96  SwiftUI                        0xce68b0 OUTLINED_FUNCTION_1 + 6660
97  SwiftUI                        0xbfa9b4 OUTLINED_FUNCTION_1 + 2648
98  SwiftUI                        0xbfb0c4 OUTLINED_FUNCTION_1 + 4456
99  SwiftUI                        0x12493a4 OUTLINED_FUNCTION_0 + 59036
100 SwiftUI                        0x1249170 OUTLINED_FUNCTION_0 + 58472
101 SwiftUI                        0x1894940 OUTLINED_FUNCTION_12 + 1860
102 SwiftUI                        0x1896350 OUTLINED_FUNCTION_12 + 8532
103 SwiftUI                        0xe902cc block_destroy_helper + 2088
104 SwiftUI                        0xce8494 OUTLINED_FUNCTION_1 + 13800
105 SwiftUI                        0xce7c90 OUTLINED_FUNCTION_1 + 11748
106 SwiftUI                        0xce8c3c OUTLINED_FUNCTION_1 + 15760
107 SwiftUI                        0xce68b0 OUTLINED_FUNCTION_1 + 6660
108 SwiftUI                        0xbfa9b4 OUTLINED_FUNCTION_1 + 2648
109 SwiftUI                        0xbfb0c4 OUTLINED_FUNCTION_1 + 4456
110 SwiftUI                        0x12493a4 OUTLINED_FUNCTION_0 + 59036
111 SwiftUI                        0x1249170 OUTLINED_FUNCTION_0 + 58472
112 SwiftUI                        0x18962ac OUTLINED_FUNCTION_12 + 8368
113 SwiftUI                        0xa9d01c OUTLINED_FUNCTION_6 + 1288
114 SwiftUI                        0x18c0674 OUTLINED_FUNCTION_35 + 8364
115 SwiftUI                        0x12493a4 OUTLINED_FUNCTION_0 + 59036
116 SwiftUI                        0x1249170 OUTLINED_FUNCTION_0 + 58472
117 SwiftUI                        0x18962ac OUTLINED_FUNCTION_12 + 8368
118 SwiftUI                        0x1459544 OUTLINED_FUNCTION_17 + 4136
119 SwiftUI                        0xf1c168 OUTLINED_FUNCTION_13 + 78480
120 SwiftUI                        0xf1bfec OUTLINED_FUNCTION_13 + 78100
121 SwiftUI                        0xf1c1a0 OUTLINED_FUNCTION_13 + 78536
122 SwiftUI                        0x18962ac OUTLINED_FUNCTION_12 + 8368
123 SwiftUI                        0x107dd68 OUTLINED_FUNCTION_1 + 14904
124 SwiftUI                        0x1249894 OUTLINED_FUNCTION_0 + 60300
125 SwiftUI                        0x12495cc OUTLINED_FUNCTION_0 + 59588
126 SwiftUI                        0x18963cc OUTLINED_FUNCTION_12 + 8656
127 SwiftUI                        0xf72028 OUTLINED_FUNCTION_197 + 322160
128 AttributeGraph                 0xc240 AG::Graph::UpdateStack::update() + 512
129 AttributeGraph                 0x2f38 AG::Graph::update_attribute(AG::data::ptr<AG::Node>, unsigned int) + 424
130 AttributeGraph                 0xd948 AG::Subgraph::update(unsigned int) + 848
131 SwiftUI                        0x1661fbc OUTLINED_FUNCTION_3 + 14788
132 SwiftUI                        0x1663618 OUTLINED_FUNCTION_3 + 20512
133 SwiftUI                        0xc86b30 OUTLINED_FUNCTION_18 + 43008
134 SwiftUI                        0x1732154 OUTLINED_FUNCTION_2 + 13932
135 SwiftUI                        0x173080c OUTLINED_FUNCTION_2 + 7460
136 SwiftUI                        0xc7dce4 OUTLINED_FUNCTION_18 + 6580
137 SwiftUI                        0x16635e0 OUTLINED_FUNCTION_3 + 20456
138 SwiftUI                        0x16634cc OUTLINED_FUNCTION_3 + 20180
139 SwiftUI                        0x102d914 OUTLINED_FUNCTION_8 + 52
140 SwiftUI                        0x67a548 OUTLINED_FUNCTION_3 + 33832
141 SwiftUI                        0x67a494 OUTLINED_FUNCTION_3 + 33652
142 SwiftUI                        0x67a5ec OUTLINED_FUNCTION_3 + 33996
143 CoreFoundation                 0x35d3c __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 36
144 CoreFoundation                 0x34738 __CFRunLoopDoObservers + 552
145 CoreFoundation                 0x33e50 __CFRunLoopRun + 1028
146 CoreFoundation                 0x33968 CFRunLoopRunSpecific + 608
147 GraphicsServices               0x34e0 GSEventRunModal + 164
148 UIKitCore                      0x22aedc -[UIApplication _run] + 888
149 UIKitCore                      0x22a518 UIApplicationMain + 340
150 photographer                   0x4090 main + 25 (main.swift:25)
151 ???                            0x1c2d2ad84 (Missing)

Thread
0  libsystem_kernel.dylib         0xa084 __workq_kernreturn + 8
1  libsystem_pthread.dylib        0x1f6c _pthread_wqthread + 364
2  libsystem_pthread.dylib        0x1fc0 start_wqthread + 8

com.apple.uikit.eventfetch-thread
0  libsystem_kernel.dylib         0x1af8 mach_msg2_trap + 8
1  libsystem_kernel.dylib         0x1890 mach_msg2_internal + 80
2  libsystem_kernel.dylib         0x17a8 mach_msg_overwrite + 436
3  libsystem_kernel.dylib         0x15e8 mach_msg + 24
4  CoreFoundation                 0x3601c __CFRunLoopServiceMachPort + 160
5  CoreFoundation                 0x33f04 __CFRunLoopRun + 1208
6  CoreFoundation                 0x33968 CFRunLoopRunSpecific + 608
7  Foundation                     0x2b4a8 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
8  Foundation                     0x554e8 -[NSRunLoop(NSRunLoop) runUntilDate:] + 64
9  UIKitCore                      0x18dac8 -[UIEventFetcher threadMain] + 420
10 Foundation                     0x9ca9c __NSThread__start__ + 732
11 libsystem_pthread.dylib        0x2a90 _pthread_start + 136
12 libsystem_pthread.dylib        0x1fcc thread_start + 8

Crashed: com.apple.root.user-initiated-qos.cooperative
0  libswiftCore.dylib             0x3ab354 _swift_release_dealloc + 32
1  libswiftCore.dylib             0x3ac488 bool swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1> >::doDecrementSlow<(swift::PerformDeinit)1>(swift::RefCountBitsT<(swift::RefCountInlinedness)1>, unsigned int) + 136
2  photographer                   0x9aa5e0 type metadata accessor for PassthroughSubject<PaywallState, Never> +<PHONE_NUMBER>
3  libswiftCore.dylib             0x3ab36c _swift_release_dealloc + 56
4  libswiftCore.dylib             0x3ac488 bool swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1> >::doDecrementSlow<(swift::PerformDeinit)1>(swift::RefCountBitsT<(swift::RefCountInlinedness)1>, unsigned int) + 136
5  photographer                   0x9a9c08 closure #2 in Superwall.publisher(forEvent:params:paywallOverrides:isFeatureGatable:) + 250 (PublicPresentation.swift:250)
6  libswiftCore.dylib             0x3ab36c _swift_release_dealloc + 56
7  libswiftCore.dylib             0x3ac488 bool swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1> >::doDecrementSlow<(swift::PerformDeinit)1>(swift::RefCountBitsT<(swift::RefCountInlinedness)1>, unsigned int) + 136
8  libswift_Concurrency.dylib     0x557a4 completeTaskWithClosure(swift::AsyncContext*, swift::SwiftError*) + 48
9  libswift_Concurrency.dylib     0x4d764 swift::runJobInEstablishedExecutorContext(swift::Job*) + 436
10 libswift_Concurrency.dylib     0x4e9c8 swift_job_runImpl(swift::Job*, swift::ExecutorRef) + 72
11 libdispatch.dylib              0x15894 _dispatch_root_queue_drain + 392
12 libdispatch.dylib              0x1609c _dispatch_worker_thread2 + 156
13 libsystem_pthread.dylib        0x1ee4 _pthread_wqthread + 228
14 libsystem_pthread.dylib        0x1fc0 start_wqthread + 8

Thread
0  libsystem_kernel.dylib         0xa084 __workq_kernreturn + 8
1  libsystem_pthread.dylib        0x1f6c _pthread_wqthread + 364
2  libsystem_pthread.dylib        0x1fc0 start_wqthread + 8

Thread
0  libsystem_pthread.dylib        0x1fb8 start_wqthread + 438

com.google.firebase.crashlytics.MachExceptionServer
0  photographer                   0x7d02d8 FIRCLSProcessRecordAllThreads + 392 (FIRCLSProcess.c:392)
1  photographer                   0x7d06b8 FIRCLSProcessRecordAllThreads + 423 (FIRCLSProcess.c:423)
2  photographer                   0x7de724 FIRCLSHandler + 34 (FIRCLSHandler.m:34)
3  photographer                   0x7def28 FIRCLSMachExceptionServer + 521 (FIRCLSMachException.c:521)
4  libsystem_pthread.dylib        0x2a90 _pthread_start + 136
5  libsystem_pthread.dylib        0x1fcc thread_start + 8

com.apple.CoreMotion.MotionThread
0  libsystem_kernel.dylib         0x1af8 mach_msg2_trap + 8
1  libsystem_kernel.dylib         0x1890 mach_msg2_internal + 80
2  libsystem_kernel.dylib         0x17a8 mach_msg_overwrite + 436
3  libsystem_kernel.dylib         0x15e8 mach_msg + 24
4  CoreFoundation                 0x3601c __CFRunLoopServiceMachPort + 160
5  CoreFoundation                 0x33f04 __CFRunLoopRun + 1208
6  CoreFoundation                 0x33968 CFRunLoopRunSpecific + 608
7  CoreFoundation                 0x336cc CFRunLoopRun + 64
8  CoreMotion                     0x2e93c0 CLClientGetDistanceCoordinates + 303492
9  libsystem_pthread.dylib        0x2a90 _pthread_start + 136
10 libsystem_pthread.dylib        0x1fcc thread_start + 8

Lens Buddy photo processing queue
0  libsystem_kernel.dylib         0x1af8 mach_msg2_trap + 8
1  libsystem_kernel.dylib         0x1890 mach_msg2_internal + 80
2  IOKit                          0x1c50 io_connect_method + 528
3  IOKit                          0x1a14 IOConnectCallMethod + 236
4  IOKit                          0x191c IOConnectCallStructMethod + 56
5  CMPhoto                        0x943c0 JPEGDeviceInterface_decodeJPEGExt + 144
6  CMPhoto                        0x66bcc JPEGDecompressSurfaceHelper + 368
7  CMPhoto                        0x67340 JPEGDecompressSurface + 1808
8  CMPhoto                        0x28350 CMPhotoUnifiedJPEGDecoderDecode + 1588
9  CMPhoto                        0xa1b0 _decodeImage + 1572
10 CMPhoto                        0x27668 _createImageForIndex + 80
11 CMPhoto                        0x275dc CMPhotoDecompressionContainerCreateImageForIndex + 280
12 ImageIO                        0x392a4 AppleJPEGReadPlugin::copyIOSurfaceImp(CGImageProvider*, __CFDictionary const*, int*) + 980
13 ImageIO                        0x3800c AppleJPEGReadPlugin::decodeImageImp(IIODecodeParameter*, IIOImageType, __IOSurface**, __CVBuffer**, CGImageBlockSet**) + 716
14 ImageIO                        0x36ebc IIOReadPlugin::callDecodeImage(IIODecodeParameter*, IIOImageType, __IOSurface**, __CVBuffer**, CGImageBlockSet**) + 768
15 ImageIO                        0x11dbf8 IIO_Reader::CopyIOSurfaceProc(void*, CGImageProvider*, __CFDictionary const*) + 624
16 ImageIO                        0x12afa4 IIOImageProviderInfo::copyIOSurface(CGImageProvider*, __CFDictionary const*) + 348
17 ImageIO                        0x129d1c IIOImageProviderInfo::CopyIOSurface(void*, CGImageProvider*, __CFDictionary const*) + 568
18 CoreImage                      0x10cbb0 -[CIImage initWithCGImage:options:] + 1744
19 CoreImage                      0x10e108 -[CIImage initWithCGImageSource:index:options:] + 1084
20 CoreImage                      0x111a48 -[CIImage initWithContentsOfURL:options:] + 228
21 photographer                   0x42e1c4 ProcessMediaOperation.startProcesing() + 200 (ProcessMediaOperation.swift:200)
22 photographer                   0x42cfac closure #1 in ProcessMediaOperation.start() + 126 (ProcessMediaOperation.swift:126)
23 photographer                   0x187ac thunk for @escaping @callee_guaranteed @Sendable () -> () +<PHONE_NUMBER> (<compiler-generated>:4337551276)
24 libdispatch.dylib              0x213c _dispatch_call_block_and_release + 32
25 libdispatch.dylib              0x3dd4 _dispatch_client_callout + 20
26 libdispatch.dylib              0xb400 _dispatch_lane_serial_drain + 748
27 libdispatch.dylib              0xbf30 _dispatch_lane_invoke + 380
28 libdispatch.dylib              0x16cb4 _dispatch_root_queue_drain_deferred_wlh + 288
29 libdispatch.dylib              0x16528 _dispatch_workloop_worker_thread + 404
30 libsystem_pthread.dylib        0x1f20 _pthread_wqthread + 288
31 libsystem_pthread.dylib        0x1fc0 start_wqthread + 8

AXSpeech
0  libsystem_kernel.dylib         0x1af8 mach_msg2_trap + 8
1  libsystem_kernel.dylib         0x1890 mach_msg2_internal + 80
2  libsystem_kernel.dylib         0x17a8 mach_msg_overwrite + 436
3  libsystem_kernel.dylib         0x15e8 mach_msg + 24
4  CoreFoundation                 0x3601c __CFRunLoopServiceMachPort + 160
5  CoreFoundation                 0x33f04 __CFRunLoopRun + 1208
6  CoreFoundation                 0x33968 CFRunLoopRunSpecific + 608
7  Foundation                     0x2b4a8 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
8  TextToSpeech                   0x224d4 TTSCFAttributedStringCreateStringByBracketingAttributeWithString + 776
9  Foundation                     0x9ca9c __NSThread__start__ + 732
10 libsystem_pthread.dylib        0x2a90 _pthread_start + 136
11 libsystem_pthread.dylib        0x1fcc thread_start + 8

com.google.fira.worker
0  libsystem_kernel.dylib         0x2654 pread + 8
1  libsqlite3.dylib               0x92e70 sqlite3_sourceid + 7600
2  libsqlite3.dylib               0x7508 sqlite3_snprintf + 7840
3  libsqlite3.dylib               0x1a918 sqlite3_log + 3472
4  libsqlite3.dylib               0x9cee0 sqlite3_sourceid + 48672
5  libsqlite3.dylib               0xa97dc sqlite3_sourceid + 100124
6  libsqlite3.dylib               0x377f0 sqlite3_step + 48948
7  libsqlite3.dylib               0x2d134 sqlite3_step + 6264
8  libsqlite3.dylib               0x2bc80 sqlite3_step + 964
9  photographer                   0xb12bec -[APMSqliteStore recordsForQuery:parameterValues:error:withFilter:] +<PHONE_NUMBER>
10 photographer                   0xa92ea8 -[APMDatabase conditionalUserPropertiesWithCondition:parameterValues:error:] +<PHONE_NUMBER>
11 photographer                   0xa92a24 -[APMDatabase timedOutConditionalUserPropertiesWithError:] +<PHONE_NUMBER>
12 photographer                   0xa86efc -[APMConditionalUserPropertyController(Private) removeTimedOutCUPWithTimedOutEvents:] +<PHONE_NUMBER>
13 photographer                   0xa86cf0 __75-[APMConditionalUserPropertyController(Private) processEventOnWorkerQueue:]_block_invoke +<PHONE_NUMBER>
14 photographer                   0xb13038 -[APMSqliteStore performTransactionWithError:block:] +<PHONE_NUMBER>
15 photographer                   0xa8afec -[APMDatabase performTransaction:] +<PHONE_NUMBER>
16 photographer                   0xa86adc -[APMConditionalUserPropertyController(Private) processEventOnWorkerQueue:] +<PHONE_NUMBER>
17 photographer                   0xac36f0 -[APMMeasurement(Event) writeEventOnWorkerQueue:] +<PHONE_NUMBER>
18 photographer                   0xac3378 -[APMMeasurement(Event) handleEventOnWorkerQueue:] +<PHONE_NUMBER>
19 photographer                   0xab7b58 -[APMMeasurement logEventOnWorkerQueue:notifyEventListeners:] +<PHONE_NUMBER>
20 photographer                   0xab79e4 -[APMMeasurement logEventOnWorkerQueueWithOrigin:isPublicEvent:name:parameters:timestamp:enabled:ignoreEnabled:ignoreInterceptor:interceptor:addedScreenParameters:] +<PHONE_NUMBER>
21 photographer                   0xab7814 __151-[APMMeasurement logEventWithOrigin:isPublicEvent:name:parameters:timestamp:enabled:ignoreEnabled:ignoreInterceptor:interceptor:addedScreenParameters:]_block_invoke +<PHONE_NUMBER>
22 photographer                   0xb0a18c __51-[APMScheduler scheduleOnWorkerQueueBlockID:block:]_block_invoke +<PHONE_NUMBER>
23 libdispatch.dylib              0x213c _dispatch_call_block_and_release + 32
24 libdispatch.dylib              0x3dd4 _dispatch_client_callout + 20
25 libdispatch.dylib              0xb400 _dispatch_lane_serial_drain + 748
26 libdispatch.dylib              0xbf30 _dispatch_lane_invoke + 380
27 libdispatch.dylib              0x16cb4 _dispatch_root_queue_drain_deferred_wlh + 288
28 libdispatch.dylib              0x16528 _dispatch_workloop_worker_thread + 404
29 libsystem_pthread.dylib        0x1f20 _pthread_wqthread + 288
30 libsystem_pthread.dylib        0x1fc0 start_wqthread + 8

com.apple.NSURLConnectionLoader
0  libsystem_kernel.dylib         0x1af8 mach_msg2_trap + 8
1  libsystem_kernel.dylib         0x1890 mach_msg2_internal + 80
2  libsystem_kernel.dylib         0x17a8 mach_msg_overwrite + 436
3  libsystem_kernel.dylib         0x15e8 mach_msg + 24
4  CoreFoundation                 0x3601c __CFRunLoopServiceMachPort + 160
5  CoreFoundation                 0x33f04 __CFRunLoopRun + 1208
6  CoreFoundation                 0x33968 CFRunLoopRunSpecific + 608
7  CFNetwork                      0x25ac48 estimatedPropertyListSize + 38228
8  Foundation                     0x9ca9c __NSThread__start__ + 732
9  libsystem_pthread.dylib        0x2a90 _pthread_start + 136
10 libsystem_pthread.dylib        0x1fcc thread_start + 8

Thread
0  libsystem_kernel.dylib         0xa084 __workq_kernreturn + 8
1  libsystem_pthread.dylib        0x1f6c _pthread_wqthread + 364
2  libsystem_pthread.dylib        0x1fc0 start_wqthread + 8

Thread
0  libsystem_kernel.dylib         0xa084 __workq_kernreturn + 8
1  libsystem_pthread.dylib        0x1f6c _pthread_wqthread + 364
2  libsystem_pthread.dylib        0x1fc0 start_wqthread + 8

Thread
0  libsystem_pthread.dylib        0x1fb8 start_wqthread + 438

H11ANEServicesThread
0  libsystem_kernel.dylib         0x1af8 mach_msg2_trap + 8
1  libsystem_kernel.dylib         0x1890 mach_msg2_internal + 80
2  libsystem_kernel.dylib         0x17a8 mach_msg_overwrite + 436
3  libsystem_kernel.dylib         0x15e8 mach_msg + 24
4  CoreFoundation                 0x3601c __CFRunLoopServiceMachPort + 160
5  CoreFoundation                 0x33f04 __CFRunLoopRun + 1208
6  CoreFoundation                 0x33968 CFRunLoopRunSpecific + 608
7  CoreFoundation                 0x336cc CFRunLoopRun + 64
8  ANEServices                    0xf88c H11ANE::H11ANEServicesThreadStart(H11ANE::H11ANEServicesThreadParams*) + 148
9  libsystem_pthread.dylib        0x2a90 _pthread_start + 136
10 libsystem_pthread.dylib        0x1fcc thread_start + 8

H11ANEServicesThread
0  libsystem_kernel.dylib         0x1af8 mach_msg2_trap + 8
1  libsystem_kernel.dylib         0x1890 mach_msg2_internal + 80
2  libsystem_kernel.dylib         0x17a8 mach_msg_overwrite + 436
3  libsystem_kernel.dylib         0x15e8 mach_msg + 24
4  CoreFoundation                 0x3601c __CFRunLoopServiceMachPort + 160
5  CoreFoundation                 0x33f04 __CFRunLoopRun + 1208
6  CoreFoundation                 0x33968 CFRunLoopRunSpecific + 608
7  CoreFoundation                 0x336cc CFRunLoopRun + 64
8  ANEServices                    0xf88c H11ANE::H11ANEServicesThreadStart(H11ANE::H11ANEServicesThreadParams*) + 148
9  libsystem_pthread.dylib        0x2a90 _pthread_start + 136
10 libsystem_pthread.dylib        0x1fcc thread_start + 8

Thread
0  libsystem_kernel.dylib         0xa084 __workq_kernreturn + 8
1  libsystem_pthread.dylib        0x1f6c _pthread_wqthread + 364
2  libsystem_pthread.dylib        0x1fc0 start_wqthread + 8

I've seen this report from someone else too. The thing that's baffling me is that the crash reports indicate it's crashing in the function Superwall.publisher(forEvent:params:paywallOverrides:isFeatureGatable:). This is a public facing combine-based function that isn't used anywhere internally within our code. Are you definitely not calling this function and only calling register?

Hey Yusuf, Thanks for getting back to me! I am pretty sure that Superwall.shared.register is the only way I'm triggering Superwall. (see screenshots)
Just FYI: I currently use Superwall.shared.register as part of my custom paywall presentation logic and also in every analytics event (following the register everything guide https://superwall.com/docs/feature-gating#register-everything). I think as a next step I'll remove Superwall integration from my analytics to try to see if that curbs the crashes.

Thanks for the info. It could be that the crash is getting misattributed. We do use a state publisher within register and previously we had memory issues when we were using Combine a lot, which we had to strip back. Thanks for the detailed report, I'll continue investigating and will come back if I need any more details.

Just FYI: I released my app update (v63) where I removed Superwall.shared.register from analytics calls almost a week ago. So far not a single crash report from the new version. (Screenshot is past 7 days reports on Firebase. I integrated Superwall SDK in v51.)

Hi, just following up here. I wasn't able to reproduce the crash but the latest update (v3.7.4) contains a potential fix for this by wrapping the Combine function that the crash log points to in a Deferred block to make sure it's not being accidentally fired. I would recommend trying that out.

Having the same issue, any updates from this?

@AdrianoBinhara Are you using v3.7.4+ of the SDK?

Yes, with xcode 16.1 beta, and also tried with xcode 15.4 and 16 RC, but got the same issue. exc_bad_access (code=1 address=0x0)

Are you able to reproduce the crash every time and is it the exact same crash log as the original post? If you can reproduce, what are your steps?

Yes, always the same crash. It tracks to detectNewSession() method at await withTaskGroup
"A bad access to memory terminated the process."

I created a new app swiftui app and added the configure line. That's all it took to break the app

Can you post the crash log? It sounds like this is a different issue to the original post.

EXC_BAD_ACCESS
A bad access to memory terminated the process.
This exception is usually accompanied by either the SIGBUS or SIGSEGV signal; for more information, see EXC_BAD_ACCESS (SIGBUS) or EXC_BAD_ACCESS (SIGSEGV).
This is all that I got, it throws at AppSessionManager -> detectNewSession()

Yeah this is different. Can you create a new issue on here and, if possible, attach the SwiftUI project which is causing this issue for you so I can download it and reproduce? When it crashes, if you copy and paste the stack trace it'll be a lot easier to debug. Currently unable to reproduce the issue.

FYI if you're building for mac using Designed for iPad from the Xcode 16 RC and running on macOS < 15, then you will get a crash in the place you said. It's an Xcode 16 bug in the latest RC: https://developer.apple.com/documentation/xcode-release-notes/xcode-16-release-notes#Known-Issues


[NB] Fix get temperature

This PR will fix an issue with getting temperature (HassClimateGetTemperature) for Norwegian Bokmål nb.
When I ran this command:
python3 -m script.intentfest parse --language nb --sentence "hvor varmt er det i stuen"

I got this error:
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/Users/stale/private_projects/home-assistant/intents/script/intentfest/__main__.py", line 29, in <module>
    sys.exit(main())
  File "/Users/stale/private_projects/home-assistant/intents/script/intentfest/__main__.py", line 24, in main
    return module.run()
  File "/Users/stale/private_projects/home-assistant/intents/script/intentfest/parse.py", line 89, in run
    render_response(response_template, result, matched, unmatched)
  File "/Users/stale/private_projects/home-assistant/intents/shared/__init__.py", line 177, in render_response
    return env.from_string(response_template).render(
  File "/Users/stale/private_projects/home-assistant/intents/venv/lib/python3.10/site-packages/jinja2/environment.py", line 1301, in render
    self.environment.handle_exception()
  File "/Users/stale/private_projects/home-assistant/intents/venv/lib/python3.10/site-packages/jinja2/environment.py", line 936, in handle_exception
    raise rewrite_traceback_stack(source=source)
  File "<template>", line 1, in top-level template code
jinja2.exceptions.UndefinedError: 'None' has no attribute 'state'

What's changed:

Response when asking for temperature / setting temperature (matching en)
Fix test data, we didn't have any climate entity

This PR will also remove this warning:
[WARN] tests/nb/climate_HassClimateGetTemperature.yaml: 3 test(s) missing response check

I have no comments to this PR.


Update RN polyfill instructions to use fewer & newer polyfills

The current RN documentation suggests using react-native-polyfill-globals which has not been updated in a few years. There have also been recent updates to RN negating the need for many of those polyfills. This PR updates the instructions to use a minimal number of newer and better maintained polyfills.
Some highlights:

Drops react-native-polyfill-globals in favor of using RN's polyfillGlobal directly.
Drops atob and btoa polyfills since hermes is now the default and includes atob and btoa.
Replaces unmaintained text-encoding with maintained and more performant react-native-fast-encoder. (Note that hermes does include TextEncoder but not yet TextDecoder)

Hi @ryanlntn. We've been trying to test out these docs changes in our examples repo, but we are running into issues making things work. It's a fun game of whack-a-mole trying to get the correct things polyfilled with various versions of dependencies.
We have a PR that we've started here which attempts to follow the docs. Would you be willing to move this one across the finish line based on your suggestions? Basically if the following all pass in that example project, we should be good:

npm run ci
npm start (and then confirming you are able to run the app on a device)
npm run web (and able to run in a browser)

Hey @smaye81!
No problem. I opened a PR to update the update here.


Rails 6

Adapted from: https://github.com/plataformatec/devise/blob/master/lib/generators/active_record/devise_generator.rb#L86
I have also changed double quotes to single so that it wouldn't conflict with the previous PR.

All rbx builds were failing, so I removed it from .travis.yml

There is a weird bug (https://github.com/plataformatec/devise/issues/4630) in newer versions of Ruby (2.5+) that keeps breaking the build for older versions of Devise (< 4.4). See: https://travis-ci.org/scambra/devise_invitable/builds/496151257
I'd say to drop Devise 4.0/4.1 support, since these versions are not being maintained, afaik.

You're right, devise 4.0 and 4.1 should be removed, can you change those gemfiles to devise 4.3 and 4.5, and change Gemfile to devise 4.6? Also, I see Gemfile.devise-4.4 and Gemfile.rails-4.2 are testing same versions, maybe all devise-x gemfiles should be changed to test agains rails 5.2, and just keep one Gemfile for rails 4.2 with latest devise version.
There is Gemfile for rails 5.2, but it isn't added to travis.yml, can you add it?
I see you added ruby 2.6 and then removed, you can add it and exclude gemfiles which won't be supported, in exclude block.
This lines can be removed from exclude:
    - rvm: 2.1.10
      gemfile: Gemfile

Rails 4.2 is incompatible with this release, so I dropped the Gemfile.

Mongoid keeps failing on this test: https://github.com/scambra/devise_invitable/blob/master/test/models/invitable_test.rb#L167
@scambra, can you please take a look?

It's ready :tada:
This PR turned out to be bigger than I anticipated it to be. A lot of commits in this branch are pretty trivial or outright contradict each other (the whole jazz with versions). Don't forget to squash all commits, otherwise it will pollute commit history for no good reason.
https://help.github.com/en/articles/configuring-commit-squashing-for-pull-requests

Great job, thanks


Upgrade to latest Jetty version

Jetty 9.4.14.v20181114 has security vulnerabilities where the server is vulnerable to XSS conditions.
https://www.cvedetails.com/cve/CVE-2019-10241/

From that CVE

... the server is vulnerable to XSS conditions if a remote client USES a specially formatted URL against the DefaultServlet or ResourceHandler that is configured for showing a Listing of directory contents.

I suppose we don't use DefaultServlet nor ResourceHandler configured for showing a Listing of directory contents.
@electrum do we?
(This is not to say we shouldn't upgrade. I'm just trying to understand the situation better.)

Completed. Please close @electrum