findBestRoute method returns wrong value for expected amount

try {
        const uniswapPairFactory = await uniswapPair.createFactory();
        const result = await uniswapPairFactory.findBestRoute(
            amount,
            TradeDirection.input
        );

        return {
            path: result.bestRouteQuote.routePathArray,
            expectedOutput:
                result.bestRouteQuote
                    .expectedConvertQuoteOrTokenAmountInMaxWithSlippage,
        };
    } catch (error) {
        console.log("error: ", error);
        throw error;
    }

I used cloneUniswapContractDetails to make this works on cronos chain and every things works fine. but for a particular token, the result.bestRouteQuote.expectedConvertQuoteOrTokenAmountInMaxWithSlippage gives a very wrong value

For Context purpose, this is the full code:
import {
    UniswapPair,
    UniswapVersion,
    UniswapPairSettings,
    TradeDirection,
} from "simple-uniswap-sdk";
import { constants } from "ethers";

interface Params {
    fromTokenContractAddress: string;
    toTokenContractAddress: string;
    amount: string;
    provider: any;
}

export const findBestRoute = async (
    params: Params
): Promise<{ path: string[]; expectedOutput: string }> => {
    const {
        fromTokenContractAddress,
        toTokenContractAddress,
        amount,
        provider,
    } = params;

    const cloneUniswapContractDetails = {
        v2Override: {
            routerAddress: "0x145677FC4d9b8F19B5D56d1820c48e0443049a30",
            factoryAddress: "0xd590cC180601AEcD6eeADD9B7f2B7611519544f4",
            pairAddress: "0xd590cC180601AEcD6eeADD9B7f2B7611519544f4",
        },
    };

    const uniswapPair = new UniswapPair({
        fromTokenContractAddress,
        toTokenContractAddress,
        ethereumAddress: constants.AddressZero,
        ethereumProvider: provider,
        settings: new UniswapPairSettings({
            slippage: 0.001,
            deadlineMinutes: 20,
            disableMultihops: false,
            uniswapVersions: [UniswapVersion.v2],
            cloneUniswapContractDetails: cloneUniswapContractDetails,
            customNetwork: {
                nameNetwork: "Cronos Mainnet Beta",
                multicallContractAddress:
                    "0x5e954f5972EC6BFc7dECd75779F10d848230345F",
                nativeCurrency: {
                    name: "cro",
                    symbol: "CRO",
                },
                nativeWrappedTokenInfo: {
                    chainId: 25,
                    contractAddress:
                        "0x5C7F8A570d578ED84E63fdFA7b1eE72dEae1AE23",
                    decimals: 18,
                    symbol: "WCRO",
                    name: "Wrapped CRO",
                },
            },
        }),
    });

    try {
        const uniswapPairFactory = await uniswapPair.createFactory();
        const result = await uniswapPairFactory.findBestRoute(
            amount,
            TradeDirection.input
        );

        return {
            path: result.bestRouteQuote.routePathArray,
            expectedOutput:
                result.bestRouteQuote
                    .expectedConvertQuoteOrTokenAmountInMaxWithSlippage,
        };
    } catch (error) {
        console.log("error: ", error);
        throw error;
    }
};

The toTokenContractAddress: "0x7b8aD6d7560FAcd1959cfb4b4163D7d297c4bFc0"
I've used MUSD(0x97749c9B61F878a880DfE312d2594AE07AEd7656) and USDC(0xc21223249CA28397B4B6541dfFaEcC539BfF0c59)
No matter the input amount provided, I keep getting value between 4.3 to 4.9
the decentralized exchange whose contracts I'm using() gives me correct value so I don't know if there is something I'm doing wrongly

A loom video showing the error in action: loom

The provider url of Cronos Mainnet Beta chain: https://rpc.nebkas.ro

this is now fixed have confirmed my end!

Hey so we spoke over twitter but will explain again.. but this was due to no liquidity on main routes and it was always going to MMF token which the sdk did not know about, you need to add that base token and then the lib will route to it..
if you add (use one of the base tokens to map the MMF token)
baseTokens: {
    dai: {
        chainId: 25,
        contractAddress: '0x97749c9B61F878a880DfE312d2594AE07AEd7656',
         decimals: 18,
         symbol: 'MMF',
         name: 'MMF',
  }
}

aka like
 in the custom network object it works

Works like charm. Thank you very much


Restrict past dates and times from date time now

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Feature with doc update
What is the current behavior? (You can also link to an open issue here)
Does not disable the past times within the current day
What is the new behavior (if this is a feature change)?
Disables the past times with the current day
Does this PR introduce a breaking change?
No, its just a useful feature to the filter
Please check if the PR fulfills these requirements

[x] This PR is against the develop branch. (Please do not submit PR's to the master branch)
[ ] The commit message follows our guidelines: https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit-message-format
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

Other information:

Coverage remained the same at 100.0% when pulling dd0e591292dafb2d8e479692946b08b2aceb1b4a on garethstar:master into 65350d34dca3751fa800fa1e8f0fa902706c6691 on dalelotts:develop.

Thanks for the PR!  Can you help me understand the use case? Why is so much code necessary?

Coverage remained the same at 100.0% when pulling 815efb31c53933bf873532e7ce4390703a875595 on garethstar:master into 65350d34dca3751fa800fa1e8f0fa902706c6691 on dalelotts:develop.

@dalelotts, I wanted to make it possible to disable all of today's times prior to now (I may add on offset) so that when the users of my app are selecting a call back time, there is no chance of them selecting past times.
At first I thought it would be a case of removing the midnight setter, however this then disabled the selection of the date. I managed to stop that bug only for 2 more to spawn from that. Then I kept finding bug after bug until the solution grew into this, a cleaner solution is more than welcome.

Why doesn't accepting $view as a parameter and adjust the "cut-off date" work for this use case?

@dalelotts i haven't tried that, i'll look into it on Monday, i'll let you know how it goes. Thanks

@dalelotts Cheers, using the value parameter works great

Coverage remained the same at 100.0% when pulling ef64cf239e70fe515f5740d621a5a8b14c819612 on garethstar:master into 65350d34dca3751fa800fa1e8f0fa902706c6691 on dalelotts:develop.


Tooltip component

Feature request
A tooltip component similar to builtin tooltips in VSCode.
Screenshots/references

Hey @EcksDy! This behavior/the example you've provided is actually enabled by default HTML behavior! You can add a title attribute to most HTML elements and when hovered the title attribute value will be rendered as a tooltip.
This is how the screenshot you provided is implemented in VS Code:

Explorer

Here are a few other examples of how various tooltips are implemented in VS Code as well:

      Welcome

Since this behavior is enabled by native HTML functionality I'm going to go ahead and close this request. But if you disagree or have any other questions please let me know and I'm happy to discuss 😊.


Cascade unloading

If I unload a Human I would expect its Legs to be unloaded as well, since they cannot exist without their corresponding Human.
This isn't currently possible by only using an Adapter mixin. Do you have some alternative ideas?

I suggest switching to decorators and then relying on the didDelete event and overwriting the unloadRecord method.
// app/models/human.js
import Model from 'ember-data/model';
import attr from 'ember-data/attr';
import { hasMany, belongsTo } from 'ember-data/relationships';
import { cascadeDelete, cascadeUnload } from 'ember-data-cascade-delete';

export default Model.extend({
  name: attr('string'),

  @cascadeUnload
  @cascadeDelete
  heart: belongsTo('heart', { async: true, inverse: 'human' }),

  @cascadeUnload
  @cascadeDelete
  legs: hasMany('leg', { async: true, inverse: 'human' })
});

Using the above pattern, you could even walk the extra mile and make sure that when a relationship is cleared, the orphaned child record gets deleted / unloaded.

For the record, 2 years after, I now think that this shouldn't be a decorator, but an option of belongsTo like it already is.
// app/models/human.js
import Model, { attr, belongsTo, hasMany } from '@ember-data/model';

export default class Human extends Model {
  @attr('string')
  name;

  @belongsTo('heart', { async: true, inverse: 'human', cascadeDelete: true })
  heart;

  @hasMany('leg', { async: true, inverse: 'human', cascadeDelete: true })
  legs;
}

The reason is that this is still describing a relationship.
Cascade unloading is still desirable and it would be nice if we could not use mixins.


[PWK] improvement: install bash and kubectl completion

FYI to make my kubectl sessions more usable, I usually do:
yum install -y bash-completion
kubectl completion bash > /etc/bash_completion.d/kubectl.bash
exec bash

dupe of #164 .


Livewire 2.x

(I was trying
composer require mattlibera/livewire-flash
Using version ^0.3.1 for mattlibera/livewire-flash
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Can only install one of: livewire/livewire[1.x-dev, v2.1.2].
- Can only install one of: livewire/livewire[v2.1.2, 1.x-dev].
- Can only install one of: livewire/livewire[1.x-dev, v2.1.2].
- mattlibera/livewire-flash v0.3.1 requires livewire/livewire ^1.2 -> satisfiable by livewire/livewire[1.x-dev].
- Installation request for mattlibera/livewire-flash ^0.3.1 -> satisfiable by mattlibera/livewire-flash[v0.3.1].
- Installation request for livewire/livewire (locked at v2.1.2, required as ^2.0) -> satisfiable by livewire/livewire[v2.1.2].
Installation failed, reverting ./composer.json to its original content.

Sorry about this. I will see what I can do today to get Livewire 2.0 support. Don't think it'll be a tough lift.

@jjrohrer Should be set via #7 . Just update your requirement for this package to be ^0.4 and then composer update mattlibera/livewire-flash should pull it in. Let me know if that doesn't work for some reason.

Nice!


Support connecting or disconnecting an actor from the upstream and downstream of the graph.

Closed via #4956.


Fix wrong temperature value

value must be shifted, because OUT_TEMP_L/H register is 12bit left-justified

Thanks for merging.
We are facing another strange issue with lis3dhh accelerometer, which seem to be related to ambient temperature: when temperature increases, raw accelerometer values become incorrect (raw values close to zero, typically between -5 and 15, for all x, y, and z axis...)
And we currently use lis3dhh accelerometer on 3 different devices, and this issue is consistent across the 3 devices!

Should I open a new issue here, or should I report this issue somewhere else?

I think it is better to open a case here:
https://stintbugzilla.st.com/

Ok.
Can you double check the url? https://stintbugzilla.st.com/  does not work for me.
Are you sure it is a public bug tracker?


fix get the transition duration parent

Fix our build: https://travis-ci.org/twbs/bootstrap/jobs/352733509
/CC @XhmikosR to fix our build and @MartijnCuppens

/CC @MartijnCuppens

Why would you get the transition duration from the parent if the element has no transition duration?

Because as I linked, you cannot get the inherited transition duration on Safari, and in Bootstrap sometimes we use Util.getTransitionDurationFromElement with a child element which do not contain any transition duration


device_state_attributes error in the newest HA beta

2021-12-04 11:00:32 WARNING (MainThread) [homeassistant.helpers.entity] Entity weather.weatherbit_zandhoven (<class 'custom_components.weatherbit.weather.WeatherbitWeather'>) implements device_state_attributes. Please report it to the custom component author.

Thanks for reporting this.
Tomorrow I expect to release a complete re-written version of this Integration, that has removed this issue and added some new stuff.

V1.0.0 released, fixing this issue.


Edit and Delete

All the various database objects need pages where they can be edited and deleted this includes

[x] Calendar events
[x] Projects
[x] Users
[x] Groups
[x] News stories

Completed by https://github.com/rcos/observatory-new/commit/befa24583aa3603f081d78d109870f09afa09ce8


(for warning_fixes) Fix non-ascii character folding problem (rails issue 3824)

In the present spec,
when the folding, an ascii only character line is not encoded.
But the ascii only line, that in the subject included non ascii character, must be encoded.
For example, gmail's behavior is that lines with non ascii character is encoded.
please see https://github.com/mikel/mail/pull/308

Hi,
What's the best way to have this bugfix ? Do you plan to release a new version soon or do you advise to build the gem from this commit in the Gemfile ?
Many thanks

@arunagw
/cc @Sylvain
Should I send pull request to master again ?

For the moment, I'll send PR #329 :-)

Merged, thanks :)


Bump node version to latest LTS

What
Because JavaScript. LOL, I'm sure.

Probably changed since this PR.


SQLite cannot get column  no such module: FTS5

Trying to match mysql FULLTEXT Index feature and found a reference to FTS5.
The query
CREATE VIRTUAL TABLE podcastchannels using FTS5 (id INTEGER,url TEXT,title TEXT,weblink TEXT,image TEXT,description TEXT,copyright VARCHAR(255),directory VARCHAR(255),labels VARCHAR(255),subscribedate VARCHAR(255),autoscan BOOL, fetchtype INTEGER,haspurge BOOL, purgecount INTEGER,writetags BOOL, filenamelayout VARCHAR(1024) );"
throws the following error
SQLite cannot get column  no such module: FTS5
Thanks
Leo

In case you're still seeing this, make sure you define the SQLITE_ENABLE_FTS5 flag when you build SQLite/SQLiteCpp.  I used FTS with SQLiteCpp for a bit and it worked fine.


Fix condition of RegisterEventHandler

Resolves #8
Move condition from EmitEvent to RegisterEventHandler to make it working with group tag.
I feel this makes the code more natural, switching whether to register evenr_handlers is better than always registering event_handlers that emit depending on some conditions.

@JWhitleyWork Could you review this, please?


Send batches of location updates

Challenge
We want to send fewer location messages but still preserve the accuracy of the location updates. In order to still be able to animate the asset position smoothly, we will need to notify the subscriber when will the next batch of locations be sent, so they can use that time to animate the previous locations.
Suggested solution:
To implement this behaviour we will have to make changes in both SDKs:
Publisher
Keep the frequent location engine updates rate ignoring the resolution requests for the best locations accuracy. This will probably require some changes in the ResolutionPolicy implementation but it's still to be decided whether this should be a completely new resolution policy or just a param on the already created DefaultResolutionPolicy (I'd suggest the second approach).
Keep the possibility to modify the location sending resolution in order to limit the number of messages sent. All locations updates that were not sent should be included in the skippedLocations list of the location update message. This is how it works already so no changes are required.
Publish the expected interval after which the new locations batch will be sent (for subscriber-side rendering). We have a debug feature of sending the current trackable resolution which we may use to provide the interval information. However, there's still a chance that the minimumDisplacement will be exceeded before the desiredInterval. This will result in the messages being sent earlier than the subscriber expects them. Not sure if that will be a problem though.

