fix: Climatisation State for 2024 Q4

Add mapping for climatisation state for 2024 Q4

Tested and working it added 1 extra entity now!

Can you also add the timer left? the timer that counts down from 30 to 0

I see the timer left in this request url:
https://emea.bff.cariad.digital/vehicle/v1/vehicles/XXX/selectivestatus?jobs=climatisation
=> remainingClimatisationTime_min
Maybe also the target temp is interesting?
=> targetTemperature
Body:
{
  "climatisation": {
    "climatisationSettings": {
      "value": {
        "carCapturedTimestamp": "2024-07-24T18:50:05Z",
        "targetTemperature_C": 21,
        "targetTemperature_F": 70,
        "unitInCar": "celsius",
        "climatizationAtUnlock": false,
        "windowHeatingEnabled": false,
        "zoneFrontLeftEnabled": false,
        "zoneFrontRightEnabled": false
      }
    },
    "climatisationStatus": {
      "value": {
        "carCapturedTimestamp": "2024-07-24T18:50:09Z",
        "remainingClimatisationTime_min": 30,
        "climatisationState": "cooling"
      },
      "requests": [
        {
          "status": "successful",
          "operation": "start",
          "body": {
            "climatizationAtUnlock": false,
            "zoneFrontRightEnabled": false,
            "zoneRearLeftEnabled": false,
            "zoneRearRightEnabled": false,
            "targetTemperature": 21,
            "targetTemperatureUnit": "celsius",
            "climatisationWithoutExternalPower": true,
            "windowHeatingEnabled": false,
            "zoneFrontLeftEnabled": false
          },
          "requestId": "47c44560-02ff-47ef-85a5-6772b7afc580",
          "vcfRequestId": "d31e96f4-3aa0-4839-878c-416deefc457d"
        }
      ]
    },
    "windowHeatingStatus": {
      "value": {
        "carCapturedTimestamp": "2024-07-24T18:50:01Z",
        "windowHeatingStatus": [
          {
            "windowLocation": "front",
            "windowHeatingState": "off"
          },
          {
            "windowLocation": "rear",
            "windowHeatingState": "off"
          }
        ]
      }
    }
  }
}

I've added Remaining Climatisation Time please retest.
As for target temp, it will take a little more time as I'll have to modify a few other files since the entity doesn't exist yet.
Ideally, entities like remaining time, and target temp, would be attributes to the Climatisation State entity, but that would take a good amount more work as well.
Please submit a feature request for Target Temp and any others so myself or someone else can get to it when they have more time.

ok, the remainingClimatisationTime is also working!  :-)
the target temp is for another time then :-)

Just trying to understand, you said :
As for target temp, it will take a little more time as I'll have to modify a few other files since the entity doesn't exist yet.
But you added the "remainingClimatisationTime_min" also with a few lines of code? that entity didnt exist either?
I also see the target temp in this request:
https://emea.bff.cariad.digital/vehicle/v1/vehicles/XXXX/selectivestatus?jobs=charging%2CchargingTimers%2CchargingProfiles%2CdepartureTimers%2Cclimatisation%2CclimatisationTimers%2CdepartureTimers%2Cmeasurements%2Cmeasurements%2CoilLevel%2Caccess%2CvehicleLights%2CvehicleHealthWarnings
{
......
.....
  "climatisation": {
    "climatisationSettings": {
      "value": {
        "carCapturedTimestamp": "2024-07-24T19:01:58Z",
        "targetTemperature_C": 21,
        "targetTemperature_F": 70,
        "unitInCar": "celsius",
        "climatizationAtUnlock": false,
        "windowHeatingEnabled": false,
        "zoneFrontLeftEnabled": false,
        "zoneFrontRightEnabled": false
      }
    },
    "climatisationStatus": {
      "value": {
        "carCapturedTimestamp": "2024-07-24T19:02:22Z",
        "remainingClimatisationTime_min": 0,
        "climatisationState": "off"
      },
      "requests": [
        {
          "status": "successful",
          "operation": "start",
          "body": {
            "climatisationWithoutExternalPower": true,
            "climatizationAtUnlock": false,
            "zoneRearRightEnabled": false,
            "targetTemperature": 21,
            "targetTemperatureUnit": "celsius",
            "zoneFrontRightEnabled": false,
            "zoneRearLeftEnabled": false,
            "windowHeatingEnabled": false,
            "zoneFrontLeftEnabled": false
          },
          "requestId": "7d6b8b21-4b01-4a14-b599-438038fb3bec",
          "vcfRequestId": "c49f2344-05b7-4fd7-adb8-6623d11f4f7c"
        },
        {
          "status": "timeout",
          "operation": "stop",
          "requestId": "1a0bffcb-fb63-4f99-b499-56b35083e80f",
          "vcfRequestId": "e74f83bf-544e-4500-a7e5-3aeefb514dd8",
          "group": 9,
          "info": "Your vehicle is not reachable at the moment. Please try again later."
        }
      ]
......
.....
}

No worries!
To create new entities requires telling the integration where to look, how to interpret the data, and providing all the metadata for the new entities. That requires modification and code in 3 different files.
The Climatisation State and Remaining Climatisation Time entities already existed for other vehicles, so the data interpreatation and metadata was already there, i just had to tell it where to look for Climate state and Remaining Time for your vehicle.

Here is the full list of existing sensors and diagnostics, if you see any others that need mapping to your vehicle, please let us know in a new issue so we can track development.

ah ok, makes sense
i'm comparing your entities in your screenshot to mine now ...
for sensors:
you have also longterm.short trip  trip data sensoers, not sure what it is?
for diagnostics, you have a lot more, but its because you have a hjybrid :-)
as for the door/window/trunk sensors, i have them, but the states doesnt work... they are always locked...
But also in the myAudi app, they dont change... probably the app needs an update for my new car :-)

ah ok, makes sense i'm comparing your entities in your screenshot to mine now ... for sensors: you have also longterm.short trip trip data sensoers, not sure what it is?
for diagnostics, you have a lot more, but its because you have a hjybrid :-)
as for the door/window/trunk sensors, i have them, but the states doesnt work... they are always locked... But also in the myAudi app, they dont change... probably the app needs an update for my new car :-)

Trip Data is unavailable for your vehicle at this time according to the logs:
2024-07-24 19:07:15.608 DEBUG (MainThread) [custom_components.audiconnect.audi_connect_account] Trip data support is disabled for VIN: *************6552. Exiting update process.
2024-07-24 19:07:15.608 DEBUG (MainThread) [custom_components.audiconnect.audi_connect_account] Trip data support is disabled for VIN: *************6552. Exiting update process.

as you're suggesting, the Audi App may need to be updated, or we may need to find more services for newer vehicles. If you find anything with HTTPTool let us know in a feature request.

Will do, will check next time when the app gets updated...
Are you also going to work on the climate start ?

And thnx! Much appreciated 👍

I merged this.

Will do, will check next time when the app gets updated...
Are you also going to work on the climate start ?

I will be working on it when I have time. I'm desperately missing it with the summer heat.


struct.error: ushort format requires 0 <= number <= 0xffff

PyZatt version: 2.0.0
Python version: 3.8
Operating System: Windows 10

Enroll Fingerprint
I Tried to enroll fingerprint according to test_other.py but i got this error :(
Traceback (most recent call last):
  File "D:/Projects/GitHub/Tman/tman_tests/zkteco_test.py", line 42, in <module>
    outfile.write(z.download_fp(user1_id, user1_fp_idx))
  File "D:\Projects\GitHub\Tman\venv\lib\site-packages\pyzatt-2.0.0-py3.8.egg\pyzatt\zkmodules\data_user.py", line 291, in download_fp
    req_fp.extend(struct.pack('<H', self.id_to_sn(user_id)))
struct.error: ushort format requires 0 <= number <= 0xffff

what device are you using?

what device are you using?

ZKTeco K40 Device


we want to use vmware fusion and virtualbox as a vagrant provider

add support for vagrant provider virtualbox

    * 05_up.sh detects installed provider and defaults vmware_fusion
    * Vagrantfile add nic, memory and vcpu customizations for virtualbox
    * examples/common.yaml change openstack:nova:libvirt_type to qemu

@saneax could you take a look too, since you were working on something similar?

Any update on this?

@cmurphy I could push a new branch with fixed the issue with checking the env for the provider type and with fixed whitespacing, would that be okay?

@mmailand plese do, thanks!

Folks,
sorry not to update so far, Will try to get this completed over the
weekend. However whatever is quicker and better is perfectly OK.
warm regards
/sanjay
On Thu, Jul 16, 2015 at 6:46 AM, Colleen Murphy<EMAIL_ADDRESS>wrote:

@mmailand https://github.com/mmailand plese do, thanks!
—
Reply to this email directly or view it on GitHub
https://github.com/puppetlabs/puppetlabs-openstack/pull/199#issuecomment-121794961
.

--
Sanjay Upadhyay
http://saneax.blogspot.com


Present View overFullScreen in SwiftUI

Hi, thank you for your article. But I couldn't understand one line on your code.
content: (Binding) -> ContentView
What is this code for and does Binding return a bool value? Thank you for your response. best regards.


[Snyk] Security upgrade daisyui from 2.51.6 to 4.0.0

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to fix one or more vulnerable packages in the `npm` dependencies of this project.
Changes included in this PR

Changes to the following files to upgrade the vulnerable dependencies to a fixed version:

package.json
package-lock.json

Vulnerabilities that will be fixed
With an upgrade:

Severity
Priority Score (*)
Issue
Breaking Change
Exploit Maturity

661/1000  Why? Recently disclosed, Has a fix available, CVSS 7.5
Uncontrolled resource consumption SNYK-JS-BRACES-6838727
Yes
No Known Exploit

661/1000  Why? Recently disclosed, Has a fix available, CVSS 7.5
Inefficient Regular Expression Complexity SNYK-JS-MICROMATCH-6838728
Yes
No Known Exploit

(*) Note that the real score may have changed since the PR was raised.
Check the changes in this PR to ensure they won't cause issues with your project.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
🛠 Adjust project settings
📚 Read more about Snyk's upgrade and patch logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Uncontrolled resource consumption

👷 Deploy Preview for classy-horse-4ef088 processing.

Name
Link

🔨 Latest commit
357095ccec4f1909ccd5315a186bffd2cf79a741

🔍 Latest deploy log
https://app.netlify.com/sites/classy-horse-4ef088/deploys/66425c17ad902c0008a87c7d


dockerhub organisation account

to get away from using @lasseke's image

orgaization can be:  metos, noresm, emerald, or latice

did we land on using NorESMhub? Mats B. seemed like the person to ask for permission if needed.
Closing this issue for now.


Spelling, grammar and clarity pass-over

Disambiguated some of the more confusing terminology, corrected grammar where appropriate.

same here for symbols ? :

@Hew-ux I think I'll do that later, many duplicated strings to translate in the code (some in uppercase, same as lowercase, etc. in the .po file)

ah, I understand what you mean now @evoflash72 , that's something I can take a look at. But for this PR, I'll leave it as it is for now. It's ready to be merged.

@nadenislamarre I noticed you updated the fr translation while I was updating the .po files, just a heads up

merged joinski's de

I've now learned of how changes to the English strings affect translations and want to do this properly from the ground up. I'll keep this PR only as a reference for the strings I did change.


PlotSquared doc transfer (in markdown)

Overview

Adding PlotSquared docu in Markdown format.
Description

Submitter Checklist

[X] Make sure you are opening from a topic branch (/feature/fix/docs/ branch (right side)) and not your main branch.
[X] Ensure that the pull request title represents the desired changelog entry.
[X] New public fields and methods are annotated with @since TODO.
[X] I read and followed the contribution guidelines.

Looks like I forgot to spot https://github.com/IntellectualSites/documentation/blob/4c010a10b066ae3fe4da194a78ad944adbc6a43d/plotsquared/old/changelog-old.md?plain=1#L15
The links point to the old wiki still, instead of the anchors within the same page, do you want to file a PR?


Hooks called twice on every rendering ? Error or "Feature" ?

Hey!
I switched from an older version to version 1.0 and now I have the problem that the Hooks called twice. Here is an example of what I mean:
This is my code for one route:
Router.route('/search/:page?/:what?/:where?', function () {
	var params;
	params = this.params;

	this.wait(Meteor.subscribe('business_search', {what : params.what, where : params.where}));

	if (this.ready()) {
		console.log('############### THIS.READY() ###############');
		this.render('search_result');
	} else {
		this.render('loaderDefault');
	}

	this.render('searchBig', {
		to : 'top',
		data : {
			what : params.what,
			where : params.where
		}
	});

}, {
	name : 'search',
	onBeforeAction : function () {
		console.log('onBeforeAction called');
		this.next();
	},
	onAfterAction : function () {
		console.log('onAFTERAction called');
	}
});

After running this route directly OR when clickung on a link which is "linking" to this route the console has this output:
onBeforeAction called
onAFTERAction called
onBeforeAction called
############### THIS.READY() ###############
onAFTERAction called

As you can see the onBeforeAction and also the OnAfterAction is always called twice.
I made a "test": When removing the "if (this.ready()) [...]" Block the Hooks are just called once per running ... so the this.ready() seems to be the problem ... but then I do not rly understand how to use this in the right way ?

did anyone solf this? i have the same issue...

No idea why but multiply:iron-router-progress is causing this. Removed it and the hook isn't called anymore @cmather @ndemoreau

i am doing it this nasty way : (any suggestions)
onAfterAction: function () {
if (typeof ranOnceCon == 'undefined')  {
console.log("sendingLogMessage");
Meteor.call('sendLogMessage');
ranOnceCon = 1;
}
}

@cmather Hi Chris, I have reproduced the error. [Here] (https://github.com/niranjans/testRouter) is the Github repo. And you can test the problem [here] (http://testrouter1.meteor.com/).
Right on the homepage, just open the browser console and you will notice that WaitOn and data are being run twice. When there is no WaitOn, then the data just runs once as normally is expected.
Let me know if I can help.

I have seen this aswell. Is there some resolution to this?

+1
I have also same problem.

waitOn: function() {
            console.log("subscribing");
            return [ Meteor.subscribe('companies')];
    },

subscribing logged twice.

IR hooks are run reactively, so if there are any reactive data sources, like Meteor.subscribe or Meteor.userId(), the hook will be rerun whenever the data source changes (eg becomes ready or gets logged in)

My workaround (for now?) is similar to what @ahmadthd suggested:
onAfterAction: function() {
    if (Tracker.currentComputation.firstRun) {
	    // called only once per route
	}
}

Like @advany I removed multiply:iron-router-progress and the problem of the action being called twice went away. So it seems to be related to that package. The problem is I would like to actually use that package. I might file a bug with them.

I switch the flow router


FromIterator Implementation for SlotMap, DenseSlotMap, and HopSlotMap

I was missing a FromIterator implementation for SlotMap to be able to do
let _map1 = SlotMap::<DefaultKey, i32>::from_iter([1, 2, 3]);

and
let _map2 = vec![1, 2, 3].into_iter().collect::<SlotMap<DefaultKey, i32>>();

I added implementations for DenseSlotMap and HopSlotMap as well and a quickcheck test for each implementation.
Please let me know if the implementation is not what you expect or it clashes with your vision of slotmap.

What is the use case for this? It allows you to have a bunch of elements in a slot map, yes but you don't get the associated keys.

I create multiple SlotMaps and iterate through them regularly. These are generated from Vecs for which I would like to use collect. For every entry that needs additional information, I create entries in a SecondaryMap. I only require the keys for insertion into the SecondaryMap and for individual elements that are referenced from outside the maps. They are retrieved while iterating through them.

I think if we implement this we should also have Extend. And if we implement Extend I think the implementation for collect should just be to create a new SlotMap and call extend on it.

Probably makes sense. I don't have time at the moment but I could write a proposal in about 2 weeks.


Unable to install in windows

Tried building in windows PC with
npm install node-occ
output
><EMAIL_ADDRESS>install D:\projects\current\Struct\node_modules\node-occ
> node-pre-gyp install --fallback-to-build

node-pre-gyp ERR! Tried to download(404): https://github.com/openwebcad/node-occ/releases/download/0.3.0/occ-v0.3.0-node-v72-win32-x64.tar.gz
node-pre-gyp ERR! Pre-built binaries not found for<EMAIL_ADDRESS>and<EMAIL_ADDRESS>(node-v72 ABI, unknown) (falling back to source compile with node-gyp)

Fails when also tried building from source.

Could you please try my branch out: https://github.com/OpenWebCAD/node-occ/pull/52

Let me ask you something first; is your build environment 32-bit Windows or 64-bit windows?

I am using 64-bit windows, will try out your branch soon.

It should be possible to install node-occ usng npm again now
> node --version
v10.20.1
> npm install node-occ

><EMAIL_ADDRESS>install C:\temp\aaa\node_modules\node-occ
> node-pre-gyp install --fallback-to-build

node-pre-gyp WARN Using needle for node-pre-gyp https download
[node-occ] Success: "C:\temp\aaa\node_modules\node-occ\lib\binding\occ.node" is installed via remote

><EMAIL_ADDRESS>postinstall C:\temp\aaa\node_modules\node-occ
> node post-install.js

npm WARN<EMAIL_ADDRESS>No description
npm WARN<EMAIL_ADDRESS>No repository field.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})

+<EMAIL_ADDRESS>updated 1 package and audited 313 packages in 14.489s

> node -e "const{ occ }= require('node-occ'); console.log(occ.makeBox(1,2,3).numFaces);"
6

Let me know if it is working on your end

Thanks it works!


A way to create objects in bulk?

@bmihelac @andrewgy8 @yozlet
Is there a way to create objects in bulk during an import? Maybe overriding a method?
The default way of calling save for every row is slow when you have a big dataset to import. However, it is extremely slow when that data set also has foreign keys.
There was never an answer to #588

Anybody has a solution?

This is a very quick hack I tried and seemed to work. Not sure the implications in other features like validation, database integrity errores and stuff like that. It should work as expected but test and use at your own risk. I didn't use this in the end that's why I didn't continue testing.
class BulkSaveMixin:
    bulk_instances = []
    bulk_m2m_fields = []

    def save_instance(self, instance, using_transactions=True, dry_run=False):
        self.before_save_instance(instance, using_transactions, dry_run)
        if not using_transactions and dry_run:
            # we don't have transactions and we want to do a dry_run
            pass
        else:
            self.bulk_instances.append(instance)
        self.after_save_instance(instance, using_transactions, dry_run)

    def save_m2m(self, obj, data, using_transactions, dry_run):
        if not using_transactions and dry_run:
            # we don't have transactions and we want to do a dry_run
            pass
        else:
            for field in self.get_import_fields():
                if not isinstance(field.widget, ManyToManyWidget):
                    continue
                self.bulk_m2m_fields.append((field, obj, data, True))

    def after_import(self, dataset, result, using_transactions, dry_run, **kwargs):
        self._meta.model.objects.bulk_create(self.bulk_instances)
        for m2m_field in self.bulk_m2m_fields:
            self.import_field(*m2m_field)

AFAIK, there is not a way currently to create objects in bulk. The current implementation creates objects one by one.
A quick scan of the solution @honi posted looks like it may work, but since I have not tried it myself, I can not say for sure.
If someone tries the solution above, and it does work as expected, please let us know. And if you feel up for it, write some tests and submit a PR!

I have achieved some decent performance improvements for bulk creates of new rows.  Some notes here
See also #1030, #730, #588

bulk create is now supported


Tensorboard information

There was a question about the overtraining of the model. Here is the training data of the model (screen[1..3].png). Is the underlined place (screen1.png) an overtraining point or did I misunderstand something? So the question arises if smoothing is set to 0.999 (screen2.png) - it is not clear at all that the model is initially incorrectly trained. Also in the last screenshot (screen3.png), the strange behavior of the training is broken, is this a mistake?

If you terminate the training without reaching the next checkpoint's save epoch, then when you continue training, the program can only continue training from the previous saved checkpoint, and the loss curve recorded by Tensorboard will experience this kind of backtracking, which generally has no impact on the training.

For the issue of incomplete display of Tensorboard's loss curve, it is only a matter of scaling level. You can try setting the smoothness to 0, double-click the loss curve box you want to view, reset the scaling level, and then adjust the smoothness to 0.6, which may be more convenient to view.


Broken Pipe / Resource temporarily unavailable

Hello,
When running cargo criterion it compiles fine but immediately gives me this error:
Error: Unable to open connection to bench target bron_kerbosch

Caused by:
    Resource temporarily unavailable (os error 35)
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: IoError(Os { code: 32, kind: BrokenPipe, message: "Broken pipe" })', /Users/heychsea/.cargo/registry/src/github.com-1ecc6299db9ec823/criterion-0.3.3/src/lib.rs:1437:13
stack backtrace:
   0:        0x10b013b0f - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h8ad47541fb823094
   1:        0x10b03c98e - core::fmt::write::he23e9bd6497f06c3
   2:        0x10b00e6c7 - std::io::Write::write_fmt::h91528f1131e6004e
   3:        0x10b0159ba - std::panicking::default_hook::{{closure}}::h1983f014a45a477e
   4:        0x10b0156fc - std::panicking::default_hook::hb0d9b93b5be8b120
   5:        0x10b015f88 - std::panicking::rust_panic_with_hook::h9f3faafe0983de5c
   6:        0x10b015b52 - rust_begin_unwind
   7:        0x10b05dc1f - core::panicking::panic_fmt::h0a2d1b3ca0b14316
   8:        0x10b05db25 - core::result::unwrap_failed::h71fe5d08237d0e52
   9:        0x10ae40576 - criterion::Criterion<M>::benchmark_group::ha490315f5602edbe
  10:        0x10ae4c62d - bron_kerbosch::seq::h54a8f4033907fcc9
  11:        0x10ae4ca90 - bron_kerbosch::main::hae67f97122857ce5
  12:        0x10ae48566 - std::rt::lang_start::{{closure}}::ha1ddb8b9e0daa0b0
  13:        0x10b0163b9 - std::rt::lang_start_internal::h795af50241e12334
  14:        0x10ae4cbe9 - main