Subscriber
Use the location updates interval to smoothly animate the courier marker on the map. The bigger part of this should be implemented by the SDK users, the only thing from the SDK side is to expose the location updates interval. However, we will implement this behaviour in our example app to show how it can be done.

see https://github.com/ably/ably-asset-tracking-android/issues/626
┆Issue is synchronized with this Jira Task by Unito

This task contains few tasks.
https://github.com/ably/ably-asset-tracking-swift/pull/277
https://github.com/ably/ably-asset-tracking-swift/pull/273
https://github.com/ably/ably-asset-tracking-swift/issues/280


[cadl-python] add item in CI to check code format

thanks @msyyc!


Electric eats my data when SET LOCAL session_replication_role = replica is set

In my quest to migrate from electric 0.6.3 to 0.7.1 I've settled on this migration plan:

Dump the user data from the database running electric 0.6.3
Create a new database with the electic 0.7.1(and changed migrations)
Load the user data into the new database with electric 0.7.1

As i want to change the schema and use the new migration proxy i cant use pg_dump & pg_restore. I've wrote a script which dumps all the important data to a json and another script which restores it. In order to simplify the restore script and not care about ordering between tables I'm setting SET LOCAL session_replication_role = replica during the restore so i may load data in any order I want.
It turns out that data gets restored only in non electrified tables! The electrified tables end up empty .-. When I'm using SET LOCAL session_replication_role = origin the  data gets indeed loaded properly into the tables(i've tested on a few electrified tables)
Why data inserted with SET LOCAL session_replication_role = replica get's deleted by electric?(I'm still testing on 0.6.3)

I've settled for manually disabling triggers while i'm messing with the database. Everything works. Electric properly reconciles the client state after an db restore. Here's the code if someone else wants to do something similar:
  await db.$transaction(async (tx: Prisma.TransactionClient) => {
    console.log("Transaction opened. Locking all tables");
    // Enable serializable isolation level
    await tx.$executeRawUnsafe("SET LOCAL TRANSACTION ISOLATION LEVEL SERIALIZABLE;");
    // Lock all tables in exclusive access mode
    await waitForPromises(
      allTables.map(async (table) => await tx.$queryRawUnsafe(`LOCK TABLE ${table} IN ACCESS EXCLUSIVE MODE`)),
    );

    console.log("Introspecting triggers");
    // First explicitly get what triggers are currently enabled
    const getTriggersFun = async (): Promise<{ triggerName: string, tableName: string, triggerMode: string }[]> => {
      return (await waitForPromises(allTables.map(async (tableName) => await tx.$queryRawUnsafe(`SELECT
      tgname AS "triggerName",
      '${tableName}' AS "tableName",
      t.tgenabled AS "triggerMode"
  FROM
      pg_trigger t
  WHERE
      t.tgrelid = '${tableName}'::regclass::oid
      -- 'A' for ALWAYS, 'R' for REPLICA, 'O' for ORIGIN/LOCAL
      AND t.tgenabled IN ('A', 'R', 'O')
      ORDER BY "tableName", "triggerName";`)),
      ) as any).flat()
        // Ignore triggers from electric
        .filter((x: any) =>
          (x.triggerName as string).indexOf("shadow_rows") < 0
          && (x.triggerName as string).indexOf("tombstone_table") < 0
          && (x.triggerName as string).indexOf("satellite_write") < 0
        ) as any;
    };

    const triggers = await getTriggersFun();
    console.log("Disabling triggers");
    await waitForPromises(triggers.map((x) => tx.$queryRawUnsafe(`ALTER TABLE ${x.tableName} DISABLE TRIGGER "${x.triggerName}"`)));
    // Sanity check that the triggers got disabled
    if ((await getTriggersFun()).length !== 0) throw new Error("Disabling triggers failed!")
    try {
    // LOAD DATA INTO TABLES
    } finally {
      console.log("Restoring triggers")
      // Reenable the triggers
      await waitForPromises(triggers.map((x) =>
        tx.$queryRawUnsafe(`ALTER TABLE ${x.tableName} ENABLE ${x.triggerMode === "A" ? "ALWAYS" : x.triggerMode === "R" ? "REPLICA" : ""} TRIGGER "${x.triggerName}"`)));
      // Sanity check that the triggers ended up in the initial state
      const finalTriggers = await getTriggersFun();
      if (!isEqual(triggers, finalTriggers)) {
        // eslint-disable-next-line no-unsafe-finally
        throw new Error(`Restoring triggers failed!, ${humanReadableObjectDiff(triggers, finalTriggers)}`)
      }
    }
    console.log("Commiting transaction");
  });

To give a bit of context, there are different triggers for when an operation is coming from the replication stream, or executed by a Pg client directly. It makes sense that when enabling the replica mode for migrating data, you need to disable the triggers associated with replica mode


DOCS: Mention that libcrypto has helper functions for OSSL_PARAMs

Fixes #11165

This pull request is ready to merge

Merged to master.


k8s-monitoring v2 doesn't allow setting discovery relabeling for node-exporter

While playing around with the helm-monitoring v2 chart, I noticed  one feature that is possible in v1 is not possible (I think) in the v2 chart. Specifically, the ability to perform discovery relabeling for node-exporter.
v1 allows this through the following configuration:
metrics:
  enabled: true
  node-exporter:
    enabled: true
    extraRelabelingRules: |
      rule {
        source_labels = ["__meta_kubernetes_pod_node_name"]
        action = "replace"
        target_label  = "nodename"
      }

In v2, the node-exporter scrape configuration is now using the node-exporter alloy module which doesn't expose the ability to set any additional discovery relabel configs (https://github.com/grafana/alloy-modules/blob/main/modules/system/node-exporter/metrics.alloy#L49C7-L138). Maybe this was intentionally not exposed, but I'm not sure.
Supporting this feature would require a change to the upstream alloy-module, it seems.

Good point! Let me make sure that functionality is in there!
Thanks for testing out version 2!


Expression.Error: The column 'customerId' of the table wasn't found.

Steps to reproduce
Perform the following tasks

Install the connector in customer environment
Open Power BI Desktop
Click Get Data and then select the Security and Management Insights connector
Click on the Users table

Expected behavior
That the list of available users for the tenant would be loaded
Actual behavior
Expression.Error: The column 'customerId' of the table wasn't found.

Diagnostic logs
N/A
Environment

Power BI Desktop
Security and Management Insights connector version 2.1

I am getting this same error for many tables.

I am getting this same error for many tables.


Update main.py

More robust handling of connection errors/loss on schema fetch

Mainly to fix this issue one of my employees is having


Updating from 3.3 to 3.7 makes ipv6 pools undeletable due to validation

Expected Behavior
Delete an ippool
Current Behavior
Errors out:
# calicoctl delete ippool somenode-v6
Failed to delete 'IPPool' resource: error with field IPpool.VXLANMode = '' (VXLANMode other than 'Never' is not supported on an IPv6 IP pool)

Possible Solution
Do not validate existing resources on deletion
Steps to Reproduce (for bugs)

Setup calico 3.3 cluster (or possibly anything before VXLANMode has been added)
Create IPv6 IPPool (not tested with IPv4)
Update to calico 3.7 (incl. calicoctl)
Try to delete that IPPool.

Context
Fix my ippools whilst updating calico at once :)
Your Environment

Calico version: 3.3.6 + 3.7.2
Orchestrator version (e.g. kubernetes, mesos, rkt): k8s
Operating System and version: Debian
Link to your project (optional):

Cheers
Thanks for looking into this.
Ashley

INFO[0000] Log level set to debug
INFO[0000] Executing config command
DEBU[0000] Resource: projectcalico.org/v3, Kind=IPPool
DEBU[0000] Data: - apiVersion: projectcalico.org/v3
  kind: IPPool
  metadata:
    creationTimestamp: null
    name: fvirtbase129.ko.seznam.cz-v6
  spec:
    cidr: ""

DEBU[0000] Loading config from JSON or YAML data
DEBU[0000] Datastore type: etcdv3
INFO[0000] Loaded client config: apiconfig.CalicoAPIConfigSpec{DatastoreType:"etcdv3", EtcdConfig:apiconfig.EtcdConfig{EtcdEndpoints:"https://fkube1:2379,https://fkube2:2379,https://fkube3:2379", EtcdUsername:"", EtcdPassword:"", EtcdKeyFile:"/www/adm/calico/cert/etcd-key.pem", EtcdCertFile:"/www/adm/calico/cert/etcd-cert.pem", EtcdCACertFile:"/www/adm/calico/cert/etcd-ca.pem", EtcdKey:"", EtcdCert:"", EtcdCACert:""}, KubeConfig:apiconfig.KubeConfig{Kubeconfig:"", K8sAPIEndpoint:"", K8sKeyFile:"", K8sCertFile:"", K8sCAFile:"", K8sAPIToken:"", K8sInsecureSkipTLSVerify:false, K8sDisableNodePoll:false, K8sUsePodCIDR:false}}
DEBU[0000] Using datastore type 'etcdv3'
INFO[0000] Client: {{{CalicoAPIConfig projectcalico.org/v3} {      0 {{0 0 <nil>}} <nil> <nil> map[] map[] [] <nil> [] } {etcdv3 {https://fkube1:2379,https://fkube2:2379,https://fkube3:2379   /www/adm/calico/cert/etcd-key.pem /www/adm/calico/cert/etcd-cert.pem /www/adm/calico/cert/etcd-ca.pem   } {      false false false}}} 0xc00080e050 0xc0006bb210}
DEBU[0000] Processing Get request                        model-etcdKey="IPPool(fvirtbase129.ko.seznam.cz-v6)" rev=
DEBU[0000] Calling Get on etcdv3 client                  etcdv3-etcdKey=/calico/resources/v3/projectcalico.org/ippools/fvirtbase129.ko.seznam.cz-v6 model-etcdKey="IPPool(fvirtbase129.ko.seznam.cz-v6)" rev=
INFO[0000] Disabling pool to release affinities          CIDR="2a02:598:64:8012:40::/116" Name=fvirtbase129.ko.seznam.cz-v6
DEBU[0000] Validate IP network: 2a02:598:64:8012:40::/116
DEBU[0000] Validate IPIP Mode: Never
DEBU[0000] Validate selector: all()
DEBU[0000] Parsing "all()"
DEBU[0000] Tokens [{14 <nil>} {20 <nil>}]
DEBU[0000] IPPool CIDR: 2a02:598:64:8012:40::/116, Masked IP: [42 2 5 152 0 100 128 18 0 64 0 0 0 0 0 0]
INFO[0000] results: {fileInvalid:false numResources:1 numHandled:0 err:{ErroredFields:[{Name:IPpool.VXLANMode Value:{typ:0x143d860 ptr:0x265a100 flag:152} Reason:VXLANMode other than 'Never' is not supported on an IPv6 IP pool}]} singleKind:IPPool resources:[] client:{config:{TypeMeta:{Kind:CalicoAPIConfig APIVersion:projectcalico.org/v3} ObjectMeta:{Name: GenerateName: Namespace: SelfLink: UID: ResourceVersion: Generation:0 CreationTimestamp:{Time:{wall:0 ext:0 loc:<nil>}} DeletionTimestamp:<nil> DeletionGracePeriodSeconds:<nil> Labels:map[] Annotations:map[] OwnerReferences:[] Initializers:<nil> Finalizers:[] ClusterName:} Spec:{DatastoreType:etcdv3 EtcdConfig:{EtcdEndpoints:https://fkube1:2379,https://fkube2:2379,https://fkube3:2379 EtcdUsername: EtcdPassword: EtcdKeyFile:/www/adm/calico/cert/etcd-key.pem EtcdCertFile:/www/adm/calico/cert/etcd-cert.pem EtcdCACertFile:/www/adm/calico/cert/etcd-ca.pem EtcdKey: EtcdCert: EtcdCACert:} KubeConfig:{Kubeconfig: K8sAPIEndpoint: K8sKeyFile: K8sCertFile: K8sCAFile: K8sAPIToken: K8sInsecureSkipTLSVerify:false K8sDisableNodePoll:false K8sUsePodCIDR:false}}} backend:0xc00080e050 resources:0xc0006bb210}}
Failed to delete 'IPPool' resource: error with field IPpool.VXLANMode = '' (VXLANMode other than 'Never' is not supported on an IPv6 IP pool)

@CallMeFoxie thanks for raising.
I think this might be fixed when this PR goes in (@asincu): https://github.com/projectcalico/calicoctl/pull/2006/files#diff-8bbd6071fc04d3937359d74a6a4be20eR410
In the meantime, you might be able to work around this by explicitly updating the pool to have VXLANMode: Never and then trying to delete it.

Will be fixed in the next patch release. Thanks!


ERR! enfield Build failed: ext must be a string

Any hint about the following error?
$ enfield -v
enfield 0.4.0
$ enfield build
info enfield Configuration File: _config.yml
info enfield Source: ./
info enfield Destination: _site
info generate Begin generation
ERR! enfield Build failed: ext must be a string
$

I'm guessing it's trying to extract a file extension from a file and failing, and that's causing an issue. What are the filenames of the site? If you run with --log verbose it may give more info.

Here the output.
$ node ../enfield/bin/enfield.js build --log verbose
verb enfield Set log level: verbose
verb enfield [09:00:10] Received command build
verb config [09:00:10] Trying to read config from file _config.yml
verb config [09:00:10] Loading config from file _config.yml
info enfield [09:00:10] Configuration File: _config.yml
info enfield [09:00:10] Source: ./
info enfield [09:00:10] Destination: _site
info generate [09:00:10] Begin generation
verb generate [09:00:10] Looking for plugins in: C:\My\Dev\snippets\enfield\src\plugins
ERR! enfield [09:00:10] Build failed: ext must be a string
verb enfield [09:00:10] Stack trace: TypeError: ext must be a string
verb enfield   at win32.basename (path.js:325:11)
verb enfield   at Array.map (native)
verb enfield   at C:\My\Dev\snippets\enfield\src\generate.coffee:711:18
verb enfield From previous event:
verb enfield   at loadBundledPlugins (C:\My\Dev\snippets\enfield\src\generate.coffee:670:6)
verb enfield   at module.exports.exports (C:\My\Dev\snippets\enfield\src\generate.coffee:29:36)
verb enfield   at Object.module.exports.exports.build (C:\My\Dev\snippets\enfield\src\enfield.coffee:131:5)
verb enfield   at C:\My\Dev\snippets\enfield\src\enfield.coffee:77:23
$

A similar experience albeit in my case in Arch Linux.
verb enfield Set log level: verbose
verb enfield [7:33:04 PM] Received command serve
verb config [7:33:04 PM] Trying to read config from file _config.yml
verb config [7:33:04 PM] Loading config from file _config.yml
info enfield [7:33:04 PM] Configuration File: _config.yml
info enfield [7:33:04 PM] Source: ./
info enfield [7:33:04 PM] Destination: _site
info generate [7:33:04 PM] Begin generation
verb generate [7:33:05 PM] Looking for plugins in: /home/bretonio/.nvm/versions/node/v7.2.0/lib/node_modules/enfield/src/plugins
ERR! enfield [7:33:05 PM] Build failed: "ext" argument must be a string
verb enfield [7:33:05 PM] Stack trace: TypeError: "ext" argument must be a string
verb enfield   at basename (path.js:1354:13)
verb enfield   at Array.map (native)
verb enfield   at /home/bretonio/.nvm/versions/node/v7.2.0/lib/node_modules/enfield/src/generate.coffee:711:18
verb enfield   at _combinedTickCallback (internal/process/next_tick.js:67:7)
verb enfield   at process._tickCallback (internal/process/next_tick.js:98:9)
verb enfield From previous event:
verb enfield   at loadBundledPlugins (/home/bretonio/.nvm/versions/node/v7.2.0/lib/node_modules/enfield/src/generate.coffee:670:6)
verb enfield   at exports (/home/bretonio/.nvm/versions/node/v7.2.0/lib/node_modules/enfield/src/generate.coffee:29:36)
verb enfield   at Object.build (/home/bretonio/.nvm/versions/node/v7.2.0/lib/node_modules/enfield/src/enfield.coffee:131:5)
verb enfield   at Object.serve (/home/bretonio/.nvm/versions/node/v7.2.0/lib/node_modules/enfield/src/enfield.coffee:142:13)
verb enfield   at /home/bretonio/.nvm/versions/node/v7.2.0/lib/node_modules/enfield/src/enfield.coffee:84:23
verb enfield   at _combinedTickCallback (internal/process/next_tick.js:67:7)
verb enfield   at process._tickCallback (internal/process/next_tick.js:98:9)

_config.yml has only two lines: name (of the project) and pygments: true.


Environment variable to replace prometheus.yml mounting in Docker Environment.

Proposal
Is there any Environment variable to replace prometheus.yml mounting in Docker Environment.

It makes more sense to ask questions like this on the prometheus-users mailing list rather than in a GitHub issue. On the mailing list, more people are available to potentially respond to your question, and the whole community can benefit from the answers provided.


Duplicate Token after teleport

Hi,
I create a Teleport trigger who send a token(player) to a Destination teleport.
Each player has his Destination teleport.
When a player touch the Teleport trigger, he sended to his Destination teleport but his token has duplicate to all Destination teleport
For this example, Karnac duplicated to Destination Azog ? why ? Bad code to me ?

As long as the macro executes, then Trigger Happy did its job. If the teleport macro isn't working as it should, then it would be a Dynamic Effects issue rather than a Trigger Happy issue.

That might not be completely true. If there are multiple trigger happy journals the trigger might be executed multiple times and that would be a trigger happy problem/feature.
I note that there are token refs to the tokens inside the trigger happy journal entries and am not sure what that does.
Could you put console.log() calls inside the macros to see how many times it is being executed?


dummy change to trigger model regression tests

dummy change to trigger model regression tests (addresses #10041 et al.)

/modeltest
include:
  - dataset: ["all"]
    config: ["all"]


Rasa X Domain & NLU Data Sync

Description of Problem: The Rasa X UI has separate Domain and NLU data. If you remove an intent from the domain, you will naturally get an inconsistency error until you remove the associated training data and visa versa.
Overview of the Solution: It would be nice to have the UI manage this for the user. Maybe remove the intents from that domain section and make an improved training (and stories) UI that allows the user to better manage bots with large amounts of data.
Show the hierarchy of intents and examples in the NLU training section. Allow the user to delete an intent at the top level and all underlying examples would be removed along with the associated domain declaration.

Thanks for submitting this feature request 🚀@tmbo will get back to you about it soon!✨

I think that is a great idea and should make removing intents / entities easier :+1: cc @abhilasharoy

I don't think this is something we should do in the UI. Consider some of the possible scenarios:

you want split an intent up into two intents, and you need to update the relevant stories and NLU data, and domain.
you want to merge half of the utterances of intent A into intent B, and discard the other half.
you actually want to remove an intent altogether and update all of the stories that contain it.

Making bigger, disruptive changes is something you want to do locally on a branch, which means you have access to your text editor, find & replace, etc. There is no way we could cover all of these cases 'automagically' in the Rasa X UI so better off letting the developer have the flexibility of the tools they know.

Thank you for raising this issue about Rasa X. We decided to stop supporting the Community Edition (free version) of ‘Rasa X’ (see more info here: https://rasa.com/blog/rasa-x-community-edition-changes/). That’s why we’ve closed your issue. We suggest that Rasa Enterprise customers raise the issue with our customer support team if they haven’t done so already.


ActiveRecord adapter does not work with forking web servers (e.g. Puma)

Using the ActiveRecord adapter in a forking web server will cause interactions with the Moneta store to fail with a NoMethodError (ActiveRecord 5, at least).
The problem is that the adapter stores the connection pool in the initializer but after a server forks, the connection pool has to be discarded and re-created in each process. The behaviour of a discarded connection pool is undefined but for sure calling with_connection results in accessing a nil instance variable on this line within AR's connection pool.
Here's an example exception with stacktrace: https://sentry.io/share/issue/51fc2ab0456447a19f59018db1a1c971/ (URL will probably only work for ~30 days, though). You have to expand stack trace to "full" to see the origin of the exception.
This can be worked around by doing something like the following after forking:
adapter.instance_variable_set(
  :@connection_pool,
  ActiveRecord::Base.connection_pool,
)

This is particularly important since the feature matrix lists this as "multiprocess" compatible. It is, but only if you create the instance after forking or mess with private internals.

Ok, looks like the way to fix this will be to replace that @connection_pool variable with a function. This also raises that we should probably have a test that involves a call to fork.  Thanks for the report!

Alternatively/additionally, factor out the setting of @connection_pool from initializer and into a separate method which can be called at anytime to reconnect.

Yes, s/function/method/


net: check length of input ip address before for loop

It would be good if length of the given string is checked before for loop and return appropriate return value.

As per discussion closing this PR


Creating a new customer during a new offer creation does not work

Describe the bug
When you create a new offer and want to add a new customer along this, when you press the "Create Customer" Button, the select customer view vanishes, but there is no view showing, that enables to create a new customer.
To Reproduce
Steps to reproduce the behavior:

Start the app
Create a new offer
When you have to select a customer, press the "Create Customer" Button

Expected behavior
A view with input elements for creating a new customer should appear.
System [please complete the following information]:

TOMATO on branch release/1.0.0-alpha

Additional context
Add any other context about the problem here.

worked on dda6e8a1739a11cfc54b1571355adcc03e2ec7e4

worked on dda6e8a1739a11cfc54b1571355adcc03e2ec7e4


Improve logging when skipping screenshots

Requested by #3626
If deliver detects some screenshots that are framed, non-framed screenshots may be skipped during the collection process. This provides log messaging to notify the user that this is happening.

LGTM! :camera:


Question about Eq.(20) and Proof of Lemma 1

Thank you for your excellent work. I have a question regarding L_{cc} and its corresponding proof in appendix. Specifically, in L_{cc}, you use the unconditional prompt to predict x_e from t with G_{\theta}, however, in the proof, conditional prompt y is used in G_{\theta} instead. Could you help clarify this? Thank you :D.

Hello, and thank you for highlighting this issue. In the proof, the condition y is included to account for a more general case. In the special case where y is null-text, it is identical to L_cc. However, L_cc can also be text-conditioned, which may introduce some variation in the generated results. The main point here is to ensure that the condition remains consistent in both terms of L_cc.


proposal: math/rand/v2: revised API for math/rand

Based on earlier discussions in #60751, #26263, and #21835, as well as discussions with @robpike, I propose adding a new version of math/rand, imported as math/rand/v2, to the standard library. The full text is below but is nearly identical to what we discussed in #60751.
The most direct motivation for this proposal is to clean up math/rand and fix these many lingering problems, especially the use of an outdated generator, slow algorithms, and the unfortunate collision with crypto/rand.Read.
A more indirect but equally important motivation is to set an example for other v2 packages in the standard library. Creating math/rand/v2 will let us work out tooling issues (support for v2 packages in gopls, goimports, and so on) in a relatively rarely used package with fairly low stakes attached before moving on to more commonly used, higher-stakes packages like sync/v2 or encoding/json/v2.
This proposal establishes the pattern for v2 packages in the standard library, namely that they are subdirectories of the original package and that the starting point for the API is the original package, with each deviation clearly justified. In particular, v2 packages are not an opportunity to redesign something from scratch "just because". The existing APIs work well, and deviations should be carefully considered. A from-scratch new API is just as likely (probably more likely) to introduce new problems as it is to fix existing ones.
Once math/rand/v2 has shipped, we would tag and delete x/exp/rand. This would keep programs that already use x/exp/rand working (by reference to the tagged version or older versions of x/exp) but allow us to delete the code from the main branch of x/exp, making clear that development on it has ended.
A prototype of these math/rand/v2 changes can be found at https://go.dev/cl/502506 and the CLs below it in the stack.
Proposal
The math/rand/v2 API would use math/rand as a starting point and then make the following backwards incompatible changes:

Remove Rand.Read and top-level Read. It is almost always a mistake to pretend that a pseudo-random generator is a good source of arbitrarily long byte sequences. The kinds of simulations and non-deterministic algorithms for which math/rand is a good choice almost never need byte sequences. Read is the only common piece of API between math/rand and crypto/rand, and code should essentially always use crypto/rand.Read instead. (math/rand.Read and crypto/rand.Read are problematic because they have the the same signature; math/rand.Int and crypto/rand.Int also both exist, but with different signatures, meaning code never accidentally mistakes one for the other.)

Remove Source.Seed, Rand.Seed, and top-level Seed. Top-level Seed is deprecated as of Go 1.20. Source.Seed and Rand.Seed assume that the underlying source can be seeded by a single int64, which is only true of a limited number of sources. Specific source implementations can provide Seed methods with appropriate signatures, or none at all for generators that cannot be reseeded; the details of seeding do not belong in the general interface.
Note that removing top-level Seed means that the top-level functions like Int will always be randomly seeded rather than deterministically seeded. math/rand/v2 will not pay attention to the randautoseed GODEBUG setting that math/rand does; auto-seeding for top-level functions is the only mode. This means in turn that the specific PRNG algorithm used by the top-level functions is unspecified and can change from release to release without breaking any existing code.

Change the Source interface to have a single Uint64() uint64 method, replacing Int63() int64. The latter was overfitting to the original Mitchell & Reeds LFSR generator. Modern generators can provide uint64s, and uint64s have fewer special cases at call sites.

Remove Source64, which is unnecessary now that Source provides the Uint64 method.

Use a more straightforward implementation in Float32 and Float64. Taking Float64 as an example, it originally used float64(r.Int63()) / (1<<63), but this has the problem of occasionally rounding up to 1.0, which Float64 must not. We tried changing it to float64(r.Int63n(1<<53) / (1<<53), which avoids the rounding problem, but we decided it was a backwards compatibile change to break the value streams that rand.Rand generators, and instead added a retry loop for the rare 1.0 case. Now we can make the breaking change, which is simpler and faster.
Note that some people have observed that the simple division does not make use of all the possible float64 values in the range [0, 1). For example values like 1/(1<<54), 1/(1<<55), 3/(1<<55), and so on are not generated at all, both in today's math/rand and in this simpler algorithm. Only the values 0 and 1/(1<<53) are, not the ones in between. It is possible to introduce even more complex algorithms to spread out the low values more while preserving something that can be deemed a uniform distribution, but these algorithms seem like overkill. The simple division should continue to suffice.

(New since #60751.) Correct bias problems in ExpFloat64 and NormFloat64. @flyingmutant reports that these have detectable bias, perhaps due to a mistake in porting the Ziggurat algorithms from float32 to float64. We can take this opportunity to correct those.

Implement Rand.Perm in terms of Rand.Shuffle. Shuffle is a bit more efficient, and then we have only one implementation. It has been suggested elsewhere to remove Rand.Perm instead, but keeping it costs little (especially if implemented in terms of Shuffle) and avoids unnecessary churn for users.

Rename Intn, Int31, Int31n, Int63, Int64n to IntN, Int32, Int32N, Int64, Int64N. The 31 and 63 in the names are unnecessarily pedantic and confusing, and the capitalized N is more idiomatic for a second "word" in the name in Go. Note: The capital N's in the names are a change from #60751.

Add Uint32, Uint32N, Uint64, Uint64N, Uint, UintN, both as top-level functions and methods on Rand. At the least, we need Uint64 to provide access to the widest values that the Source can provide. But we may as well complete the set while we are here. Note: The capital N's in the names are a change from #60751.

(New since #60751) Add a generic top-level function N that is like Int64N or Uint64N but works for any integer type. In particular this allows using rand.N(1*time.Minute) to get a random duration in the range [0, 1*time.Minute).

Use Lemire's algorithm in N, IntN, UintN, and so on. Preliminary benchmarks show a 40% savings compared to v1 Int31n and a 75% savings compared to v1 Int63n. (Like with Float64, since this changes the values returned, it is a breaking change that can only be applied in math/rand/v2.)

Add a new Source implementation, PCG-DXSM, with this API:
func NewPCG(seed1, seed2 uint64) *PCG
type PCG struct { ... }
func (p *PCG) Uint64() uint64
func (p *PCG) Seed(seed1, seed2 uint64)
func (p *PCG) MarshalBinary() ([]byte, error)
func (p *PCG) UnmarshalBinary(data []byte) error

PCG is a simple, efficient algorithm with good statistical randomness properties. The DXSM variant was introduced by the author specifically to correct a rare, obscure shortcoming in the original (PCG-XSLRR) and is now the default generator in Numpy.
PCG is provided for people who are writing simulations and need a seeded, deterministic source of randomness suitable for most purposes. Note that PCG is not assumed in any code. In particular the top-level functions need not use PCG (and in the current prototype do not). If in the future we add another algorithm, it will sit alongside PCG as a true peer.
Note: MarshalBinary and UnmarshalBinary are new since #60751.

Remove the Mitchell & Reeds LFSR generator and NewSource. An alternative to removing it would be to give it a name like NewLFSR or NewMitchellReeds, but that would serve no purpose. The obvious purpose would be to provide the original math/rand source so that code that needs to reproduce the exact math/rand outputs can do so. But the other changes to Rand, in routines like Intn and Float64, change the derived values from Rand's methods for a given Source input stream. Since preserving the math/rand Source stream would not suffice to preserve the math/rand Rand stream, preserving the math/rand Source is not worthwhile. Programs that need exactly the math/rand value streams can continue to use that package; it will not be removed.

(New since #60751 and the original proposal in this issue) Add a new Source implementation, ChaCha8, with this API:
func NewChaCha8(seed [32]byte) *ChaCha8
type ChaCha8 struct { ... }
func (c *ChaCha8) Uint64() uint64
func (c *ChaCha8) Seed(seed [32]byte)
func (c *ChaCha8) MarshalBinary() ([]byte, error)
func (c *ChaCha8) UnmarshalBinary(data []byte) error

ChaCha8 is a cryptographically-strong random number generator derived from the ChaCha8 stream cipher. It provides security equivalent to ChaCha8 encryption.

(New since #60751 and the original proposal in this issue) Use a per-OS-thread ChaCha8 for the global random generator, both in math/rand/v2 and in math/rand (when unseeded). The current implementation uses a per-OS-thread wyrand, which was fine compared to the Mitchell/Reeds/Thompson generator but is not really great compared to PCG or ChaCha8. In particular, it is strange for the top-level randomness to be less studied and less robust than the two concrete implementations provided. Using ChaCha8 also gives the default top-level randomness real cryptographic strength, turning accidental use of math/rand where crypto/rand would be more appropriate into less of a security problem. Using ChaCha8 runs slower than using wyrand, but it is about as fast as the current sync.Mutex-locked generator in math/rand (~6ns per value on my 2019 Intel MacBook Pro).

Differences since previous discussion
The differences between this proposal and what we discussed in #60751 are:

Renamed Intn, Int64n, etc to IntN, Int64N, etc, capitalizing the N.

Added top-level generic rand.N function, which is like tbe current rand.Int64n or rand.Uint64n but works for any integer type.

Added MarshalBinary and UnmarshalBinary methods to the new PCG type.

Adjust the ExpFloat64 and NormFloat64 algorithms to remove bias. (Thanks to @zephyrtronium.)

Add ChaCha8 alongside PCG.

Use ChaCha8 for global generator.

These differences are also marked above.
Discussion Summary
Summarizing the discussion on #60751:

There was a suggestion to parameterize the top-level Intn, Uintn, Int64n, Uint64n etc functions. The single N function does that instead.

There was a suggestion to make PCG implement BinaryMarshaler and BinaryUnmarshaler, which has been accepted.

There was a suggestion to use more efficient algorithms for ExpFloat64 and NormFloat64, which has been accepted.

There was a suggestion to use more efficient but subtly biased fixed-point multiplication-based algorithms for Int64N and related functions. Careful benchmarks do not seem to bear out the benefits of these, so I've left them using a variant of Lemire's algorithm that is less efficient only in the rare cases where it is correcting the subtle bias.

There was a suggestion to use a more complex implementation of Float64 that spreads some of the probability of very small values around to even smaller values that would otherwise never be generated. Specifically, values betwen 0 and 1/2⁵³ are never generated, so the suggestion is to generate 0 and 1/2⁵³ with probability less than the current 1-in-2⁵³ and reuse some of that probability for values in between. This does not seem worth the cost for two reasons. First, the simple division algorithm produces numbers that have uniform gaps between them. That is, the gaps near 1 are the same size as the gaps near zero. That specific uniformity is lost if you get clever about creating smaller gaps near zero. Second, many times the result of Float32 or Float64 is scaled or translated or both (Float64()*X + Y). The +Y undoes all the work to create those gaps, and the *X scales the gaps so that in the new range it's still not true that every possible floating point value in the range will be generated. (This basic rationale is in the proposal text below as well, since it was included in the text used to begin the discussion at #60751.)

There was a suggestion to remove the indirection of the Source abstraction, but that abstraction is important for being able to substitute a different pseudo-random algorithm, especially in simulations that care about the algorithm. The suggestion was motivated by performance reasons, but I am confident any performance problems can be handled by devirtualization in the compiler.

There was a suggestion to use v2/math/rand instead, but generally the v2 seems like a "lower order bit" than the package path, and so it should come after the package path. That form would also break 'go test math...' or at least not include math/rand. Another, related problem with v2/math/rand is that at some point we may want to break the standard library into separate modules. For example a crypto module could provide crypto/.... If some crypto packages are v2, like crypto/tls/v2, then there is no problem with the module named crypto providing both crypto/tls and crypto/tls/v2. However, the module named crypto cannot provide v2/crypto/tls, because strings.HasPrefix(v2/crypto/tls, crypto/) == false. I don't know whether it's a good idea to break the standard library up this way or not, but I think we want to at least leave that door accessible in case we want to walk through it. v2/crypto/tls or v2/math/rand would block that door. It is worth noting that the standard library is not special in being allowed to introduce v2 subdirectories for specific packages. Any module can do this, and in particular v1 modules can do this.

There was a suggestion to leave the top-level Read removed but add back rand.Rand.Read. The need for this is unclear, so it seems worth leaving out for now.

There was a suggestion to provide access to a goroutine-safe implementation of Source. That is not a common need, and it can be implemented trivially as a wrapper around rand.Uint64.

There was a suggestion to rename the package from math/rand to math/pseudorand, to try to draw more of a distinction between math/rand and crypto/rand. I have not done this, for a few reasons. First, even crypto/rand can be pseudo-random, just in a cryptographically stronger way. Second, the names are long and not Go-like. Third, there is already an established name for this package, and it is math/rand. If you notice there are packages named math/rand and math/rand/v2, the relationship is clear. If you notice packages named math/rand and math/pseudorand, the relationship is much less clear. Just as we are conservative about changing established API from v1 to v2, we should be conservative about changing established names.

There was a hyperbolic suggestion that Go "would do a great service to its users by making it as hard as possible to use any RNG other than crypto/rand." We are not going to take that approach, but we've added ChaCha8 as a source you can construct explicitly, and we've also changed the top-level functions to use ChaCha8 underneath, although this is not a documented guarantee.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Adjust the ExpFloat64 and NormFloat64 algorithms to remove bias. (Not implemented yet.)

I have an example implementation of this in https://github.com/zephyrtronium/pgregory_rand/tree/master/misc/practrand which I used to verify that it does resolve the bias detected by practrand. My approach uses recalculated 1024-step ziggurats specifically built for 64-bit PRNGs to improve the rejection procedure efficiency, which gives about -6% ns/op versus the 128-step normal ziggurat and +4% ns/op versus the 256-step exponential one (possibly due to bounds checking? I can't investigate at the moment), at the cost of the tables being a collective 48 kB instead of 4.5 kB.
goos: linux
goarch: amd64
pkg: math/rand
cpu: 12th Gen Intel(R) Core(TM) i5-1235U
               │ /home/branden/old.bench │      /home/branden/new.bench       │
               │         sec/op          │   sec/op     vs base               │
NormFloat64-12               3.961n ± 2%   3.709n ± 0%  -6.35% (p=0.000 n=20)
ExpFloat64-12                3.801n ± 1%   3.974n ± 0%  +4.56% (p=0.000 n=20)
geomean                      3.880n        3.840n       -1.04%

An alternative implementation is to use the same tables but adjusting the input to avoid reusing random bits between the step selection and the final output, which would leave tables unchanged and should result in the same performance but still resolve the bias.
This is out of band for the proposal per se, but would it be appropriate for me to send in a CL based on 502506 implementing the new ziggurats? I don't know whether or how I can do that.

@zephyrtronium If you can send a CL with the new code that'd be great. We will not be able to submit it as is, but I can lift it from there and add it to the v2 stack. 48kB of table is a lot more than 4.5kB, so your alternative leaving the tables unchanged sounds like the right approach. Thanks!

Creating math/rand/v2 will let us work out tooling issues (support for v2 packages in gopls, goimports, and so on)

Typically packages are identified in code by the last portion of their import path.  This would be undesirable for packages versioned this way, so is the subtext here that tools like goimports would recognize math/rand/v2 and write import statements with renamed identifiers (import rand "math/rand/v2")?

@joeshaw Tools like goimports already recognize math/rand/v2 and understand that it is 'rand' even without a renamed import. Such paths are common already for the root package of a module that is >=v2.

People seem overall happy with this proposal, since we already hashed almost everything out in the previous discussion. I've updated the CL stack with recent adjustments and updated benchmarks. Thanks to @zephyrtronium for contributing fixes for ExpFloat64 and NormFloat64, now included in the stack.
After discussion with @FiloSottile, I've added a ChaCha8 source alongside the PCG source, so that people who want cryptographically strong randomness can have it.

Also based on discussion with @FiloSottile, I've changed the implementation of the top-level random functions to use an unexported per-OS-thread ChaCha8 source. (Anyone who wants this in Source form can build a trivial Source out of rand.Uint64, as noted before.)
The top-level per-thread ChaCha8 source is slower than the per-thread wyrand source I had been using in the stack, but it's about the same speed as the top-level locked source in math/rand. We eliminate the lock but use the cost savings to pay for cryptographic randomness by default instead. This seems like a reasonable trade. In particular, wyrand is less well understood than either PCG or ChaCha8, so it seems strange to have a package that exports PCG and ChaCha8 and then uses something less robust implicitly in the top-level functions.
I've timed using each of them, and ChaCha8 is a little faster than PCG on 32-bit, a little slower on 64-bit, but overall quite similar. Both are slower than wyrand, but wyrand is fairly trivial. Given the choice between PCG and ChaCha8 for the top-level randomness, ChaCha8 has a similar cost but provides cryptographic strength. That makes accidental use of math/rand/v2 instead of crypto/rand much less of a problem.
[This is a separate comment so people can thumbs-up or thumbs-down the idea of using ChaCha8 as the global generator separate from the other update.]

If we do keep ChaCha8 as the global generator and commit to having some cryptographic global generator like ChaCha8 in the future, we could potentially bring back both the top-level Read function and the Rand.Read method.
In the earlier discussion, some people asked what to do about getting short byte sequences from the PRNG. We essentially sacrificed the convenience of Read for the security of forcing people over to crypto/rand. But if we make the top-level Read backed by a cryptographic generator, we could bring Read back and have both convenience and security.
Not entirely sure whether this is worth doing, but it seems worth discussing.
[This is a separate comment so people can thumbs-up or thumbs-down the idea of bringing Read back separate from the other updates.]

@rsc

ChaCha8 requires maintaining 304 bytes of extra state in the per-OS-thread m structure in the runtime.

If I checked correctly, an m is currently 408 bytes, so this seems like a lot? Is it possible this might slow down unrelated code by the extra size?

If we do keep ChaCha8 as the global generator and commit to having some cryptographic global generator like ChaCha8 in the future, we could potentially bring back both the top-level Read function and the Rand.Read method.

ISTM that crypto/rand.Read is still more secure, is it not? AIUI it uses facilities by the kernel to get data, which I would tend to trust more than the Go runtime to do this correctly (no offense - common OS kernels just have more eyes on them).

I feel that 304 bytes is too much for the default source. Making chacha8 easy to use is great, but let's keep the default one as PCG because it is very small. 19 times smaller in fact.

The m struct tends to be noise compared to the per-thread stack allocated by the operating system.
On my MacBook Pro, for example, an m's stack is 512 kB. Another 304 bytes is noise.
Even on the systems where C is not involved and Go allocates the stacks, we allocate 8 kB.

My usual stance is that cryptographically secure PRNGs should be used for cryptographic applications and not general purpose ones. A rough analogy is that we don't advise people to use atomic operations when they don't need atomicity: even when it isn't measurably worse, it's a tool with a particular semantic purpose. For that reason, unless it is legitimately the case that users should choose ChaCha8 over crypto/rand for some cryptographic purposes (not at all my field of expertise, I'd appreciate clarification), I can't say I'm a fan of advertising it as cryptographically secure.
However, as I've advocated on other proposals, I believe it's important to present multiple choices of PRNG in any library. Having options indicates especially to new programmers that there are reasons to choose one PRNG over another. Here we could have advice along the lines of, "ChaCha8 is a suitable PRNG for most purposes. Applications which require many independent random sequences may prefer PCG, which has similar throughput and a much smaller state but marginally lower statistical quality over billions of variates."
Considering that advice, including ChaCha8 makes me want the Jump operation on PCG. Compared to repeated seeding which is subject to the birthday problem, jumping by 2^64 steps yields up to 2^64 PCG states that are guaranteed independent for 2^64 calls to Uint64. That's very valuable for exactly the cases where I'd choose PCG over ChaCha8. Of course, a proposal can wait until after this one is accepted, but I think it's valuable to consider it as a reason to provide both generators.

@rsc Perhaps we are talking about different things. One of my original points regarding the need to replace the generator was the possibility of a lock-free simulation by putting a generator in every object. There may be many thousands, or even much more than that, such items in a large simulation. The size of the generator matters then.
Please clarify what the status of PCG would be in your proposal. Is it just another generator, is it the default when you ask for a new source (which is what I would prefer), or does it just not exist at all?

@robpike My understanding is that ChaCha8 would be the "global source", as in a lock-free per-m (or per-p) source used when calling the package-scoped functions. This is different from today, where there is one locked source used by the package-scoped functions.
Additionally, there would be two exported types PCGSource and ChaCha8Source (well, I'm not sure about the latter one. It seems of dubious use), each with their own custom seeding, suitable for your purpose.
That is, you could use a PCGSource as a field in a struct, for just 16 bytes of state, but if you just called rand.N(42), you'd use a properly seeded CSPRNG.

Maybe it's time to post the full proposed API here.

 I meant more like a go doc output, so one can see what function attaches to which generator, and which are per-m, and so on.

I'm not particularly against it, but if the main concern for the removal of (non-topLevel) Rand.Read is the similarity with crypto/rand, why not rename it and also remove the io.Reader logic?  I.e. something like Rand.Fill([]byte).  Or, to keep the Rand API more minimal, rand.Fill(r Rand, b []byte).

@rsc missing MarshalBinary/UnmarshalBinary for ChaCha8?

While there's merits to keeping the signature of Shuffle the same as in math/rand, I feel like this is a perfect opportunity to use generics and add a generic implementation instead.
I've come across some code which incorrectly shuffles code by providing a mistakenly implemented version of Shuffle, which are both obvious programmer errors, but can often be easy to miss:
rand.Shuffle(len(s), func(i, j int) {
  s[i] = s[j]
})

rand.Shuffle(len(s), func(i, j int) {
  s[i], s[j] = s[i], s[j]
}

This is something that a generic version like (func Shuffle[T ~[]any](s T)) would address, at the cost of some few cases where Shuffle is called on a non-slice context.
For what it's worth, (and the sample size is small) there's no uses of Shuffle in the go source tree that don't provide a swap function that I could find.

Instead of changing Shuffle(), maybe a generic swap function could be added to slices that could simplify the usage. Something like rand.Shuffle(s, slices.Swap[int]). Or maybe just add a rand.ShuffleSlice(). Or both. That way rand.Shuffle() doesn't have to be restricted to slices.

@jnowls Not everything that one wants to shuffle is a slice. And if it's a slice, it doesn't necessarily have to be single element-wise.

@robpke sorry for the delay - I've posted a diff in Gerrit showing the full v2 docs on the right and the v1 docs on the left for comparison.
https://go-review.git.corp.google.com/c/go/+/520036/1/src/math/rand/v2/doc.txt

Thank you @fzipp, I have fixed the URL. (For incredibly frustrating security reasons, any time people at Google visit the public URLs we get redirected to this Google-internal URL, and then we often forget to cahnge 'git.corp.google' to 'googlesource' when pasting back.)

I'm still not clear on the motivation for adding a CSPRNG in particular to math/rand/v2. In what circumstances would I choose ChaCha8 over crypto/rand? When would I choose crypto/rand over ChaCha8?

@zephyrtronium, crypto/rand will give you unreproducible randomness. You would use rand.NewChaCha8 if you wanted repeatable randomness, such as for a simulation, but for whatever reason you believed that PCG was not high enough quality randomness. There are certainly good arguments that in certain demanding cases PCG is not random enough. On the other hand, ChaCha8 being cryptographically strong means that it is definitely random enough for any simulation. Instead of having to pick a single one to provide, math/rand/v2 can provide both under clear names and let users pick. This also future proofs the choice, in that if there is some better algorithm in the future, we can add it next to NewChaCha8 and NewPCG and there won't be one that is the "privileged" default.
Providing ChaCha8 also lets us use it for the top-level functions. This also serves as a bit of a belt-and-suspenders defense against code that should use crypto/rand but doesn't. In this case, the damage will be far more limited because ChaCha8 is itself cryptographically strong and therefore unpredictable, to an extent that PCG simply is not. Changing the global generator also affects math/rand, so even very old code that accidentally uses math/rand will be improved.
I spoke to @robpike about his concerns about ChaCha8 being what the top-level functions use, and I believe those are resolved. Rob did not realize there is no "default" source anymore, because rand.NewSource is replaced by rand.NewChaCha8 and rand.NewPCG - you have to say what you want (as I just noted in the first paragraph of this comment).

Have all remaining concerns about this proposal been addressed?

@rsc https://github.com/golang/go/issues/61716#issuecomment-1672631554

How the default ChaCha8 source (used by top-level functions) will be populated? From the CL 516860 is seems like is uses getRandomData function, which reads the /dev/urandom file, but in case of an  error it seems to use nanotime() to set the seed. Is this fine??

@mateusz834 Thanks I will get the Marshal methods added. Consider them part of the proposal.

How the default ChaCha8 source (used by top-level functions) will be populated? From the CL 516860 is seems like is uses getRandomData function, which reads the /dev/urandom file, but in case of an error it seems to use nanotime() to set the seed. Is this fine??

We will look into that. These reads no longer fail on modern systems so it's not much of an issue.

@rsc

These reads no longer fail on modern systems so it's not much of an issue.

Yeah, but there is still a possibility that the ChaCha8 might not be initialized with cryptographically secure random data (unlikely), at least that should be documented in the package docs. Also it would be probably better to use the getRandom syscall (as crypto/rand does) instead of reading /dev/urandom.

@rsc I would love to see my comment get addressed, I feel that if we are recreating the api for math/rand, a second look over shuffling over slices should be considered, even if a different version or nothing comes out of it :)

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

@jdemeyer I think the proposal is pretty clear, that there is no guarantee for the per-OS-thread source (given that goroutines are scheduled freely to OS-threads, that doesn't even seem possible). I also think it's pretty clear that the individual Source implementations will produce stable streams for the same seed.
I think the one thing that requires a clear statement is if a *rand.Rand produces the same values from all its methods, when used with the same Source. I would assume it is guaranteed, as that's the recommended way to get reproducible simulations. If so, the algorithm used for the Intn method (for example) can not change in future Go versions, though the algorithm used for the Intn function can (as the default source is not guaranteed to produce a stable stream anyways).

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

I also wonder what will happen when the getrandom syscall blocks (because there is no entropy),
crypto/rand prints an error to stderr in this case:
https://github.com/golang/go/blob/638e0d36d2a6b2efce0550978bf48e7df1166a0b/src/crypto/rand/rand_unix.go#L44-L46C2

Was recently running some tests that used some random data. They genuinely didn't care what the data was, just wanted it to be anything at all not just zeros. The switch from math/rand.Read to crypto/rand.Read made that go from <1% of CPU time to, I think, around 10% of CPU time used by the entire test run.
I think my intuition here is that the arguments against using a PRNG as a random data source are much weaker when talking about test cases than they are when talking about production usage. But also, I think it's important to note that at least on some systems (I was hitting this on a Mac), the performance penalty for using the crypto reader is pretty devastating.
It really feels like "I genuinely don't care if the data's any good, I just want a few KB of bits that aren't completely obviously patterned" is a real use case. On the other hand, it's probably easy enough to synthesize it from Uint64(), and that's probably equivalent to what's happening internally anyway.
I just want to stress, though, that the performance penalty is not uniformly trivial on at least some current platforms.

These changes are now all submitted for Go 1.22.


fix(kit): update statically HostBinding in line-clamp

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows Conventional Commits
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Refactoring
[ ] Code style update
[ ] Build or CI related changes
[ ] Documentation content changes

What is the current behavior?
Closes #3087

What is the new behavior?

Does this PR introduce a breaking change?

[ ] Yes
[x] No

@vladimirpotekhin hello, please review me)


Trying to install via docker into a debian system and getting no response

Describe the bug
I have used docker compose to try and install. Compose gives no errors and the container starts successfully. However when I try and hit the external http port I get nothing and when I goto portainer and look at the logs it shows no logs. I can access the containers console but I dont know where to look for log info
Here is my docker compose file. I am using postgres here but also started with sqllite to the same result. The postgres container appears to the up and the logs for that container confirm this
The local directories /root/speedtest/config and /root/speedtest/web exist but are empty
Anything I should look at to start?
version: '3.3'
services:
    speedtest-tracker:
        container_name: speedtest-tracker
        ports:
            - '8080:80'
#            - '8070:443'
        environment:
            - PUID=0
            - PGID=0
            - DB_CONNECTION=pgsql
            - DB_HOST=db
            - DB_PORT=5432
            - DB_DATABASE=speedtest_tracker
            - DB_USERNAME=speedy
            - DB_PASSWORD=password
            - TZ=Europe/Tallinn
        volumes:
            - /etc/localtime:/etc/localtime:ro
            - /root/speedtest/config:/config
            - /root/speedtest/web:/etc/ssl/web
        image: 'ghcr.io/alexjustesen/speedtest-tracker:latest'
        restart: unless-stopped
        depends_on:
            - db
    db:
        image: postgres:15
        container_name: speedtest-postgres
        restart: always
        environment:
            - POSTGRES_DB=speedtest_tracker
            - POSTGRES_USER=speedy
            - POSTGRES_PASSWORD=password
        volumes:
            - /root/speedtest/db:/var/lib/postgresql/data

Unfortunately on startup the container initialization process takes a while (2 to 5 minutes, depending on the hardware), you need to be patient.
As soon as it completes, you'll see the logs through docker logs speedtest-tracker command. If you don't see any log it means it didn't complete the startup phase yet.
From what I could analyze, it seems to be a problem with php-fpm...at startup I can see php-fpm process hitting the cpu with various processes for quite some time...as soon as it finishes, the container starts and I can see the log.
On RPi platform this can last many minutes, unfortunately. I already told @alexjustesen about this.
If you don't see the logs...it means the container didn't start, so you can't hit the http port.

This is helpful thank you. I went back to my container and it still doesn't work but now I see error logs telling me to run it as another user/group beside root.
All good, I can work on this issue. Thank you for pointing this out

now I see error logs telling me to run it as another user/group beside root

That's a good advice. I run it wih user id 1000, and chown the mapped folders/subfolders ($PWD/config and $PWD/certs) to user 1000:
version: '3.3'
services:
  speedtest-tracker:
    image: ghcr.io/alexjustesen/speedtest-tracker:v0.11.17
    container_name: speedtest-tracker
    restart: unless-stopped
    ports:
      - 8008:443
    environment:
      #TZ: Europe/Rome
      PUID: 1000
      PGID: 1000
      DB_CONNECTION: mysql
      DB_HOST: yyyyyyyy
      DB_PORT: nnnnn
      DB_DATABASE: speedtest_tracker
      DB_USERNAME: yyyyyyyyy
      DB_PASSWORD: xxxxxxxxxx
      TELEGRAM_BOT_TOKEN: 'xxxxxxxxxxx'
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - $PWD/config:/config
      - $PWD/certs:/etc/ssl/web


Support skipping files

This is a first draft of skipping resource files.
Not Implemented, yet
At this moment, following features are not implemented.

wildcard
skipping all files in folder
must not start with "/" (.gitignore ignores first slashes)
negation ("!" symbol at the beginning of the line)

Sample skip file
Same as .gitignore file, developers should specify relative path from --rswiftignore file. (I don't think it should accept using "..")
# filter Colors.jpg
ResourceApp/Images/Colors.jpg
# filter GdyBkltter1911.ttf
ResourceApp/Fonts/GdyBkltter1911.ttf

Other comments
I cherry-pick your commits but some of them conflict with master. So, you better check all of the commits listed here.
Let me know if you want me to squash my commits.
Thanks, in advance!

Could you give me some clue how to fix this problem? or how to set up CI?

Seems like Bitrise tries to checkout your commit on the wrong repo or something. No worries about that, I'll look into it later.
I can only authorize 2 persons atm so I cant easily let you in Bitrise. But if you build and run all tests locally it should give the same result as Bitrise does.

Thanks! As long as you can check my code, I'm ok.

Do you want me to support wildcard or specify folder features in this PR? (I'm not sure how long does it take...)
ResourceAppTest's testWarningsAreLogged fails even in master branch. Other than that since I didn't add any test cases, this PR passes all test cases.

Looks good, thanks for your effort so far, I think the most important feature to have is wildcard support. The most common use cases imo are:

Ignore all files of a certain type: **.ttf should ignore any ttf file regardless folder depth
Ignore a whole directory: some/folder should ignore anything in that folder including subfolders
Ignore certain files in a folder: some/folder/*.jpg should ignore all jpg in that folder
Ignore certain files in a folder: some/folder/**.jpg should ignore all jpg in that folder and subfolders

I think that it would be most practical to call out to the glob c-function. That would have all these features without we having to implement that ourselves. What do you think?

I like your idea comparing with reinventing the wheel. I will work on that.

So, I integrated glob and notice it does not support **. I think Python or other language glob supports ** but not C.
22c9ad991c839e78cb85ef493aba2081da0a36d9 only support the following feature using glob.

Ignore certain files in a folder: some/folder/*.jpg should ignore all jpg in that folder

By the way, does gitignore support the following feature?

Ignore certain files in a folder: some/folder/**.jpg should ignore all jpg in that folder and subfolders

Cool! Thanks for your work on this.
Git does support it as stated in the documentation, but it seems they don't use the C implementation of the glob function. I looked into it and found the commit where they implement this feature. There you see that they use wildmatch to implement it.
Along the way I found this C library called wildmatch with the same name (it's not the same code as git uses, but it has about the same feature set). We could look into it, if we could include this in the R.swift project we could use that implementation of wildmatch and also support the ** feature.
What do you think?

That works. I will take a look.
I don't read code, yet but I found Swift version of glob with ** support in gist https://gist.github.com/efirestone/ce01ae109e08772647eb061b3bb387c3

That also looks promissing! Do you have some time to give one of these options a try? :)

Of course! One thing I'm concern about is I'm not good at licensing. If my pull request violate license, please let me know.

Apache license seems okay, especially if we just leave that code alone. I'll also add a statement in the Readme if we depend on an other library.

The Swift version of Glob does not work well for **.strings or *.strings. It works if the patten is **/*.strings. I will try wildmatch

Could you help me integrating C library? Here is my working branch https://github.com/shiraji/R.swift/tree/skip-file-wildmatch

Looked into it, turns out the bridging header wasn't configured correctly, this PR fixes it: https://github.com/shiraji/R.swift/pull/1
Would be nice if wildcard does what we want! If it turns out that it's hard to use or also doesn't support the exact matching we need I think the Swift gist version could also be okay. **/*.strings isn't a bad syntax perse, but if we can have more gitignore style syntax that would be nice!

Thanks for your pull request! It compiles now. However, the result is the same as Swift's version. Since this library is written by Swift, I think the Swift gist version would be better. What do you think?

Awesome! Thanks for putting time into this and figuring this our.
Also agreed, having C code in the project is not ideal, would be nicer to use the Swift version if they have nearly the same features.

Add Glob.swift 🚀
Current features

Ignore certail file: some/folder/foo.strings should ignore the exact file
Ignore certain files in a folder: some/folder/*.jpg should ignore all jpg in that folder
Ignore certain files in a folder: some/folder/* should ignore all files in that folder
Ignore certain files in a folder: some/**/*.jpg should ignore all jpg in sub directory of some.
Ignore a whole directory: some/folder/* should ignore anything in that folder including subfolders

Missing features

Ignore all files of a certain type: **.ttf should ignore any ttf file regardless folder depth
Ignore a whole directory: some/folder should ignore anything in that folder including subfolders

I thought just use hasPrefix instead of using == but this leads filtering wrong files.
I guess if we want to those features, we need to change Glob.swift
Now I start wonder how I can test this code...Do you think I should integrate Glob.swift's test, too?

Awesome! Thanks for the work so far.
Some questions that come to mind:

You describe "ignore a whole directory including subfolders" and "ignore all files in that folder" both as some/folder/*. I think there is a typo in there somewhere?
"Missing feature" **.ttf doesn't work, but can you instead do **/*.ttf? That would be a good workaround I think.

On the testing, yes I think it is good to put the glob tests als into R.swift and probably we should write some tests for IgnoreFile.swift also in R.swift itself. The ResourceApp can have an ignore file for a few "end-to-end" tests to see if that is working.
Note to myself, we shouldn't forget to write some documentation about this feature.

OK, update it! I forget to mention **/*.ttf feature.

## Current features

* Ignore certail file: `some/folder/foo.strings` should ignore the exact file
* Ignore certain files in a folder: `some/folder/*.jpg` should ignore all jpg in that folder
-* Ignore certain files in a folder: `some/folder/*` should ignore all files in that folder
-* Ignore certain files in a folder: `some/**/*.jpg` should ignore all jpg in sub directory of `some`.
+* Ignore certain files in a folder: `some/**/*.jpg` should ignore all jpg in directory of `some`
* Ignore a whole directory: `some/folder/*` should ignore anything in that folder including subfolders
+ * Ignore all files of a certain type: `**/*.ttf` should ignore any ttf file regardless folder depth

## Missing features

* Ignore all files of a certain type: `**.ttf` should ignore any ttf file regardless folder depth
* Ignore a whole directory: `some/folder` should ignore anything in that folder including subfolders

OK, I added test cases for Glob.swift. This actually helpful writing documentation.
I have questions about test cases. I'm trying to write test cases that the resource is missing.
ignore file
# Filtering single file
ResourceApp/Images/Sky.tiff

Testing
let imageMirror = Mirror(reflecting: R.image.self)
print(imageMirror.children.count) // show 0.

I thought using Mirror is the only way to test it. Do you have any suggestion?
By the way, I'm having hard time to creating test cases for IgnoreFile.swift. If I add test cases for ResourceApp's ignore file, is it OK? or do you have any idea how to test IgnoreFile.swift?

Could you help me figure out how to test this, @mac-cain13 ?

For sure! I'm crazy busy atm, but as soon as I have some time I'll dive into this PR. I think we're pretty close to a first version of this feature that we can merge.
Thanks again for your time!

Good to hear that! I will leave this PR until you give me feedback.
Sorry for borthing you many times.
2016年10月31日(月) 16:37 Mathijs Kadijk<EMAIL_ADDRESS>
For sure! I'm crazy busy atm, but as soon as I have some time I'll dive
into this PR. I think we're pretty close to a first version of this feature
that we can merge.
Thanks again for your time!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mac-cain13/R.swift/pull/281#issuecomment-257230188,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADgVQtsoQ5b1JzQL3bYkVFpoTw217Hguks5q5ZqlgaJpZM4KZ-ar
.

Finally took some time to review/test/merge this PR! It's in master now and will be in the next release. Main thing I want to do is add a test and run it in a real life project before releasing a stable version.
Thanks again for all the time you put into this!

@mac-cain13 Nice! Thanks a lot.


@parent tag is not escaping

@parent is not escaping when the data comes from the MySQL but it get's compiled and executed. This can be a security issue.
I have created a sample repo to demonstrate the issue https://github.com/abhimanyusharma003/laravelSample

Clone the repo and run composer install
Run php artisan migrate
Run php aritsan db:seed ( Which will create a user with name @parent )
Visit home page

You will see a notice Master sidebar only display if @\parent tag is executed. which means that @parent tag is executed and not escaped out when it is getting data from MySQL.
I'm just fetching the first user from MySQL in routes.php file https://github.com/abhimanyusharma003/laravelSample/blob/master/app/Http/routes.php then that data passed to view child ( Location: resouces/views/child.blade.php )
You can see at line no 4. {{ $user->name }} https://github.com/abhimanyusharma003/laravelSample/blob/master/resources/views/child.blade.php#L4 this is the place where blade supposed to escape @parent tag but it is not rather it is excution it and appending it master.blade.php
Expected Result:
    @parent

This is appended to the master sidebar.

Current Result:
Master sidebar only display if @\parent tag is executed.
This is appended to the master sidebar.

PS: @parent is the also the name of user in database.
Thanks

You should NEVER execute php code from user input.

That's what you're doing here.

Looking at your code there, I don't see why you have an issue though, because you're just echoing a value in php.

How come @parent is php code ?

Because it gets compiled by blade into php, then the file is required.

From your code sample there, that's not happening though.

That sort of thing would only happen if you're actually building files from user input.

I can 100% guarantee you that {{ $user->name }} will NOT ever execute anything or mess with blade in any way. It's literally impossible.

It's just compiling down to escape then echo.

I'm doing nothing special you can see, but somehow @parent is executing. Let's say if there is some textarea on my website and i'm displaying in the same way.
So can you please tell how to avoid so that @parent will get executed.

I'm doing nothing special you can see, but somehow @parent is executing.

That's impossible from that code sample.

We don't even have a way to execute @parent. It has to be compiled first then the result must be required.

So sorry. Just read our code again. It seems that part isn't done at the "compile" level, but is done after.

You have indeed uncovered a security issue. I'm going to contact Taylor.

@GrahamCampbell many many thanks for reopening the issue. :)

Not at all, security is very important. Sorry I took a while to realise what was going on here.

In future, could you please contact Taylor directly regarding security issues, because now this is public knowledge to anyone wanting to target Laravel apps.

IMO, the issue here is not so much the escaping, but more, that there's an inherit design floor here that allows this to happen in the first place.

Ok, so sorry for not contacting Taylor directly and I will make sure of this next time. I will wait for some update. Yes you are right it's not major security issue, but it will break the template/design of the website.

I reported this exact issue months ago - and it got closed to due inactivity: https://github.com/laravel/framework/issues/7888

@TheShiftExchange this so strange, I'm giving try to few things but i'm not sure what causing this. I can't say much but this need to resolved quickly.

Is anyone able to look into this? The previous fix we had was very good, but it had to be reverted due to a bug.

I looked into this and put something together, just need some tests and i will send a PR.

Instead of depending on composer post-update scripts, should there be a mechanism inside laravel framework to check for a version file and delete all the framework related cache files when the current version does not match the version file?
It would make easy to fix issues like this one without breaking backward compatibility.

Sorry to disturb, but can somebody fix it for 5.3 at least? I only know how to remove the feature, if you like me to submit a PR!? I am sending this just because 5.3 is coming soon and I think it is better not to have this bug there, than be backward compatible.

The PR had to be reverted not because of BC, but because it didn't actually work properly. We'd definitely accept a PR that does work. :)

Yes it should be fixed, not removed.

@taylorotwell can I request re-open for community to help ?

any stable solution to this without manual escaping? it is dynamic data that contains @parent and it's creating trouble

this was fixed in https://github.com/laravel/framework/pull/16033


chore: use<EMAIL_ADDRESS>in corepack

This PR brings:

Ensure to use<EMAIL_ADDRESS>to adopt the highest resolution by default.
Experiment with<EMAIL_ADDRESS>in CI to evaluate if it can reduce the linking time by CoW during installation.

No significant time savings were found.

👍🏻👍🏻

No significant time savings were found.

The macOS CI seems faster.
before:

2m 28s https://github.com/web-infra-dev/modern.js/actions/runs/6478733373/job/17590991464
2m 33s https://github.com/web-infra-dev/modern.js/actions/runs/6466689446/job/17555223573

after:

1m 38s https://github.com/web-infra-dev/modern.js/actions/runs/6481309345/job/17598550151

Not sure if it’s caused by network differences..

I propose that we can create a PR for pnpm to display the time spent on the resolution and linking steps.

LGTM~


Crash

How to upload a file? File too big.

There are some file sharing websites like https://gofile.io which accept big files, or we can provide a private FTP server access.
If the link can not be shared publicly, drop me an email.

https://gofile.io/d/KgjrL2
Floating point division by zero.

1.ts = https://gofile.io/d/KgjrL2

cat Dockerfile
FROM almalinux

RUN yum install -y git automake autoconf libtool pkgconfig make gcc gcc-c++ zlib-devel wget

RUN git clone https://github.com/MediaArea/ZenLib.git \
    && cd ZenLib/Project/GNU/Library \
    && ./autogen.sh \
    && ./configure --enable-static --enable-debug \
    && make

RUN git clone https://github.com/MediaArea/MediaInfoLib.git \
    && cd MediaInfoLib/Project/GNU/Library \
    && ./autogen.sh \
    && ./configure --enable-static --enable-staticlibs --enable-debug\
    && make

RUN git clone https://github.com/MediaArea/MediaInfo.git \
    && cd MediaInfo/Project/GNU/CLI \
    && ./autogen.sh \
    && ./configure --enable-staticlibs --enable-debug \
    && make \
    && make install

WORKDIR /MediaInfo

RUN ls

RUN mediainfo  --Help

COPY 1.ts 1.ts

RUN ls

RUN yum install -y valgrind

RUN valgrind --leak-check=full --show-leak-kinds=all mediainfo /MediaInfo/1.ts

./Dockerfile-create-image
Sending build context to Docker daemon  31.72MB
Step 1/12 : FROM almalinux
 ---> f4b24db3d26d
Step 2/12 : RUN yum install -y git automake autoconf libtool pkgconfig make gcc gcc-c++ zlib-devel wget
 ---> Using cache
 ---> f485a118435d
Step 3/12 : RUN git clone https://github.com/MediaArea/ZenLib.git     && cd ZenLib/Project/GNU/Library     && ./autogen.sh     && ./configure --enable-static --enable-debug     && make
 ---> Using cache
 ---> a1f099a3b03e
Step 4/12 : RUN git clone https://github.com/MediaArea/MediaInfoLib.git     && cd MediaInfoLib/Project/GNU/Library     && ./autogen.sh     && ./configure --enable-static --enable-staticlibs --enable-debug    && make
 ---> Using cache
 ---> ebfd67b1bc9b
Step 5/12 : RUN git clone https://github.com/MediaArea/MediaInfo.git     && cd MediaInfo/Project/GNU/CLI     && ./autogen.sh     && ./configure --enable-staticlibs --enable-debug     && make     && make install
 ---> Using cache
 ---> 35cbbb026a30
Step 6/12 : WORKDIR /MediaInfo
 ---> Using cache
 ---> deaee3271778
Step 7/12 : RUN ls
 ---> Using cache
 ---> 3493b8040301
Step 8/12 : RUN mediainfo  --Help
 ---> Using cache
 ---> 2a4529c4161c
Step 9/12 : COPY 1.ts 1.ts
 ---> Using cache
 ---> 2d998f47471f
Step 10/12 : RUN ls
 ---> Using cache
 ---> 170040c11e88
Step 11/12 : RUN yum install -y valgrind
 ---> Using cache
 ---> 690e17a6020a
Step 12/12 : RUN valgrind --leak-check=full --show-leak-kinds=all mediainfo /MediaInfo/1.ts
 ---> Running in 8087beaaa942
==1== Memcheck, a memory error detector
==1== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==1== Command: mediainfo /MediaInfo/1.ts
==1==
General
ID                                       : 1 (0x1)
Complete name                            : /MediaInfo/1.ts
Format                                   : MPEG-TS
File size                                : 30.2 MiB
Duration                                 : 9 s 960 ms
Overall bit rate mode                    : Variable
Overall bit rate                         : 25.4 Mb/s
Frame rate                               : 25.000 FPS

Video
ID                                       : 211 (0xD3)
Menu ID                                  : 1 (0x1)
Format                                   : HEVC
Format/Info                              : High Efficiency Video Coding
Format profile                           : Main@L5@Main
Codec ID                                 : 36
Duration                                 : 10 s 0 ms
Width                                    : 3 840 pixels
Height                                   : 2 160 pixels
Display aspect ratio                     : 16:9
Frame rate                               : 25.000 FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits

Audio
ID                                       : 221 (0xDD)
Menu ID                                  : 1 (0x1)
Format                                   : AAC LC SBR PS
Format/Info                              : Advanced Audio Codec Low Complexity with Spectral Band Replication and Parametric Stereo
Commercial name                          : HE-AACv2
Format version                           : Version 4
Format settings                          : Implicit
Muxing mode                              : ADTS
Codec ID                                 : 15-2
Duration                                 : 10 s 26 ms
Channel(s)                               : 2 channels
Channel layout                           : M
Sampling rate                            : 48.0 kHz
Frame rate                               : 23.438 FPS (2048 SPF)
Compression mode                         : Lossy
Delay relative to video                  : -38 ms
Language                                 : Russian

Menu
ID                                       : 4095 (0xFFF)
Menu ID                                  : 1 (0x1)
Format                                   : HEVC / AAC
Duration                                 : 9 s 960 ms
List                                     : 211 (0xD3) (HEVC) / 221 (0xDD) (AAC, Russian)
Language                                 :  / Russian
Service name                             : 19262
Service provider                         : TightVideo
Service type                             : digital television

==1==
==1== HEAP SUMMARY:
==1==     in use at exit: 0 bytes in 0 blocks
==1==   total heap usage: 242,498 allocs, 242,498 frees, 59,222,196 bytes allocated
==1==
==1== All heap blocks were freed -- no leaks are possible
==1==
==1== For lists of detected and suppressed errors, rerun with: -s
==1== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Removing intermediate container 8087beaaa942
 ---> fc9dd8f4c580
Successfully built fc9dd8f4c580

<\pre>

@pavel-pimenov  This is surprising but actually there is really a crash, in the GUI, not in the CLI, on Windows.
This may be due to a specific compiler config (the GUI is compiled with another compiler) which flag a division by 0 as a failure (this is not mandatory for float, result can be also just inf).
If you know how to activate a crash on a division by zero with Valgrind or Visual Studio, I am interested, it would help to catch the source of the division by 0.

(Note: the Visual Studio DLL build in debug mode has also no crash, so right now playing with Visual Studio options for seeing which option triggers the crash)

The option to change for avoiding a crash is /arch, from "Not set" to "/arch:IA32" ("legacy 32-bit x86 instruction set without any vector operations and using x87 for floating-point calculations"), but there is no crash if I run that with the command line. So impossible to have automatic catch of the crash, looks like that we need to remove a piece of code, compile, test. Boring... @pavel-pimenov if you have another solution for catching the place of the crash, I am very interested in it!


The command "chatGPT MD: chat" should collect questions in respect to the separator

Hi there,
My markdown file contains many Q&A by chatGPT. It has more than 2000 words and 10,000 characters.
Then I created a new question as below example (NOTE: the plugin works well before reaching this point)

My new question is here .... (it's about 200 words)

Then I executed the command "chatGPT MD: chat" and encountered this error

GUESS: the plugin is collecting all the texts from the beginning of the file.
EXPECTED BEHAVIOR: it should collect question content from the nearby separator
 so that only my new question is sent to chatGPT and no error of token limit to occur.
Thank you very much for the good works!
Bests,

Hi @tkt028,
Considering implementing a history feature which may help this (https://github.com/bramses/chatgpt-md/issues/55), but no, chatgpt md does not make case by case logic calls about how many messages to send to the api


Let idle notification trigger while WCing/fishing if bags are full

Sometimes the animation keeps going until you try to chop the next log/catch the next fish, which creates a period where you aren't idle, but don't need to be doing the same action. Might be nice to have an idle trigger if actively doing either of those activities and your bags fill up.

You can trigger notifications upon reaching a full inventory via the Advanced Notifications plugin on the hub.


Ionic and Angular Update

If I got together a working version with the latest Ionic 2 and Angular 2 version would you want me to make a PR? Is that something you'd be interested in?

That'd be awesome thanks! We have this which should be current: github.com/auth0/auth0-ionic2

@jacobscarter
Could you PR or publish it?
Im trying to get this code working on the latest ionic and angular 2 but it fails to load the application.
Would be higly appreciated. thank you