On the other side, running cargo bench works perfectly.
I'm using cargo-criterion v1.0.0-alpha3 and criterion-rs v0.3.3 and I'm working on macOS 15.5.5.

Hey, thanks for the bug report!
I'm pretty well stumped as to what might cause this, and I don't have a Mac available to experiment on. Here's what I can say, in case some mac user would like to help track this down:
cargo-criterion opens a non-blocking localhost socket and passes the port number to the benchmark in an environment variable. Criterion.rs benchmarks will detect that variable and open a connection to that socket, to exchange information about the benchmarks with cargo-criterion. When the socket is opened, there's a quick handshake to exchange information about the versions of the two sides. cargo-criterion sends a message first, then reads the response from Criterion.rs. This is all in src/connection.rs in both repos.
What happened here is that cargo-criterion was able to send its handshake message (or at least enough of it that Criterion.rs thought the connection was successfully opened) but then failed to read the response. Strangely, this doesn't seem to have produced any error message. Instead, the failure to open the connection was returned up to src/bench_target.rs, which reports the error up the call stack and eventually terminates the cargo-criterion process with the "Unable to open connection to bench target" error message. The panic backtrace is mostly a red herring - this is Criterion.rs thinking the connection was opened successfully and then failing to write to it later on.
I've pushed a branch which adds a bit of extra debug output to that code. Could you try installing from that branch:
cargo install --git https://github.com/bheisler/cargo-criterion.git --branch issue_12
And then running the following command to enable as much debug output as possible:
CRITERION_DEBUG=1 RUST_BACKTRACE=FULL cargo criterion --debug
That will enable cargo-criterion & Criterion.rs' internal debug output, full backtraces, and also compile the benchmarks in debug mode so that they give the complete backtrace with line numbers.

Thanks for investigating ! Unfortunately, the output does not seem to be really useful:

Debug output
```
08:18:29 [INFO] Executing bron_kerbosch - "/Users/heychsea/Documents/Rust/graph-proto/target/debug/deps/bron_kerbosch-2a0450f129717ad7"
08:18:29 [DEBUG] (1) cargo_criterion::bench_target: Running '"/Users/heychsea/Documents/Rust/graph-proto/target/debug/deps/bron_kerbosch-2a0450f129717ad7" "--bench"'
Error: Unable to open connection to bench target bron_kerbosch
Caused by:
0: Failed to receive benchmark-hello message
1: Resource temporarily unavailable (os error 35)
Criterion.rs DEBUG: Runner version: [1, 0, 0]
thread 'main' panicked at 'called Result::unwrap() on an Err value: IoError(Os { code: 32, kind: BrokenPipe, message: "Broken pipe" })', /Users/heychsea/.cargo/registry/src/github.com-1ecc6299db9ec823/criterion-0.3.3/src/lib.rs:1437:13
stack backtrace:
0:        0x10a5314ff - backtrace::backtrace::libunwind::trace::hdff08984d375d02a
at /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
1:        0x10a5314ff - backtrace::backtrace::trace_unsynchronized::h1a393bcdfc10be62
at /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
2:        0x10a5314ff - std::sys_common::backtrace::_print_fmt::h063c5f96b3f1deaf
at src/libstd/sys_common/backtrace.rs:78
3:        0x10a5314ff - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h8ad47541fb823094
at src/libstd/sys_common/backtrace.rs:59
4:        0x10a55a5ce - core::fmt::write::he23e9bd6497f06c3
at src/libcore/fmt/mod.rs:1069
5:        0x10a52bef7 - std::io::Write::write_fmt::h91528f1131e6004e
at src/libstd/io/mod.rs:1504
6:        0x10a53356a - std::sys_common::backtrace::_print::ha16b452b57f4cc4c
at src/libstd/sys_common/backtrace.rs:62
7:        0x10a53356a - std::sys_common::backtrace::print::hdcfe7b1cd849140e
at src/libstd/sys_common/backtrace.rs:49
8:        0x10a53356a - std::panicking::default_hook::{{closure}}::h1983f014a45a477e
at src/libstd/panicking.rs:198
9:        0x10a5332ac - std::panicking::default_hook::hb0d9b93b5be8b120
at src/libstd/panicking.rs:218
10:        0x10a533b38 - std::panicking::rust_panic_with_hook::h9f3faafe0983de5c
at src/libstd/panicking.rs:511
11:        0x10a533702 - rust_begin_unwind
at src/libstd/panicking.rs:419
12:        0x10a56de8f - core::panicking::panic_fmt::h0a2d1b3ca0b14316
13:        0x10a56dd95 - core::result::unwrap_failed::h71fe5d08237d0e52
14:        0x109f0aeb7 - core::result::Result<T,E>::unwrap::h5d152e65de72fd91
at /Users/heychsea/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/src/libcore/result.rs:1005
15:        0x109ed7502 - criterion::Criterion::benchmark_group::h04ca15f15d4ff0f7
at /Users/heychsea/.cargo/registry/src/github.com-1ecc6299db9ec823/criterion-0.3.3/src/lib.rs:1437
16:        0x109f049d8 - bron_kerbosch::seq::h00ff477123a6d269
at benches/bron_kerbosch.rs:50
17:        0x109f04fcd - bron_kerbosch::seq_small::h0f328d6aad0b23ac
at benches/bron_kerbosch.rs:70
18:        0x109f05163 - bron_kerbosch::benches::hdf9755073dd2fc51
at /Users/heychsea/.cargo/registry/src/github.com-1ecc6299db9ec823/criterion-0.3.3/src/macros.rs:71
19:        0x109f051f0 - bron_kerbosch::main::h78f48a930b47a7a4
at /Users/heychsea/.cargo/registry/src/github.com-1ecc6299db9ec823/criterion-0.3.3/src/macros.rs:124
20:        0x109f0c39e - std::rt::lang_start::{{closure}}::h67d530a2f09e4f8f
at /Users/heychsea/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/src/libstd/rt.rs:67
21:        0x10a533f69 - std::rt::lang_start_internal::{{closure}}::hcd3fdb11e5e01a21
at src/libstd/rt.rs:52
22:        0x10a533f69 - std::panicking::try::do_call::hd8e8ada4e26d8788
at src/libstd/panicking.rs:331
23:        0x10a533f69 - std::panicking::try::hf951a93b7ea92f92
at src/libstd/panicking.rs:274
24:        0x10a533f69 - std::panic::catch_unwind::he82f6de4bcfc0f8c
at src/libstd/panic.rs:394
25:        0x10a533f69 - std::rt::lang_start_internal::h795af50241e12334
at src/libstd/rt.rs:51
26:        0x109f0c381 - std::rt::lang_start::h410bf05594d441d5
at /Users/heychsea/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/src/libstd/rt.rs:67
27:        0x109f05282 - main
</details>

I've found a solution, but it involves updating criterion-rs. After a bit of debugging I've found that localhost was translated to ::1 for the socket, and setting it to <IP_ADDRESS> to force IPV4 seems to fix everything.

Further research shows that localhost is not considered valid as an IPV4 address by the standard library (at least on my machine 1.44.1), however it is with IPV6 and for some reason on my mac IPV6 TcpStream does not seem to work (even though a it works with a netcat).

Further research shows that error 35 is EAGAIN on macOS, and it happens when there is nothing to read yet. So the Connection::new method fails because there is nothing to read (happens only in non blocking mode).

On macOS, the non-blocking socket seems to give a lot of WouldBlock errors, I somehow managed to make it work a bit by protecting the reads but this does not protect everything and the socket is closed elsewhere :/ (And also, it seems extremely unoptimised)
loop {
    match socket.read_exact(&mut hello_buf) {
        Ok(_) => break,
        Err(e) if e.kind() == std::io::ErrorKind::WouldBlock => {}
        Err(e) => return Err(e).context("Unable to read from socket"),
    }
    std::thread::yield_now();
}

Output
❯ cargo criterion --debug -- '^Sequential/small/1/BK-Basic$'
    Finished test [unoptimized + debuginfo] target(s) in 0.14s
Benchmarking Sequential/small/1/BK-Basic: Warming up for 3.0000 s
Warning: Unable to complete 100 samples in 5.0s. You may wish to increase target time to 43.4s, or reduce sample count to 10.
Sequential/small/1/BK-Basic
                        time:   [406.51 ms 410.18 ms 414.11 ms]
                        change: [-11.955% -10.257% -8.5448%] (p = 0.00 < 0.05)
                        Performance has improved.
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Failed to send message

Caused by:
    Resource temporarily unavailable (os error 35)', src/value_formatter.rs:41:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: IoError(Custom { kind: UnexpectedEof, error: "failed to fill whole buffer" })', /Users/heychsea/.cargo/registry/src/github.com-1ecc6299db9ec823/criterion-0.3.3/src/analysis/mod.rs:106:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: IoError(Custom { kind: UnexpectedEof, error: "failed to fill whole buffer" })', /Users/heychsea/.cargo/registry/src/github.com-1ecc6299db9ec823/criterion-0.3.3/src/benchmark_group.rs:377:13
stack backtrace:
   0:        0x10700e4ff - backtrace::backtrace::libunwind::trace::hdff08984d375d02a
                               at /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
   1:        0x10700e4ff - backtrace::backtrace::trace_unsynchronized::h1a393bcdfc10be62
                               at /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
   2:        0x10700e4ff - std::sys_common::backtrace::_print_fmt::h063c5f96b3f1deaf
                               at src/libstd/sys_common/backtrace.rs:78
   3:        0x10700e4ff - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h8ad47541fb823094
                               at src/libstd/sys_common/backtrace.rs:59
   4:        0x1070375ce - core::fmt::write::he23e9bd6497f06c3
                               at src/libcore/fmt/mod.rs:1069
   5:        0x107008ef7 - std::io::Write::write_fmt::h91528f1131e6004e
                               at src/libstd/io/mod.rs:1504
   6:        0x10701056a - std::sys_common::backtrace::_print::ha16b452b57f4cc4c
                               at src/libstd/sys_common/backtrace.rs:62
   7:        0x10701056a - std::sys_common::backtrace::print::hdcfe7b1cd849140e
                               at src/libstd/sys_common/backtrace.rs:49
   8:        0x10701056a - std::panicking::default_hook::{{closure}}::h1983f014a45a477e
                               at src/libstd/panicking.rs:198
   9:        0x1070102ac - std::panicking::default_hook::hb0d9b93b5be8b120
                               at src/libstd/panicking.rs:218
  10:        0x107010b38 - std::panicking::rust_panic_with_hook::h9f3faafe0983de5c
                               at src/libstd/panicking.rs:511
  11:        0x107010702 - rust_begin_unwind
                               at src/libstd/panicking.rs:419
  12:        0x10704ae8f - core::panicking::panic_fmt::h0a2d1b3ca0b14316
  13:        0x10704ad95 - core::result::unwrap_failed::h71fe5d08237d0e52
  14:        0x1069e7eb7 - core::result::Result<T,E>::unwrap::h5d152e65de72fd91
                               at /Users/heychsea/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/src/libcore/result.rs:1005
  15:        0x1069d1f5d - <criterion::benchmark_group::BenchmarkGroup<M> as core::ops::drop::Drop>::drop::h87f6806838289151
                               at /Users/heychsea/.cargo/registry/src/github.com-1ecc6299db9ec823/criterion-0.3.3/src/benchmark_group.rs:377
  16:        0x1069d0d25 - core::ptr::drop_in_place::h365f56f6de59a2ad
                               at /Users/heychsea/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/src/libcore/ptr/mod.rs:177
  17:        0x1069e1b4a - bron_kerbosch::seq::h00ff477123a6d269
                               at benches/bron_kerbosch.rs:55
  18:        0x1069e1fcd - bron_kerbosch::seq_small::h0f328d6aad0b23ac
                               at benches/bron_kerbosch.rs:70
  19:        0x1069e2163 - bron_kerbosch::benches::hdf9755073dd2fc51
                               at /Users/heychsea/.cargo/registry/src/github.com-1ecc6299db9ec823/criterion-0.3.3/src/macros.rs:71
  20:        0x1069e21f0 - bron_kerbosch::main::h78f48a930b47a7a4
                               at /Users/heychsea/.cargo/registry/src/github.com-1ecc6299db9ec823/criterion-0.3.3/src/macros.rs:124
  21:        0x1069e939e - std::rt::lang_start::{{closure}}::h67d530a2f09e4f8f
                               at /Users/heychsea/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/src/libstd/rt.rs:67
  22:        0x107010f69 - std::rt::lang_start_internal::{{closure}}::hcd3fdb11e5e01a21
                               at src/libstd/rt.rs:52
  23:        0x107010f69 - std::panicking::try::do_call::hd8e8ada4e26d8788
                               at src/libstd/panicking.rs:331
  24:        0x107010f69 - std::panicking::try::hf951a93b7ea92f92
                               at src/libstd/panicking.rs:274
  25:        0x107010f69 - std::panic::catch_unwind::he82f6de4bcfc0f8c
                               at src/libstd/panic.rs:394
  26:        0x107010f69 - std::rt::lang_start_internal::h795af50241e12334
                               at src/libstd/rt.rs:51
  27:        0x1069e9381 - std::rt::lang_start::h410bf05594d441d5
                               at /Users/heychsea/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/src/libstd/rt.rs:67
  28:        0x1069e2282 - main
thread panicked while panicking. aborting.

Hmm. I thought I had a reproducible test case for a crash very much like this, except it disappeared when I recompiled cargo-criterion. Even reinstalling the latest version from crates.io doesn't bring it back.
Very strange.

I'm encountering this on a fresh setup with Mac OS 10.15.6, cargo-criterion 1.0.0-alpha3, criterion v0.3.3. Is there anything further I can do to help chase down the underlying issue?

Debug output
% RUST_BACKTRACE=full CRITERION_DEBUG=1 cargo criterion
   Compiling isosurface v0.0.4 (/Users/tristam/projects/rust/isosurface)
    Finished bench [optimized] target(s) in 1.97s
07:26:19 [INFO] Executing isosurface - "/Users/tristam/projects/rust/isosurface/target/release/deps/isosurface-2c9f9a590606eb28"
07:26:19 [DEBUG] (1) cargo_criterion::bench_target: Running '"/Users/tristam/projects/rust/isosurface/target/release/deps/isosurface-2c9f9a590606eb28" "--bench"'

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

07:26:19 [INFO] Executing isosurface - "/Users/tristam/projects/rust/isosurface/target/release/deps/isosurface-3040ba4e0213e406"
07:26:19 [DEBUG] (1) cargo_criterion::bench_target: Running '"/Users/tristam/projects/rust/isosurface/target/release/deps/isosurface-3040ba4e0213e406" "--bench"'
Criterion.rs DEBUG: Runner version: [1, 0, 0]
Error: Unable to open connection to bench target isosurface

Caused by:
    Resource temporarily unavailable (os error 35)

Stack backtrace:
   0: std::backtrace_rs::backtrace::libunwind::trace
             at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/../../backtrace/src/backtrace/libunwind.rs:90:5
      std::backtrace_rs::backtrace::trace_unsynchronized
             at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
      std::backtrace::Backtrace::create
             at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/backtrace.rs:316:13
   1: std::backtrace::Backtrace::capture
             at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/backtrace.rs:284:9
   2: cargo_criterion::connection::Connection::new
   3: cargo_criterion::bench_target::BenchTarget::execute
   4: cargo_criterion::main
   5: std::sys_common::backtrace::__rust_begin_short_backtrace
   6: std::rt::lang_start::{{closure}}
   7: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
             at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/core/src/ops/function.rs:259:13
      std::panicking::try::do_call
             at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/panicking.rs:379:40
      std::panicking::try
             at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/panicking.rs:343:19
      std::panic::catch_unwind
             at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/panic.rs:396:14
      std::rt::lang_start_internal
             at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/rt.rs:51:25
   8: _main
tristam@Tristams-MacBook-Pro isosurface % thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: IoError(Os { code: 32, kind: BrokenPipe, message: "Broken pipe" })', /Users/tristam/.cargo/registry/src/github.com-1ecc6299db9ec823/criterion-0.3.3/src/lib.rs:1438:18
stack backtrace:
   0:        0x10e5a04d4 - std::backtrace_rs::backtrace::libunwind::trace::hd4e4f36eb9f0f866
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/../../backtrace/src/backtrace/libunwind.rs:90:5
   1:        0x10e5a04d4 - std::backtrace_rs::backtrace::trace_unsynchronized::hddd9cf7e61567951
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:        0x10e5a04d4 - std::sys_common::backtrace::_print_fmt::hf0df20706c8d0efd
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/sys_common/backtrace.rs:67:5
   3:        0x10e5a04d4 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hddf67b5e68ee5eac
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/sys_common/backtrace.rs:46:22
   4:        0x10e5c3040 - core::fmt::write::hae6418d3f135b639
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/core/src/fmt/mod.rs:1078:17
   5:        0x10e59b0d6 - std::io::Write::write_fmt::h822c37b1fbb805d3
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/io/mod.rs:1519:15
   6:        0x10e5a23f9 - std::sys_common::backtrace::_print::hf8d765f57ebaea59
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/sys_common/backtrace.rs:49:5
   7:        0x10e5a23f9 - std::sys_common::backtrace::print::h4405042f17c9e5df
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/sys_common/backtrace.rs:36:9
   8:        0x10e5a23f9 - std::panicking::default_hook::{{closure}}::hb8c76ec6b2b5fec2
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/panicking.rs:208:50
   9:        0x10e5a1f80 - std::panicking::default_hook::h9520f36dd50be056
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/panicking.rs:225:9
  10:        0x10e5a2a7b - std::panicking::rust_panic_with_hook::hbb70e1d25c7381a9
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/panicking.rs:591:17
  11:        0x10e5a25a5 - std::panicking::begin_panic_handler::{{closure}}::hb72eee9aad2e147c
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/panicking.rs:497:13
  12:        0x10e5a0978 - std::sys_common::backtrace::__rust_end_short_backtrace::h372ff87ecb2667f3
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/sys_common/backtrace.rs:141:18
  13:        0x10e5a250a - rust_begin_unwind
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/panicking.rs:493:5
  14:        0x10e5d898f - core::panicking::panic_fmt::h261fd45d36f74dfa
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/core/src/panicking.rs:92:14
  15:        0x10e5d8895 - core::option::expect_none_failed::hf2a36714418ff407
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/core/src/option.rs:1268:5
  16:        0x10e3be53b - criterion::Criterion<M>::bench_function::h62a4757a80f13e2b
  17:        0x10e3c8ee3 - isosurface::main::hbe32f8f1f642cb6c
  18:        0x10e3b292a - std::sys_common::backtrace::__rust_begin_short_backtrace::heed8a8514d50f973
  19:        0x10e3ba6cc - std::rt::lang_start::{{closure}}::h957fbb99146e98e8
  20:        0x10e5a2ed4 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h4ab201f754b12ec0
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/core/src/ops/function.rs:259:13
  21:        0x10e5a2ed4 - std::panicking::try::do_call::h2d40bab4a9c2dc4b
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/panicking.rs:379:40
  22:        0x10e5a2ed4 - std::panicking::try::he14232182da07291
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/panicking.rs:343:19
  23:        0x10e5a2ed4 - std::panic::catch_unwind::ha032e0ba57e1000e
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/panic.rs:396:14
  24:        0x10e5a2ed4 - std::rt::lang_start_internal::hebea83fb59fe572e
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/rt.rs:51:25
  25:        0x10e3c8f79 - _main

I'm encountering this on a fresh setup with Mac OS 10.15.6, cargo-criterion 1.0.0-alpha3, criterion v0.3.3. Is there anything further I can do to help chase down the underlying issue?

Debug output
% RUST_BACKTRACE=full CRITERION_DEBUG=1 cargo criterion
   Compiling isosurface v0.0.4 (/Users/tristam/projects/rust/isosurface)
    Finished bench [optimized] target(s) in 1.97s
07:26:19 [INFO] Executing isosurface - "/Users/tristam/projects/rust/isosurface/target/release/deps/isosurface-2c9f9a590606eb28"
07:26:19 [DEBUG] (1) cargo_criterion::bench_target: Running '"/Users/tristam/projects/rust/isosurface/target/release/deps/isosurface-2c9f9a590606eb28" "--bench"'

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

07:26:19 [INFO] Executing isosurface - "/Users/tristam/projects/rust/isosurface/target/release/deps/isosurface-3040ba4e0213e406"
07:26:19 [DEBUG] (1) cargo_criterion::bench_target: Running '"/Users/tristam/projects/rust/isosurface/target/release/deps/isosurface-3040ba4e0213e406" "--bench"'
Criterion.rs DEBUG: Runner version: [1, 0, 0]
Error: Unable to open connection to bench target isosurface

Caused by:
    Resource temporarily unavailable (os error 35)

Stack backtrace:
   0: std::backtrace_rs::backtrace::libunwind::trace
             at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/../../backtrace/src/backtrace/libunwind.rs:90:5
      std::backtrace_rs::backtrace::trace_unsynchronized
             at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
      std::backtrace::Backtrace::create
             at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/backtrace.rs:316:13
   1: std::backtrace::Backtrace::capture
             at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/backtrace.rs:284:9
   2: cargo_criterion::connection::Connection::new
   3: cargo_criterion::bench_target::BenchTarget::execute
   4: cargo_criterion::main
   5: std::sys_common::backtrace::__rust_begin_short_backtrace
   6: std::rt::lang_start::{{closure}}
   7: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
             at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/core/src/ops/function.rs:259:13
      std::panicking::try::do_call
             at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/panicking.rs:379:40
      std::panicking::try
             at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/panicking.rs:343:19
      std::panic::catch_unwind
             at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/panic.rs:396:14
      std::rt::lang_start_internal
             at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/rt.rs:51:25
   8: _main
tristam@Tristams-MacBook-Pro isosurface % thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: IoError(Os { code: 32, kind: BrokenPipe, message: "Broken pipe" })', /Users/tristam/.cargo/registry/src/github.com-1ecc6299db9ec823/criterion-0.3.3/src/lib.rs:1438:18
stack backtrace:
   0:        0x10e5a04d4 - std::backtrace_rs::backtrace::libunwind::trace::hd4e4f36eb9f0f866
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/../../backtrace/src/backtrace/libunwind.rs:90:5
   1:        0x10e5a04d4 - std::backtrace_rs::backtrace::trace_unsynchronized::hddd9cf7e61567951
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:        0x10e5a04d4 - std::sys_common::backtrace::_print_fmt::hf0df20706c8d0efd
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/sys_common/backtrace.rs:67:5
   3:        0x10e5a04d4 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hddf67b5e68ee5eac
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/sys_common/backtrace.rs:46:22
   4:        0x10e5c3040 - core::fmt::write::hae6418d3f135b639
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/core/src/fmt/mod.rs:1078:17
   5:        0x10e59b0d6 - std::io::Write::write_fmt::h822c37b1fbb805d3
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/io/mod.rs:1519:15
   6:        0x10e5a23f9 - std::sys_common::backtrace::_print::hf8d765f57ebaea59
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/sys_common/backtrace.rs:49:5
   7:        0x10e5a23f9 - std::sys_common::backtrace::print::h4405042f17c9e5df
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/sys_common/backtrace.rs:36:9
   8:        0x10e5a23f9 - std::panicking::default_hook::{{closure}}::hb8c76ec6b2b5fec2
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/panicking.rs:208:50
   9:        0x10e5a1f80 - std::panicking::default_hook::h9520f36dd50be056
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/panicking.rs:225:9
  10:        0x10e5a2a7b - std::panicking::rust_panic_with_hook::hbb70e1d25c7381a9
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/panicking.rs:591:17
  11:        0x10e5a25a5 - std::panicking::begin_panic_handler::{{closure}}::hb72eee9aad2e147c
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/panicking.rs:497:13
  12:        0x10e5a0978 - std::sys_common::backtrace::__rust_end_short_backtrace::h372ff87ecb2667f3
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/sys_common/backtrace.rs:141:18
  13:        0x10e5a250a - rust_begin_unwind
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/panicking.rs:493:5
  14:        0x10e5d898f - core::panicking::panic_fmt::h261fd45d36f74dfa
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/core/src/panicking.rs:92:14
  15:        0x10e5d8895 - core::option::expect_none_failed::hf2a36714418ff407
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/core/src/option.rs:1268:5
  16:        0x10e3be53b - criterion::Criterion<M>::bench_function::h62a4757a80f13e2b
  17:        0x10e3c8ee3 - isosurface::main::hbe32f8f1f642cb6c
  18:        0x10e3b292a - std::sys_common::backtrace::__rust_begin_short_backtrace::heed8a8514d50f973
  19:        0x10e3ba6cc - std::rt::lang_start::{{closure}}::h957fbb99146e98e8
  20:        0x10e5a2ed4 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h4ab201f754b12ec0
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/core/src/ops/function.rs:259:13
  21:        0x10e5a2ed4 - std::panicking::try::do_call::h2d40bab4a9c2dc4b
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/panicking.rs:379:40
  22:        0x10e5a2ed4 - std::panicking::try::he14232182da07291
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/panicking.rs:343:19
  23:        0x10e5a2ed4 - std::panic::catch_unwind::ha032e0ba57e1000e
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/panic.rs:396:14
  24:        0x10e5a2ed4 - std::rt::lang_start_internal::hebea83fb59fe572e
                               at /rustc/1c389ffeff814726dec325f0f2b0c99107df2673/library/std/src/rt.rs:51:25
  25:        0x10e3c8f79 - _main

Same issue on macOS 11.2.1 Big Sur with cargo-criterion 1.0.1 and criterion 0.3.4.

I don't want to make a "me too" comment, but it might be useful information that this also affects Windows 10:

Debug output
17:01:53 [INFO] Executing proxybench - "C:\\Users\\user\\git\\proxybench\\target\\release\\deps\\proxybench-59ddb8dd21410019.exe"
17:01:53 [DEBUG] (1) cargo_criterion::bench_target: Running '"C:\\Users\\user\\git\\proxybench\\target\\release\\deps\\proxybench-59ddb8dd21410019.exe" "--bench"'
Criterion.rs DEBUG: Runner version: [1, 0, 1]
Error: Unable to open connection to bench target proxybench
Caused by:
Ein nicht blockierender Socketvorgang konnte nicht sofort ausgeführt werden. (os error 10035)
Gnuplot not found, using plotters backend
Stack backtrace:
0: <unknown>
1: <unknown>
2: <unknown>
3: <unknown>
4: <unknown>
5: <unknown>
6: <unknown>
7: <unknown>
8: <unknown>
9: <unknown>
10: BaseThreadInitThunk
11: RtlUserThreadStart
thread 'main' panicked at 'called Result::unwrap() on an Err value: IoError(Os { code: 10053, kind: ConnectionAborted, message: "Eine bestehende Verbindung wurde softwaregesteuert\r\ndurch den Hostcomputer abgebrochen." })', C:\Users\user.cargo\registry\src\github.com-1ecc6299db9ec823\criterion-0.3.4\src\lib.rs:1105:18
stack backtrace:
0:     0x7ff6ebda41fe - std::backtrace_rs::backtrace::dbghelp::trace
at /rustc/3f5aee2d5241139d808f4fdece0026603489afd1/library\std\src....\backtrace\src\backtrace\dbghelp.rs:98
1:     0x7ff6ebda41fe - std::backtrace_rs::backtrace::trace_unsynchronized
at /rustc/3f5aee2d5241139d808f4fdece0026603489afd1/library\std\src....\backtrace\src\backtrace\mod.rs:66
2:     0x7ff6ebda41fe - std::sys_common::backtrace::_print_fmt
at /rustc/3f5aee2d5241139d808f4fdece0026603489afd1/library\std\src\sys_common\backtrace.rs:67
3:     0x7ff6ebda41fe - std::sys_common::backtrace::_print::{{impl}}::fmt                               at /rustc/3f5aee2d5241139d808f4fdece0026603489afd1/library\std\src\sys_common\backtrace.rs:46
4:     0x7ff6ebdc309b - core::fmt::write
at /rustc/3f5aee2d5241139d808f4fdece0026603489afd1/library\core\src\fmt\mod.rs:1096
5:     0x7ff6ebd9b618 - std::io::Write::write_fmtstd::sys::windows::stdio::Stderr
at /rustc/3f5aee2d5241139d808f4fdece0026603489afd1/library\std\src\io\mod.rs:1568
6:     0x7ff6ebda6fdd - std::sys_common::backtrace::_print
at /rustc/3f5aee2d5241139d808f4fdece0026603489afd1/library\std\src\sys_common\backtrace.rs:49
7:     0x7ff6ebda6fdd - std::sys_common::backtrace::print
at /rustc/3f5aee2d5241139d808f4fdece0026603489afd1/library\std\src\sys_common\backtrace.rs:36
8:     0x7ff6ebda6fdd - std::panicking::default_hook::{{closure}}
at /rustc/3f5aee2d5241139d808f4fdece0026603489afd1/library\std\src\panicking.rs:208
9:     0x7ff6ebda6aa9 - std::panicking::default_hook
at /rustc/3f5aee2d5241139d808f4fdece0026603489afd1/library\std\src\panicking.rs:225
10:     0x7ff6ebda7890 - std::panicking::rust_panic_with_hook
at /rustc/3f5aee2d5241139d808f4fdece0026603489afd1/library\std\src\panicking.rs:591
11:     0x7ff6ebda73c1 - std::panicking::begin_panic_handler::{{closure}}
at /rustc/3f5aee2d5241139d808f4fdece0026603489afd1/library\std\src\panicking.rs:497
12:     0x7ff6ebda4b8f - std::sys_common::backtrace::__rust_end_short_backtrace<closure-0,!>
at /rustc/3f5aee2d5241139d808f4fdece0026603489afd1/library\std\src\sys_common\backtrace.rs:141
13:     0x7ff6ebda7319 - std::panicking::begin_panic_handler
at /rustc/3f5aee2d5241139d808f4fdece0026603489afd1/library\std\src\panicking.rs:493
14:     0x7ff6ebdc1920 - core::panicking::panic_fmt
at /rustc/3f5aee2d5241139d808f4fdece0026603489afd1/library\core\src\panicking.rs:92
15:     0x7ff6ebdc1763 - core::option::expect_none_failed
at /rustc/3f5aee2d5241139d808f4fdece0026603489afd1/library\core\src\option.rs:1300
16:     0x7ff6eb97f9fa - criterion::Criterion::benchmark_group::hcc976a7395a1c914
17:     0x7ff6eb9b9158 - hashbrown::raw::RawTable::insert::hb8725d1d91577b5c
18:     0x7ff6eb9649f6 - std::sys_common::backtrace::__rust_begin_short_backtrace::h735612a0fe897d28
19:     0x7ff6eba309fc - std::rt::lang_start::{{closure}}::hc57f833c45c23b07
20:     0x7ff6ebda7b67 - core::ops::function::impls::{{impl}}::call_once
at /rustc/3f5aee2d5241139d808f4fdece0026603489afd1\library\core\src\ops\function.rs:280
21:     0x7ff6ebda7b67 - std::panicking::try::do_call
at /rustc/3f5aee2d5241139d808f4fdece0026603489afd1/library\std\src\panicking.rs:379
22:     0x7ff6ebda7b67 - std::panicking::try
at /rustc/3f5aee2d5241139d808f4fdece0026603489afd1/library\std\src\panicking.rs:343
23:     0x7ff6ebda7b67 - std::panic::catch_unwind
at /rustc/3f5aee2d5241139d808f4fdece0026603489afd1/library\std\src\panic.rs:431
24:     0x7ff6ebda7b67 - std::rt::lang_start_internal
at /rustc/3f5aee2d5241139d808f4fdece0026603489afd1/library\std\src\rt.rs:51
25:     0x7ff6eb9b9667 - main
26:     0x7ff6ebdd7a80 - invoke_main
at d:\agent_work\63\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
27:     0x7ff6ebdd7a80 - __scrt_common_main_seh
at d:\agent_work\63\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
28:     0x7ffc68a47034 - BaseThreadInitThunk
29:     0x7ffc6a2dd241 - RtlUserThreadStart

Fixed in cargo-criterion-1.1.0.


another attempt to fix schedule in dependabot.yml

#1549 was 1st attempt but https://github.com/apache/pekko/runs/32649405548 still happens
still complaining about schedule
now trying to make schedule match https://github.com/pjfanning/excel-streaming-reader/blob/main/.github/dependabot.yml

https://github.com/apache/pekko/runs/32651776368 passed


fixed positons of the cards

Description

...
...
...

Related issue(s)

Thanks for contributing @Rahul-chaurasiya


Behavior for suggestions of incomplete words

... selecting a suggestion that ends with a character marking an incomplete word [e.g. the |-sign] should not be appended with a space character (as the word yet needs to be completed) ... .

Originally posted by @aarppe in https://github.com/giellalt/keyboard-crk/issues/13#issuecomment-1249657190
... but selecting a completion suggestion that does not end with a character marking an incomplete word (e.g. does not end with the |-sign or some other character used to indicate this) should be appended with a space character.
This behavior could either be implemented in the mobile speller FSTs (in which case the code should not append any space character in any event), or then it could be implemented through the code.
Whichever way we go depends on what we end up deeming as the best way for the keyboard to behave in indicating the incompleteness and completeness of both the input and suggestions.

Changed the marker of incomplete words to tilde ~.


Is there a way to translate error messages?

Hello.
We're using PEG.js in an internationalized web application. Is there a way to pass in options to customize error messages? If not, is it planned and what's the best way to achieve the goal?
Many thanks.

The SyntaxError exception thrown by a generated parser contains all the data needed for building your own error message (in the expected and found properties). Have a look at the buildMessage function to see how parser itself does it.
One small caveat is that the expectations can contain two English strings as their description: “any character” and “end of input”. This can be trivially handled using a small translation table without any support on PEG.js side.
Having a direct translation support on PEG.js side would be nice, but given the use case is solvable in reasonable way (as described above) and there is very little demand for this feature I’m closing this issue.


Use Random instead of SecureRandom in request_id

SecureRandom is quite a bit slower on Windows
Does RequestID need to use SecureRandom?
cc @lamont-granquist @stevendanna @chef/client-core

We need a unit test for generate_required_id now. it "looks like a UUID."

Since I saw this, the UUID generated is used by reporting. So long as it's a UUID then all should be well. Specifically, securerandom.uuid is generating a v4 UUID as outlined on wikipedia here:
https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_4_.28random.29
So that's the form we'd want to test around.
This stackoverflow actually has a great answer on how securerandom.uuid works: http://stackoverflow.com/questions/16650764/securerandom-uuid-vs-uuid-gem
securerandom is taking longer b/c it's trying very heard to get a random seed.  It also tries, in order:
openssl
/dev/urandom/
Win32
so it's going to fail the first two checks on Windows and try Win32. I have no idea how fast Win32 is, but it might be worth seeing if the slowdown is Ruby trying to access this.
I suspect this change is okay, but since I saw it I thought I'd drop in some more background on what securerandom is doing and why. I can tell you that when it was picked for use by Reporting it was just picked b/c it was the easiest way to get a UUID.

@mmzyk thanks for digging in. I've sometimes seen this issue on osx, but it's consistent on the windows boxes. I'm going to try the win32 api function call for getting a uuid, and if that's faster, I may just use that on windows and leave the other os's untouched. I think it generates a mac/timestamp based uuid (https://msdn.microsoft.com/en-us/library/windows/desktop/aa379322(v=vs.85).aspx). It does say the UUID is only valid on the box, however I'm not sure how big of a deal a collision is for this. If it's only used for reporting, I'm thinking it's going to be ok since you'll have both machine name and the uuid.

@jdmundrawala I'm not sure what you mean by there'll be both machine name and the uuid. By machine name you mean the node id? While that is true, that's not how the reporting db stores things - it uses the uuid as the primary key.
https://github.com/chef/oc_reporting/blob/master/db/deploy/base%401.2.0.sql#L22
While that table does have org id and node id as well, the table that stores the full details of a run only uses the uuid as the primary key and reference point back to the main table: https://github.com/chef/oc_reporting/blob/master/db/deploy/base%401.2.0.sql#L47
This is why I'm suggesting we be hesitant in straying too far from true uuids, since we don't want to naively create something that might introduce collisions at a higher rate. While I get that the chances of collisions is likely very low, I just want to make sure we use the right amount of caution around changing this. (But I also understand we need to do something to make run times not be abnormally high for windows users).

I'm satisfied that the randomness of Random will be good enough to avoid any issues with birthday collisions in the uuid generation.  With either implementation we should still require close enough to 2^61 uuids to generate a collision.

:+1: if we get tests.

guess the tests should just be that we set the version number and the reserved bits correctly. Otherwise I'm happy to do this.

this still scares me a little, let's come back to this when we've fixed all other perf issues related to windows


GPU out of memory when running infer_vos.sh/py

I am trying to run bash ./launch/infer_vos.sh ytvos, but am getting errors of "GPU out of memory".  Trying to reduce the batch_size down to 8, 4, 2, 1, but still getting the error.  I have nVidia K2000, with only  4G GPU memory.  Any suggestions/advice how to get around the issue?  Thanks.

Hi, having at least 12GB of GPU memory is the requirement for this implementation. The memory bottleneck are the context frames: depending on the test set, there may be up to 20 previous predictions accumulated in the context. Those have to stay on GPU memory. Obviously, you can move some of the computations on the CPU, but that would dramatically slow down the inference (and it's already quite slow on GPU). Nikita


mget within RedisCluster now also returns false

Bug Report

Q
A

Version(s)
2.5.0

Summary
mget within RedisCluster now also returns false on errors:
https://github.com/phpredis/phpredis/blob/35a7cc094c6c264aa37738b074c4c54c4ca73b87/redis_cluster.c#L694
Current behavior
message foreach() argument must be of type array|object, bool given thrown on line 202 of vendor/laminas/laminas-cache-storage-adapter-redis/src/RedisCluster.php
Expected behavior
An exception should be thrown

Can confirm that phpredis can return non-array return values and thus checking for the return value should work.


Add atrous_conv2d_transpose python function

Issue description : https://github.com/tensorflow/tensorflow/issues/4668
This is the first commit of the issue.
I will commit the unit test later.
I will also add the comment for the method.
Thank you for any advice.
Now I test it with:

# Input, output: [batch, height, width, depth]
x_image = tf.placeholder(tf.float32,shape=[1])
x = tf.reshape(x_image,[1,1,1,1])

#Filter: W [kernel_height, kernel_width, output_depth, input_depth]
W_cpu = np.array([[1,-1,1],[1,1,1],[-1,1,-1]],dtype=np.float32)
W = tf.Variable(W_cpu)
W = tf.reshape(W, [3,3,1,1])

strides=[1, 1, 1, 1]
padding='VALID'

y = tf.nn.atrous_conv2d_transpose(x, W, [1,5,5,1], 2, strides, padding)

x_data = np.array([1],dtype=np.float32)
with tf.Session() as sess:
    init = tf.initialize_all_variables()
    sess.run(init)

    x = (sess.run(x, feed_dict={x_image: x_data}))
    W = (sess.run(W, feed_dict={x_image: x_data}))
    y = (sess.run(y, feed_dict={x_image: x_data}))

    print "The shape of x:\t", x.shape, ",\t and the x.reshape(1) is :"
    print x.reshape(1)
    print ""

    print "The shape of x:\t", W.shape, ",\t and the W.reshape(3,3) is :"
    print W.reshape(3,3)
    print ""

    print "The shape of y:\t", y.shape, ",\t and the y.reshape(5,5) is :"
    print y.reshape(5,5)
    print ""

and
  def testAtrousConv2DTransposeSingleStride(self):
    with self.test_session():
      strides = [1, 1, 1, 1]

      # Input, output: [batch, height, width, depth]
      x_shape = [2, 6, 4, 3]
      y_shape = [2, 6, 4, 2]

      # Filter: [kernel_height, kernel_width, output_depth, input_depth]
      f_shape = [3, 3, 2, 3]

      x = tf.constant(1.0, shape=x_shape, name="x", dtype=tf.float32)
      f = tf.constant(1.0, shape=f_shape, name="filter", dtype=tf.float32)

      output = tf.nn.atrous_conv2d_transpose(x, f, y_shape, 2, strides=strides,
                                      padding="SAME")

      value = output.eval()
      print(value)

Can one of the admins verify this patch?

Looks nice at a high level!  Let's add the tests in the same PR.

I'm working.

What's the current status here @guotong1988 ?
Need some help? What need's to be done to get this merged?

I got a little busy to change my job in the past three weeks. And I just finished it.
I am working now.

Nice! Ping me if you need help.

@sbrodehl In fact I'm not sure that my only test case can cover that much . Please provide more test case, if you have. Thank you .

I write another example ,  and I think my commit may be right.
import numpy as np
import tensorflow as tf

# Input, output: [batch, height, width, depth]
x_image = tf.placeholder(tf.float32,shape=[2,2])
x = tf.reshape(x_image,[1,2,2,1])

#Filter: W [kernel_height, kernel_width, output_depth, input_depth]
W_cpu = np.array([[1,-1,1],[1,1,1],[-1,1,-1]],dtype=np.float32)
W = tf.Variable(W_cpu)
W = tf.reshape(W, [3,3,1,1])

strides=[1, 1, 1, 1]
padding='VALID'

y = tf.nn.atrous_conv2d_transpose(x, W, [1,5,5,1], 2, strides, padding)

x_data = np.array([[1,1],[1,1]],dtype=np.float32)
with tf.Session() as sess:
    init = tf.initialize_all_variables()
    sess.run(init)

    x = (sess.run(x, feed_dict={x_image: x_data}))
    W = (sess.run(W, feed_dict={x_image: x_data}))
    y = (sess.run(y, feed_dict={x_image: x_data}))

    print "The shape of x:\t", x.shape, ",\t and the x.reshape(2,2) is :"
    print x.reshape([2,2])
    print ""

    print "The shape of x:\t", W.shape, ",\t and the W.reshape(3,3) is :"
    print W.reshape(3,3)
    print ""

    print "The shape of y:\t", y.shape, ",\t and the y.reshape(6,6) is :"
    print y.reshape(6,6)
    print ""

Now that I'm sure that my commit is right , because I write this example which is similar to the above one.
import numpy as np
import tensorflow as tf

# Input, output: [batch, height, width, depth]
x_image = tf.placeholder(tf.float32,shape=[2,3])
x = tf.reshape(x_image,[1,2,3,1])

#Filter: W [kernel_height, kernel_width, output_depth, input_depth]
W_cpu = np.array([[1,-1,1],[1,1,1],[-1,1,-1]],dtype=np.float32)
W = tf.Variable(W_cpu)
W = tf.reshape(W, [3,3,1,1])

strides=[1, 1, 1, 1]
padding='VALID'

y = tf.nn.atrous_conv2d_transpose(x, W, [1,5,5,1], 2, strides, padding)

x_data = np.array([[1,1,1],[1,1,1]],dtype=np.float32)
with tf.Session() as sess:
    init = tf.initialize_all_variables()
    sess.run(init)

    x = (sess.run(x, feed_dict={x_image: x_data}))
    W = (sess.run(W, feed_dict={x_image: x_data}))
    y = (sess.run(y, feed_dict={x_image: x_data}))

    print "The shape of x:\t", x.shape, ",\t and the x.reshape(2,2) is :"
    print x.reshape([2,3])
    print ""

    print "The shape of x:\t", W.shape, ",\t and the W.reshape(3,3) is :"
    print W.reshape(3,3)
    print ""

    print "The shape of y:\t", y.shape, ",\t and the y.reshape(6,6) is :"
    print y.reshape(6,7)
    print ""

Than I think I could start to finish the unit test.

I tried running your code on MNIST. The output shape looks wrong to me:
        print(inputs.get_shape(), W.get_shape())
        outputs = atrous_conv2d_transpose(inputs, W, [100, 28, 28, 1],
                                          2, [1,1,1,1], padding='SAME')
        print(outputs.get_shape())

gives:
(100, 28, 28, 8) (5, 5, 1, 8)
(100, 36, 36, 1)

I was expecting the output shape, i.e. the last line above, to read (100, 28, 28, 1).

@Fenugreek Yes , I fixed it.

@gpapan just sent me a full PR for implementing the transpose, btw.

@vrv I will finish the unit test.

@gpapan, since you wrote the internal one, I'll let you decide which one we should accept :)

@gpapan Could you provide your code? I want to learn from it.

I nearly finish. But the code need to review and edit, of course.

Thank you for your code. I learn a lot. Close this PR please.

Thanks @guotong1988 https://github.com/guotong1988!
@vrv: Can you please close #4668 and #5300?
On Mon, Dec 5, 2016 at 12:40 AM, 郭同jet · 耐心<EMAIL_ADDRESS>wrote:

Thank you for your code. I learn a lot. Close this PR please.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tensorflow/tensorflow/pull/5300#issuecomment-264795777,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF8Y_V16SQBnwOD5zAEWa-thMmHqWVh4ks5rE836gaJpZM4Kk04b
.

--
Best,
George


xWebAdministration and ApplicationHost.config

We have an IIS with 30+ apppools and 30+website/webapps hosting WCF services.
When I run a DSC config for this server it results in sporadic errors and afterwards a number of settings are missing in the ApplicationHost.config.
Run the DSC again (and again) and every time some more settings are applied until it applies them all.
I'm under the impression that IIS/DSC can't handle the number of applicationHost.config changes.
The host system is Windows 2012 R2 with latest patches.
is this a known issue?

Sorry that nobody answered your issue for so long. Are you still seeing this issue? If so, what OS editon and version, WMF and if you have a configuration to reproduce this it would be great!


All Subsequent Transfers are lost if an out-of-order multiframe transfer is received

It has been observed that if the packets for a multiframe transfer are received of order, then libudpard fails to receive any subsequent transfers for all Port IDs.

This issue was fixed by https://github.com/OpenCyphal-Garage/libudpard/pull/20


[4.4] update cs and add missing @return

Description
Now 4.4 branch is broken.

update cs and add missing @return

   1) user_guide_src/source/outgoing/response/003.php (blank_line_before_statement)
      ---------- begin diff ----------
--- /home/runner/work/CodeIgniter4/CodeIgniter4/user_guide_src/source/outgoing/response/003.php
+++ /home/runner/work/CodeIgniter4/CodeIgniter4/user_guide_src/source/outgoing/response/003.php
@@ -6,5 +6,6 @@
 ];

 return $this->response->setJSON($data);
+
 // or
 return $this->response->setXML($data);

      ----------- end diff -----------

 Error: Method CodeIgniter\Exceptions\FrameworkException::forCopyError() has no return type specified.
 ------ ----------------------------------------------------------------------
  Line   system/Exceptions/FrameworkException.php
 ------ ----------------------------------------------------------------------
  50     Method CodeIgniter\Exceptions\FrameworkException::forCopyError() has
         no return type specified.
 ------ ----------------------------------------------------------------------

Checklist:

[x] Securely signed commits
[] Component(s) with PHPDoc blocks, only if necessary or adds value
[] Unit testing, with >80% coverage
[] User guide updated
[x] Conforms to style guide

Now 4.4 branch is broken. Please review.


Feature Request: Implement Branch Management Functionality

Develop the core functionality that allows users to create, manage, and merge branches through a user-friendly interface.

ongoing


Create App Online Bundle id is not available

New Issue Checklist

[x] Updated fastlane to the latest version
[x] I read the Contribution Guidelines
[x] I read docs.fastlane.tools
[x] I searched for existing GitHub issues

Issue Description

Create App Online Bundle id is not available on specific teams, it works on other teams also i did try changing the app_identifier still its not creating, Is it possible that this is an account issue?

 Create App Online Bundle id is not available

🚫 fastlane environment 🚫
Stack

Key
Value

OS
11.4

Ruby
2.7.3

Bundler?
false

Git
git version 2.29.2

Installation Source
/usr/local/Cellar/fastlane/2.181.0/libexec/bin/fastlane

Host
macOS 11.4 (20F71)

Ruby Lib Dir
<EMAIL_ADDRESS>

OpenSSL Version
OpenSSL 1.1.1k  25 Mar 2021

Is contained
false

Is homebrew
true

Is installed via Fabric.app
false

Xcode Path
/Applications/Xcode.app/Contents/Developer/

Xcode Version
12.5

System Locale

Variable
Value

LANG
en_US.UTF-8
✅

LC_ALL
en_US.UTF-8
✅

LANGUAGE
en_US.UTF-8
✅

fastlane files:
`./fastlane/Fastfile`
# This file contains the fastlane.tools configuration
# You can find the documentation at https://docs.fastlane.tools
#
# For a list of all available actions, check out
#
#     https://docs.fastlane.tools/actions
#
# For a list of all available plugins, check out
#
#     https://docs.fastlane.tools/plugins/available-plugins
#

# Uncomment the line if you want fastlane to automatically update itself
# update_fastlane

# fastlane_require "dotenv"

before_all do

default_platform(:ios)

platform :ios do
    lane :prepare do
      create_app_online(
	    app_identifier: ENV['APP_IDENTIFIER'] ,
        app_name: ENV['APP_NAME'],
        enable_services: {
          push_notification: "on",
          app_group: "on"
        }
      )
      produce(
          app_identifier: ENV['NotificationServiceBundleID'] ,
          app_name: ENV['NotificationServiceAppName'],
          sku: ENV['SKU'],
          skip_itc: true,
          enable_services: {
            push_notification: "on",
            app_group: "on"
          }
      )

    end
end

`./fastlane/Appfile`
# app_identifier("[[APP_IDENTIFIER]]") # The bundle identifier of your app
# apple_id("[[APPLE_ID]]") # Your Apple email address

# For more information about the Appfile, see:
#     https://docs.fastlane.tools/advanced/#appfile

fastlane gems

Gem
Version
Update-Status

fastlane
2.181.0
🚫 Update available

Loaded fastlane plugins:

Plugin
Version
Update-Status

fastlane-plugin-appicon
0.16.0
✅ Up-To-Date

fastlane-plugin-versioning
0.4.4
🚫 Update available

fastlane-plugin-sentry
1.8.1
✅ Up-To-Date

Loaded gems

Gem
Version

did_you_mean
1.4.0

slack-notifier
2.3.2

atomos
0.1.3

CFPropertyList
3.0.3

claide
1.0.3

colored2
3.1.2

nanaimo
0.3.0

xcodeproj
1.19.0

rouge
2.0.7

xcpretty
0.3.0

terminal-notifier
2.0.0

unicode-display_width
1.7.0

terminal-table
1.8.0

plist
3.6.0

public_suffix
4.0.6

addressable
2.7.0

multipart-post
2.0.0

word_wrap
1.0.0

tty-screen
0.8.1

tty-cursor
0.7.1

tty-spinner
0.9.3

artifactory
3.0.15

babosa
1.0.4

colored
1.2

highline
1.7.10

commander-fastlane
4.4.6

excon
0.80.1

faraday-excon
1.1.0

faraday-net_http
1.0.1

faraday-net_http_persistent
1.1.0

ruby2_keywords
0.0.4

faraday
1.4.1

unf_ext
<IP_ADDRESS>

unf
0.1.4

domain_name
0.5.20190701

http-cookie
1.0.3

faraday-cookie_jar
0.0.7

faraday_middleware
1.0.0

fastimage
2.2.3

gh_inspector
1.1.3

json
2.3.0

mini_magick
4.11.0

naturally
2.2.1

rubyzip
2.3.0

security
0.1.3

xcpretty-travis-formatter
1.0.1

dotenv
2.7.6

bundler
2.2.15

simctl
1.6.8

jwt
2.2.3

uber
0.1.0

declarative
0.0.20

trailblazer-option
0.1.1

representable
3.1.1

retriable
3.1.2

mini_mime
1.1.0

multi_json
1.15.0

signet
0.15.0

memoist
0.16.2

os
1.1.1

googleauth
0.16.1

httpclient
2.8.3

google-api-client
0.38.0

google-cloud-env
1.5.0

google-cloud-errors
1.1.0

google-cloud-core
1.6.0

rexml
<IP_ADDRESS>

webrick
1.6.1

google-apis-core
0.3.0

google-apis-iamcredentials_v1
0.3.0

google-apis-storage_v1
0.3.0

rake
13.0.3

digest-crc
0.6.3

google-cloud-storage
1.31.0

emoji_regex
3.2.2

jmespath
1.4.0

aws-partitions
1.446.0

aws-eventstream
1.1.1

aws-sigv4
1.2.3

aws-sdk-core
3.114.0

aws-sdk-kms
1.43.0

aws-sdk-s3
1.93.1

uri
0.10.0

forwardable
1.3.1

logger
1.4.2

cgi
0.1.0

date
3.0.0

timeout
0.1.0

stringio
0.1.0

zlib
1.1.0

ipaddr
1.2.2

openssl
2.1.2

ostruct
0.2.0

strscan
1.0.3

delegate
0.1.0

fileutils
1.4.1

io-console
0.5.6

singleton
0.1.0

open3
0.1.0

yaml
0.1.0

psych
3.1.0

mutex_m
0.1.0

fastlane-plugin-appicon
0.16.0

benchmark
0.1.0

fastlane-plugin-versioning
0.4.4

fastlane-plugin-sentry
1.8.1

generated on: 2021-06-02

Hi,
If it's a problem with creating Bundle ids, you should go to Appstore Connect - Users and Access - select your account and scroll down to "developer resources" and check if you have "Access to Certificates, Identifiers & Profiles" selected.
If you have it selected in those teams, it will be hard to help without fastlane env output and a more detailed description of the issue.

Hi,
If it's a problem with creating Bundle ids, you should go to Appstore Connect - Users and Access - select your account and scroll down to "developer resources" and check if you have "Access to Certificates, Identifiers & Profiles" selected.
If you have it selected in those teams, it will be hard to help without fastlane env output and a more detailed description of the issue.

Hi @lucgrabowski , Thank you will provide fastlane env. This is weird because its working on other teams just specific account.

🚫 fastlane environment 🚫
Stack

Key
Value

OS
11.4

Ruby
2.7.3

Bundler?
false

Git
git version 2.29.2

Installation Source
/usr/local/Cellar/fastlane/2.181.0/libexec/bin/fastlane

Host
macOS 11.4 (20F71)

Ruby Lib Dir
<EMAIL_ADDRESS>

OpenSSL Version
OpenSSL 1.1.1k  25 Mar 2021

Is contained
false

Is homebrew
true

Is installed via Fabric.app
false

Xcode Path
/Applications/Xcode.app/Contents/Developer/

Xcode Version
12.5

System Locale

Variable
Value

LANG
en_US.UTF-8
✅

LC_ALL
en_US.UTF-8
✅

LANGUAGE
en_US.UTF-8
✅

fastlane files:
`./fastlane/Fastfile`
# This file contains the fastlane.tools configuration
# You can find the documentation at https://docs.fastlane.tools
#
# For a list of all available actions, check out
#
#     https://docs.fastlane.tools/actions
#
# For a list of all available plugins, check out
#
#     https://docs.fastlane.tools/plugins/available-plugins
#

# Uncomment the line if you want fastlane to automatically update itself
# update_fastlane

# fastlane_require "dotenv"

before_all do

default_platform(:ios)

platform :ios do
    lane :prepare do
      create_app_online(
        enable_services: {
          push_notification: "on",
          app_group: "on"
        }
      )

    end
end

`./fastlane/Appfile`
# app_identifier("[[APP_IDENTIFIER]]") # The bundle identifier of your app
# apple_id("[[APPLE_ID]]") # Your Apple email address

# For more information about the Appfile, see:
#     https://docs.fastlane.tools/advanced/#appfile

fastlane gems

Gem
Version
Update-Status

fastlane
2.181.0
🚫 Update available

Loaded fastlane plugins:

Plugin
Version
Update-Status

fastlane-plugin-appicon
0.16.0
✅ Up-To-Date

fastlane-plugin-versioning
0.4.4
🚫 Update available

fastlane-plugin-sentry
1.8.1
✅ Up-To-Date

Loaded gems

Gem
Version

did_you_mean
1.4.0

slack-notifier
2.3.2

atomos
0.1.3

CFPropertyList
3.0.3

claide
1.0.3

colored2
3.1.2

nanaimo
0.3.0

xcodeproj
1.19.0

rouge
2.0.7

xcpretty
0.3.0

terminal-notifier
2.0.0

unicode-display_width
1.7.0

terminal-table
1.8.0

plist
3.6.0

public_suffix
4.0.6

addressable
2.7.0

multipart-post
2.0.0

word_wrap
1.0.0

tty-screen
0.8.1

tty-cursor
0.7.1

tty-spinner
0.9.3

artifactory
3.0.15

babosa
1.0.4

colored
1.2

highline
1.7.10

commander-fastlane
4.4.6

excon
0.80.1

faraday-excon
1.1.0

faraday-net_http
1.0.1

faraday-net_http_persistent
1.1.0

ruby2_keywords
0.0.4

faraday
1.4.1

unf_ext
<IP_ADDRESS>

unf
0.1.4

domain_name
0.5.20190701

http-cookie
1.0.3

faraday-cookie_jar
0.0.7

faraday_middleware
1.0.0

fastimage
2.2.3

gh_inspector
1.1.3

json
2.3.0

mini_magick
4.11.0

naturally
2.2.1

rubyzip
2.3.0

security
0.1.3

xcpretty-travis-formatter
1.0.1

dotenv
2.7.6

bundler
2.2.15

simctl
1.6.8

jwt
2.2.3

uber
0.1.0

declarative
0.0.20

trailblazer-option
0.1.1

representable
3.1.1

retriable
3.1.2

mini_mime
1.1.0

multi_json
1.15.0

signet
0.15.0

memoist
0.16.2

os
1.1.1

googleauth
0.16.1

httpclient
2.8.3

google-api-client
0.38.0

google-cloud-env
1.5.0

google-cloud-errors
1.1.0

google-cloud-core
1.6.0

rexml
<IP_ADDRESS>

webrick
1.6.1

google-apis-core
0.3.0

google-apis-iamcredentials_v1
0.3.0

google-apis-storage_v1
0.3.0

rake
13.0.3

digest-crc
0.6.3

google-cloud-storage
1.31.0

emoji_regex
3.2.2

jmespath
1.4.0

aws-partitions
1.446.0

aws-eventstream
1.1.1

aws-sigv4
1.2.3

aws-sdk-core
3.114.0

aws-sdk-kms
1.43.0

aws-sdk-s3
1.93.1

uri
0.10.0

forwardable
1.3.1

logger
1.4.2

cgi
0.1.0

date
3.0.0

timeout
0.1.0

stringio
0.1.0

zlib
1.1.0

ipaddr
1.2.2

openssl
2.1.2

ostruct
0.2.0

strscan
1.0.3

delegate
0.1.0

fileutils
1.4.1

io-console
0.5.6

singleton
0.1.0

open3
0.1.0

yaml
0.1.0

psych
3.1.0

mutex_m
0.1.0

fastlane-plugin-appicon
0.16.0

benchmark
0.1.0

fastlane-plugin-versioning
0.4.4

fastlane-plugin-sentry
1.8.1

generated on: 2021-06-02

Could you login to Appstore Connect to the team that it's failing and go to A Users and Access - select your tester account and scroll down to "developer resources" and check if you have "Access to Certificates, Identifiers & Profiles" selected?
If access to developer resources is there and it's not working, it would be good if you describe what fastlane's commands do you try to execute and show some logs.

@lucgrabowski , this is the output on bitrise and bitrise locally, it works on other teams that i've deployed, but this one is specific this account is nearing its expiration and it might be the cause

@lucgrabowski , yes i have access on everything, my role was admin

We are also facing the same issue

I don't use Bitrise and I don't have any ideas without taking a look at configuration and logs. It would be best if you could paste verbose logs.

Do you try to create an app with bundle identifier that is used on another developer account? If you created an identifier in Team1, you won't be able to create it in Team2.

Hello,
thanks for sharing your concern.
Please update your bundle ID in XCode to match the bundle ID of the push certificate you uploaded, or upload a new .p12 push certificate file that matches your XCode bundle ID.

@lucgrabowski , i've tested multiple bundle ids and even random ones just to simulate that, and its really happening on just one dev account, i've managed multiple teams and this is just isolated case on 1 account, i'm assuming that its account related and its near expiring, can that be a possible root cause?

Do you try to create an app with bundle identifier that is used on another developer account? If you created an identifier in Team1, you won't be able to create it in Team2.

@lucgrabowski , i've tested multiple bundle ids and even random ones just to simulate that, and its really happening on just one dev account, i've managed multiple teams and this is just isolated case on 1 account, i'm assuming that its account related and its near expiring, can that be a possible root cause?

Hello,
thanks for sharing your concern.
Please update your bundle ID in XCode to match the bundle ID of the push certificate you uploaded, or upload a new .p12 push certificate file that matches your XCode bundle ID.

@Anthonyby526 , i've already setup automation for that, it's not the issue. Thank you :)

Hello,
thanks for sharing your concern.
Please update your bundle ID in XCode to match the bundle ID of the push certificate you uploaded, or upload a new .p12 push certificate file that matches your XCode bundle ID.

@Anthonyby526 , i've already setup automation for that, it's not the issue. Because its working on other teams that i manage. Thank you :)

ok thank you for update.

How do you login/authenticate? Via Apple ID or App Store Connect API key?

@max-ott , I'm using bitrise for that, also the build is successful on multiple other teams that I've deployed. this is isolated on just 1 team that I managed.

This issue has been resolved, So once the apple membership is expiring it would always fail to upload then once you renew your membership the team id also changes. Thank you everyone!


Docker images with arm64 support

I am still working on the image for the dev container but the testing process is slow so I will make a separate PR once that is ready.

The build error may be related to this issue: https://github.com/golang/go/issues/51253

Also need to look more closely at these issues which were brought to my attention by Aron:
https://github.com/actions/checkout/issues/760
https://github.com/actions/checkout/issues/766

I'm not too familiar with VS code or developing in containers but I had to update how the dev container was installing Go modules to be the same as the other Dockerfile to get the image to build. I installed VS code and was able to connect to the container afterwards.
Happy to discuss the overall approach more as well.

I'm not sure if this will help here, but I saw it come up in a ticket from @shepherdjerred for RSPM.  https://www.docker.com/blog/faster-multi-platform-builds-dockerfile-cross-compilation-guide/

I'm not sure if this will help here, but I saw it come up in a ticket from @shepherdjerred for RSPM. https://www.docker.com/blog/faster-multi-platform-builds-dockerfile-cross-compilation-guide/

Thanks for the mention Brian! The solution here looks similar to what I'm doing for RSPM.

I was able to remove the logic for downloading the Go tarball by using the TARGETARCH env var which simplified the Dockerfile quite a bit but I couldn't think of a better way to set the correct checksum. Other suggestions welcome.

@mcbex should we merge this?

Ugh my apologies I never saw these comments. Going to go over it again and make those changes!

@jonyoder Let me know if you see any other changes I should make before we merge