Ensure all styling props are documented

Components that accept props to modify their styling generally document those props, with the exception of props provided by library functions, such as spacing.withWhiteSpace or spacing.withWidth.
The spacing lib includes withWhiteSpace.propTypes which provides a definition of the props that the withWhiteSpace styling function provides.  (Currently there is no equivalent for withWidth.)
Unfortunately spreading those definitions in the propTypes for a component does not result in those props appearing in the documentation.  As the definitions for the props provided by withWhiteSpace is complicated, it's not practical to copy the complete definitions into each component.
We should investigate ways of ensuring that all props get documented in a practical manner.
This issue replaces #321

Potential avenues of investigation include:

Augmenting the existing doc generation tools
Defining props with Flow
Defining props with TypeScript

Does @storybook/addon-info support showing spread propTypes?
Related: #621


fix: more leniency with URL format in mountpoint

Fix #7
Support any of the following URL formats:
https://adobe.sharepoint.com/:f:/r/sites/MySite/Shared%20Documents/website
https://adobe.sharepoint.com/sites/MySite/Shared%20Documents/website

:tada: This PR is included in version 3.35.3 :tada:
The release is available on:

GitHub release
v3.35.3

Your semantic-release bot :package::rocket:


Set ANDROID_NDK_HOME for mac

The macOS build also pass now, https://buildkite.com/bazel/rules-android-ndk/builds/13#01833bb7-97d4-43fe-9a68-1ec690d0156b

You probably want to fix the buildifier error so that the pipeline is green

buildifier fix https://github.com/bazelbuild/rules_android_ndk/pull/18
so i'd say we should just merge this one, thanks for doing it!

You probably want to fix the buildifier error so that the pipeline is green, then we can enable it in downstream pipeline so you also get test coverage from Bazel@HEAD

hmm I had run buildifier yesterday:
https://github.com/bazelbuild/rules_android_ndk/commit/5c8acc87b851179380ed5713acfd4a10430d42f5
buildifier on buildkite doesn't say what's wrong within the files so not sure why it's still giving errors


Error

Hi! When I download the newest version of your program (the one you uploaded 14 hours ago), I get an error that says "Error: read ECONNRESET", and nothing will load after that. I can't get in ;__;

@ankiramania The error didn't occurr when I debugged it. I recommend you remove old version completely, then install the newest version and try it again.

Thank you. It turns out it was a problem with my internet... I apologize for wasting your time.


[VH] Rule filtering by date ignores time zone information if milliseconds are absent

Describe the bug
A ValidFrom date 2021-07-22T16:34:33+02:00 is parsed as 16:34:33 UTC. Supposedly only happens if the date string does not have milliseconds.
Expected behaviour
A ValidFrom date 2021-07-22T16:34:33+02:00 should parsed as 14:34:33 UTC
Steps to reproduce the issue
Parse date 2021-07-22T16:34:33+02:00 and check output
Technical details
n/a
Possible Fix
somewhere here https://github.com/eu-digital-green-certificates/dgc-certlogic-ios/blob/257fa209c053ca4bc05629ece867f2f30bc45a3f/Sources/CertLogic/Date+.swift
Additional context
n/a

Generally, it might make sense to use the built-in ISO8106 parser as the first one instead of the last one:
https://github.com/eu-digital-green-certificates/dgc-certlogic-ios/blob/8b7f86a2aed4f2c60dd2c7c4f28eb129d9fe379d/Sources/CertLogic/Rule.swift#L58-L79

Just changing the order would not solve this issue as the Date. Date.iso8601Formatter does not have the .withTimeZone format option set and currently just ignores the time zone.

@nickguendling fixed in #40


[icu] build failure

OS: Windows 10.0.18363
Compiler: MSVC v142 build tools
Vcpkg version: 2020.02.04-nohash

What I type and get in PowerShell:
PS D:\vcpkg> vcpkg install icu --clean-after-build
Computing installation plan...
The following packages will be built and installed:
    icu[core]:x64-windows
Starting package 1/1: icu:x64-windows
Building package icu[core]:x64-windows...
-- Using cached D:/vcpkg/downloads/icu4c-65_1-src.tgz
-- Extracting source D:/vcpkg/downloads/icu4c-65_1-src.tgz
-- Applying patch D:/vcpkg/ports/icu/disable-escapestr-tool.patch
-- Applying patch D:/vcpkg/ports/icu/remove-MD-from-configure.patch
-- Applying patch D:/vcpkg/ports/icu/fix_parallel_build_on_windows.patch
-- Applying patch D:/vcpkg/ports/icu/fix-extra.patch
-- Using source at D:/vcpkg/buildtrees/icu/src/c-65_1-src-702c9cff96
-- Acquiring MSYS Packages...
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:72 (message):
    Command failed: D:/vcpkg/downloads/tools/msys2/msys64/usr/bin/bash.exe --noprofile --norc -c "pacman -Sy --noconfirm --needed make automake1.15"
    Working Directory: D:/vcpkg/downloads/tools/msys2
    Error code: 1
    See logs for more information:
      D:\vcpkg\buildtrees\icu\msys-pacman-x64-windows-out.log
      D:\vcpkg\buildtrees\icu\msys-pacman-x64-windows-err.log

Call Stack (most recent call first):
  scripts/cmake/vcpkg_acquire_msys.cmake:108 (vcpkg_execute_required_process)
  ports/icu/portfile.cmake:77 (vcpkg_acquire_msys)
  scripts/ports.cmake:90 (include)

Error: Building package icu:x64-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with `.\vcpkg update`, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
  Package: icu:x64-windows
  Vcpkg version: 2020.02.04-nohash

Additionally, attach any relevant sections from the log files above.

msys-pacman-x64-windows-out.log
:: Synchronizing package databases...

msys-pacman-x64-windows-err.log
error: failed to update mingw32 (unable to lock database)
error: failed to update mingw64 (unable to lock database)
error: failed to update msys (unable to lock database)
error: failed to synchronize all databases

What am I doing wrong?

I've deleted the folder vcpkg\downloads\tools\msys2 that has solved the problem.


[AzureFirewall]  az network firewall policy: Support Explicit Proxy feature

closed: https://github.com/Azure/azure-cli/issues/27581
This checklist is used to make sure that common guidelines for a pull request are followed.
Related command

General Guidelines

[ ] Have you run azdev style <YOUR_EXT> locally? (pip install azdev required)
[ ] Have you run python scripts/ci/test_index.py -q locally? (pip install wheel==0.30.0 required)
[ ] My extension version conforms to the Extension version schema

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your pull request is merged into main branch, a new pull request will be created to update src/index.json automatically.
You only need to update the version information in file setup.py and historical information in file HISTORY.rst in your PR but do not modify src/index.json.

AzureFirewall

please update the changelog and setup.py as well


How to add a toolbar command

I would like to implement an additional toolbar command to insert some text to the editing area.
When the toolbar command is fired, I would like to invoke JS code to connect to the server to get some text data.  Then, the text will be inserted in the editing area.
It seems that I need to configure the editor.   However, I'm not able to figure it out now.   My problems are:

How to add a toolbar command
How to invoke a JS function when the toolbar command is invoked
How to insert text to the editing area in the JS function

Any help will be highly appreciated!

I figured it out at last fortunately.  The following is the code:
        new EasyMDE({
            toolbar: [{
                name: "bold",
                action: EasyMDE.toggleBold,
                className: "fa fa-bolt",
                title: "Bold",
            }, '|', { // Separator
                name: "alert",
                action: (editor) => {
                    // contact the server and obtain the dynamic text data; store it in the var new_content
                    // ...
                    editor.value(new_content);
                },
                className: "fa fa-star",
                title: "A Custom Button",
            },
            element: document.getElementById('demo1'),
            initialValue: 'Hello!'
        });


Validation Loss: nan, Validation Regression Loss nan, Validation Classification Loss: nan

I trained model and ıt worked fine in Collecting your own Detection Datasets with follow this road. But I wanted to improve my model therefore I added photos .I followed same way with repo. But I tried again to train my model but the train returned nan.
Why it didnt calculate value ?
python3 train_ssd.py --dataset-type=voc --data=data/products --model-dir=models/products5
2020-11-25 08:10:24 - Epoch: 8, Step: 40/44, Avg Loss: nan, Avg Regression Loss nan, Avg Classification Loss: nan

@dusty-nv

Hi @dusty-nv , i have litteraly the same issue. All my losses during training are nan. I have a multi-label dataset, with each image containing several objects. All images appear to be correctly annotated (pascalVOC).
initial command : python3 train_ssd.py --data=data/mildiou_detection --model-dir=models/mildiou --batch-size=32 --epochs=30 --dataset-type=voc --validation-mean-ap="True"
command for debug : python3 train_ssd.py --data=data/mildiou_detection --model-dir=models/mildiou --batch-size=1 --epochs=30 --dataset-type=voc --validation-mean-ap="True" --debug-steps=1 --workers=0 --log-level="debug"
I've already trained models on other datasets without any problems. Do you have any idea what's causing this problem ?

@nodk15 try removing/fixing the image annotations from the image/xml directly proceeding the first nan

@dusty-nv i try removing with no success, still the same issue... but the images are correctly annotated. Maybe because of the image size (5184x3888) ?
here is the xml file of the first image :
<annotation>     <folder>JPEGImages</folder>     <filename>Pinot noir - Corin 2021-08-16-18.11.16.jpg</filename>     <path>../JPEGImages/Pinot noir - Corin 2021-08-16-18.11.16.jpg</path>     <source>         <database>Unknown</database>     </source>     <size>         <width>5184</width>         <height>3888</height>         <depth>3</depth>     </size>     <segmented>0</segmented>     <object>         <name>downy mildew oil spot square</name>         <truncated>0</truncated>         <difficult>0</difficult>         <bndbox>             <xmin>1597</xmin>             <ymin>1429</ymin>             <xmax>2267</xmax>             <ymax>2019</ymax>         </bndbox>     </object>     <object>         <name>downy mildew oil spot square</name>         <truncated>0</truncated>         <difficult>0</difficult>         <bndbox>             <xmin>1757</xmin>             <ymin>2029</ymin>             <xmax>2207</xmax>             <ymax>2599</ymax>         </bndbox>     </object>     <object>         <name>downy mildew oil spot square</name>         <truncated>0</truncated>         <difficult>0</difficult>         <bndbox>             <xmin>2307</xmin>             <ymin>1649</ymin>             <xmax>3007</xmax>             <ymax>2409</ymax>         </bndbox>     </object>     <object>         <name>downy mildew oil spot square</name>         <truncated>0</truncated>         <difficult>0</difficult>         <bndbox>             <xmin>2297</xmin>             <ymin>2389</ymin>             <xmax>2947</xmax>             <ymax>2769</ymax>         </bndbox>     </object>     <object>         <name>downy mildew oil spot square</name>         <truncated>0</truncated>         <difficult>0</difficult>         <bndbox>             <xmin>3237</xmin>             <ymin>2189</ymin>             <xmax>3497</xmax>             <ymax>2519</ymax>         </bndbox>     </object>     <object>         <name>downy mildew oil spot square</name>         <truncated>0</truncated>         <difficult>0</difficult>         <bndbox>             <xmin>2437</xmin>             <ymin>849</ymin>             <xmax>3187</xmax>             <ymax>1579</ymax>         </bndbox>     </object>     <object>         <name>downy mildew oil spot square</name>         <truncated>0</truncated>         <difficult>0</difficult>         <bndbox>             <xmin>3387</xmin>             <ymin>1659</ymin>             <xmax>3867</xmax>             <ymax>2349</ymax>         </bndbox>     </object> </annotation>

@nodk15 did you remove it's image ID from your dataset's ImageLists ?   (i.e. is it no longer being loaded)
If so, it might be another image that is causing the NaN's.   In that case, you need to keep filtering/removing them until the NaN's are gone or you find out what about them is causing the NaN's.

@dusty-nv Is there a limit to the number of objects per image ? I noticed only images with more 4 objects generate nan losses.

Finally, I solved my problem. The problem was effectely in the annotations. Many of my annotations had an xmax lower than the xmin...
Thanks you @dusty-nv for help :)


Upgrade for 1-10

I think this actually handles both 1.9 and 1.10. We'll know when CI passes.

@dfdx looks like it works.

Additionally, do we need to be testing on nightly, or shall we just test on 1.9 and 1 (which will correspond to 1.10 in the relatively near future I assume)?

Julia 1.6 is still the official LTS version, and it's what we have in Project.toml. So the default plan was to support it until the next LTS version. Do you find issues that cannot be handled (easily) on Julia < 1.9?
Regarding nightlies, I think it constantly fails for over a year now and we don't really adapt the package for pre-release versions. So yes, I think we can drop it and test only on the released versions.

Julia 1.6 is still the official LTS version, and it's what we have in Project.toml. So the default plan was to support it until the next LTS version. Do you find issues that cannot be handled (easily) on Julia < 1.9?

Ah, okay. I got the impression from https://github.com/dfdx/Umlaut.jl/pull/43 that you were happy to drop support for 1.6 if we tag a new minor version. The reason being that we don't need CompilerPluginTools from 1.9 onwards, and CompilerPluginTools does not even precompile on 1.10, meaning that Umlaut cannot precompile on 1.10.

Regarding nightlies, I think it constantly fails for over a year now and we don't really adapt the package for pre-release versions. So yes, I think we can drop it and test only on the released versions.

Sounds good.

Codecov Report
Attention: 8 lines in your changes are missing coverage. Please review.

Comparison is base (0263cdf) 1.26% compared to head (3c9c00a) 1.26%.

Files
Patch %
Lines

src/trace.jl
0.00%
8 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff            @@
##            main     #53      +/-   ##
========================================
- Coverage   1.26%   1.26%   -0.01%
========================================
  Files          8       8
  Lines        713     714       +1
========================================
  Hits           9       9
- Misses       704     705       +1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

All true, I forgot we discussed version 1.10 specifically, now the puzzle has come together.
The general principle I follow is to support old versions as long as they don't block the progress. For Julia 1.10-beta2 the situation was unclear because pre-release versions often change - why to make life harder for the dependent packages if it may be fixed soon! With the current version 1.10-rc1 it's unlikely that CompilerPluginTools will start working, so dropping the old versions of Julia sounds justified.
I will merge the PR, update compat and tag a new version.


Current sensors should be float

As already commented in the HA Forum, this integration treats Current values as integers, not as floats.
I see 2 problems here:

In this range >6 A and < 32 A, the first decimals do make a difference.
So I believe it should be extract_item_from_array_to_float,

Anyway, usage of int seems to be problematic to me when parsing json, as it just cuts the decimal part instead of rounding.
So something like this would make more sense, wouldn't it?

def extract_item_from_array_to_int(value, key) -> int:
    """Extract item from array to int."""
    return round(float(json.loads(value)[int(key)]))

Though I have never ever developed in Python before. So maybe this is complete nonsene.

Thanks for your detailed bug report! Could you add the nrg payload example here too? I will prepare a fix!

I would be happy about a plain text copy of the response. :-) This is the response of my charger:
/go-eCharger/072246/nrg [232,232,233,1,0,0,0,0,0,0,0,0,0,0,0,0]

It looks like the resolution has changed / is different per model?

The plaintext copy of your response:
/go-eCharger/203597/nrg [232.5,231.26,234.67,2.48,5.966,6.004,5.996,1347.132,1358.567,1360.781,0,4066.48,97.11894,97.84528,95.1958,100]

[
    233.43,
    231.26,
    234.67,
    2.48,
    5.928,
    6.004,
    5.966,
    1346.888,
    1354.837,
    1359.388,
    0,
    4061.113,
    97.33447,
    97.57664,
    97.0963,
    100
]

Firmware 054.7
Hardwareversion V4
Firmware-Version des Ladecontrollers 0.0.1-36

In my case it's firmware 054.6, hardware version 3, module revision 1 and charger controller version 12.

I've published a new release (0.14.3). Please give it a try! It hopefully solves your issue.

Works!

Thank you!


Summarization categorization

Gists now return an english paragraph that is human-friendly.
Sample located at Gist.

We should think about how to test this. test/src/summarize_test.dart should be expanded to test the individual description types, and to test one or two full snippets and validate their summaries. In other words, test the individual parts and have one or two higher level tests that test against full summaries.

We may want to remove the _languageFeatures method and the under development text now.

@Georgehe4 let me know if you'd like me to take a look at this at some point

Some smaller comments. Let's add one or two more tests for coverage when we have AnalysisResults. You can create them something like this:
AnalysisIssue issue = new AnalysisIssue();
issue.kind = 'error';
issue.message = 'foo';
issue.sourceName = 'main.dart';
AnalysisResults results = new AnalysisResults();
results.issues.add(issue);
results.packageImports = [];
results.resolvedImports = [];

Looking at the sample:

Summary: This amazing assemblage of characters contains a few errors and warnings, and contains use of async features.

It would be nice to put in a state machine that prevents repetition of things like 'contains', but only if it doesn't massively complicate the code.

This code has some associated html and some associated css, and it imports this will break the code from external packages.

I don't understand the last clause, it seems ungramatical?

It imports dart:async from the dart package as well. Also, mentions pirates, birds, and llamas.

Nice.
Overall this seems to be going in a nice direction

@lukechurch
The ungrammatical sentence is caused by the import actually named 'this will break the code'. I will add quotes to address the concern.

@devoncarew @lukechurch

lgtm!

Changes Unknown when pulling a4eedcb36a2cd883be8c131d99529781ed8e90c6 on SummarizationCategorization into ** on master**.

Merging


Use devicePixelRatio to calculate canvas width and height

I noticed that the canvas created in the JS version of reason-glfw is not taking the pixel ratio into account. If the width is 800, both canvas.style.width and canvas.width are 800.
I was able to have the canvas rendering perfectly in a retina device by changing the value of width and height to double the pixels (so, width to 1600 and height to 1200 for a 800x600 window).
This is essentially what this PR does: calculate the canvas width and height based on the device pixel ratio. This also makes the canvas real size the same as the framebuffer size, so the values can be  returned from caml_glfwGetFramebufferSize without any extra modifications.
More info in https://support.unity3d.com/hc/en-us/articles/214948483-WebGL-looks-wrong-on-High-resolutions-Retina-.
Before this PR:

After:

This also makes the canvas real size the same as the framebuffer size, so the values can be returned from caml_glfwGetFramebufferSize without any extra modifications.

Excellent! Thanks for figuring this out & fixing it. Indeed, we'd want caml_glfwGetFramebufferSize to return the true pixel dimensions.
It looks like our previous logic was half-baked and didn't all the cases.
            if (w.onSetFramebufferSize) {
                w.onSetFramebufferSize(w, canvas.offsetWidth * pixelRatio, canvas.offsetHeight * pixelRatio);
            }

Nice find @jchavarri !


duplicate style?

hi
i see this image in orbit storybook

when i change a small value of this component like color, all style of this component will duplicate and create new style hash with huge similar value and bit different value like color
its ok?

Hey @straxico yes, IMO that's ok, styled-components doesn't create a granular CSS declaration, so this is expected.


Fixed wrong target spec in 9p-fs template

When using a id attribute to specify a synced folder the mount inside the guest fails, since the user-defined id will be used as mount_tag by vagrant-libvirt. Unfortunately this mount_tag has never been announced to libvirt/qemu as target via filesystem.xml.erb.
Inside filesystem.xml.erb the target was always the guestpath which is completely ok when no id was specified by the user and vagrant takes care of it.

can you show vagrantfile for checking your changes?

Sure. We are using a hombrew debian-wheezy box, but any debian 7 should do.
The failing mount issued by cachier is
mount -t 9p [mountopts] 'vagrant-cache' /tmp/vagrant-cache

Vagrant.configure(2) do |config|
  config.vm.box = "debian-wheezy"
  config.vm.synced_folder './', '/vagrant', type: '9p', disabled: false
  config.vm.provider :libvirt do |lv|
	lv.driver = 'kvm'
	lv.disk_bus = 'scsi'
	lv.memory = 512
	lv.cpus = 2
	lv.nested = true
	lv.keymap = 'de'
  end

  if Vagrant.has_plugin?("vagrant-cachier")
    config.cache.scope = :machine
	config.cache.synced_folder_opts = {
	  type: '9p'
	}
  end
end

thanks. today or tomorrow i will chek it and accept . schoenes wochenende

dankeschön! :-)


Add Page displaying all registered Prologue routes + user specified configs and maybe other things that the prologue object exposes

This has been achived


The words are still french when is the event coming up?

The words are still french when is the event coming up?

A few more days.


Automated cherry pick of #1074: cachedimage-filter-by-region-or-zone

Cherry pick of #1074 on release/2.10.0.
#1074: cachedimage-filter-by-region-or-zone

/lgtm
/approve

Codecov Report

:exclamation: No coverage uploaded for pull request base (release/2.10.0@4c3d83e). Click here to learn what that means.
The diff coverage is n/a.

@@               Coverage Diff                @@
##             release/2.10.0   #1075   +/-   ##
================================================
  Coverage                  ?   7.89%
================================================
  Files                     ?     356
  Lines                     ?   56477
  Branches                  ?       0
================================================
  Hits                      ?    4461
  Misses                    ?   51620
  Partials                  ?     396

Flag
Coverage Δ

#aFlag
7.89% <ø> (?)

Impacted Files
Coverage Δ

pkg/compute/models/cachedimages.go
2.25% <ø> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4c3d83e...bf36c14. Read the comment docs.


ReferenceError: route is not defined

I have an issue with Ziggy, I was using it first with the directive @routes but after switching to the artisan method the route helper function fails to import,
###Steps to reproduce
in webpack.mix:
ziggy: path.resolve(
      __dirname,
      'vendor/tightenco/ziggy/dist/js/route.js'),
ziggyRoutes: path.resolve(
       __dirname,
      'resources/assets/js/ziggy.js'),

in app.js:
import route from 'ziggy';
import { Ziggy } from 'ziggyRoutes'

Vue.mixin({
    methods: {
        route: (name, params, absolute) => window._route(name, params, absolute, Ziggy),
    }
});

Current Behavior

[Vue warn]: Error in data(): "ReferenceError: route is not defined"

For bug reports only please provide
Currently installed Laravel version:
5.7
Currently installed Ziggy version
v<IP_ADDRESS>

Are you using Vue with your project? If so, can I see what the whole app.js file looks like?
If not, you only need to add those first two lines to your app.js file:
import route from 'ziggy';
import { Ziggy } from 'ziggyRoutes'

I have the exact same problem. I carefully followed the Artisan section of the readme, after composer require tightenco/ziggy.
In webpack.mix.js, I added:
// [...]
const path = require('path');

mix.webpackConfig({
    resolve: {
        alias: {
            ziggy: path.resolve('vendor/tightenco/ziggy/dist/js/route.js'),
        },
    },
});
// [...]

In app.js:
// [...]
require('./bootstrap');

import route from 'ziggy';
import { Ziggy } from './ziggy';

window.Vue = require('vue');

Vue.mixin({
    methods: {
        route: (name, params, absolute) => route(name, params, absolute, Ziggy),
    }
});
// [...]

Then I generated the ziggy.js file:
php artisan ziggy:generate "resources/js/ziggy.js"
So the ziggy.js file is in the same directory as app.js (you should probably update default location to match new Laravel's structure BTW)
Then:
npm run dev
Compiles without any problem.
Everything works if I add @routes to my blade view, but if I don't, I get "ReferenceError: Can't find variable: route".

Same problem here!
In webpack.mix.js, I added:
const path = require('path')
mix.webpackConfig({
    resolve: {
        alias: {
                ziggy: path.resolve('vendor/tightenco/ziggy/dist/js/route.js'),
        },
    },
});

In app.js (not using Vue):
import route from 'ziggy';
import { Ziggy } from '../assets/js/ziggy'

In app.js it creates:
// [...]
var Ziggy = {
  namedRoutes: {
    "debugbar.openhandler": {
      "uri": "_debugbar\/open",
      "methods": ["GET", "HEAD"],
      "domain": null
    },
    "debugbar.clockwork": {
      "uri": "_debugbar\/clockwork\/{id}",
      "methods": ["GET", "HEAD"],
      "domain": null
    },
    "debugbar.telescope": {
      "uri": "_debugbar\/telescope\/{id}",
      "methods": ["GET", "HEAD"],
      "domain": null
    },
    "debugbar.assets.css": {
      "uri": "_debugbar\/assets\/stylesheets",
      "methods": ["GET", "HEAD"],
      "domain": null
    },
// [...]

Everything works if I @routes is added in the blade view, but if it isn't, I get "ReferenceError: Can't find variable: route".

Here's what my setup looks like, it works without the @routes blade directive:
In app.js:
[...]
import route from 'ziggy';
import { Ziggy } from './ziggy';

window.route = route;
window.Ziggy = Ziggy;
Vue.mixin({
  methods: {
    route: (name, params, absolute) => route(name, params, absolute, Ziggy),
  }
});

in webpack.mix.js:
mix.webpackConfig({
  resolve: {
    alias: {
      ...
      ziggy: path.resolve('vendor/tightenco/ziggy/dist/js/route.js'),
    },
  },
});

Compiles without errors, and everything works as expected. Hope this helps.

I confirm @mazedlx setup. Two points changed between my setup and his.
These two lines are required:
window.route = route;
window.Ziggy = Ziggy;

And in webpack.mix.js, I used the minified route.js, whereas @mazedlx referred to the non-minified route.js.
It works as expected now. thank you very much !

As pointed out above, this is just a question of bundlers not propagating route and Ziggy into the global scope.
If you're using the route() helper in your app Javascript files, you need to import route from 'ziggy' and import { Ziggy } from './ziggy' wherever you want to use them.
If you will later need to call route() somewhere else, like from other scripts loaded later on the page and not bundled, add route and Ziggy to the global scope as demonstrated above with window.route = route; and window.Ziggy = Ziggy;. Using the @routes Blade directive accomplished this too.
If you're using Vue, as the original issue describes, you don't need route and Ziggy on the window and you can do what they were describing:
// webpack.mix.js

// ...

mix.webpackConfig({
    resolve: {
        alias: {
            ziggy: path.resolve('vendor/tightenco/ziggy/src/js/route.js'),
            ziggyRoutes: path.resolve('resources/js/ziggy.js'),
        },
    },
});

// app.js:

import route from 'ziggy';
import { Ziggy } from 'ziggyRoutes';

// ...

Vue.mixin({
    methods: {
        route: (name, params, absolute) => route(name, params, absolute, Ziggy),
    },
});


⚠ Bofrost.de has degraded performance

In 0d25583, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 936 ms

Resolved: Bofrost.de performance has improved in 9758297.


chore: use nvm in publish script

Also prevents user agent script from leaving repo in a dirty state after generation.

Done as part of implementing changesets.


Allow python sklearn interface's fit() to pass init_model to train()

Allow python sklearn interface's fit() to pass init_model to train()

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

@aaiyer Please rebase to the latest master in order to pass CI checks.

@aaiyer Something went wrong during the branch rebasing:

Please fix it.

My bad. Fixed

@aaiyer Please, make it possible to pass sklearn model as init_model.
I guess, it can be something like
https://github.com/microsoft/LightGBM/blob/dee72159d36a66d72372ec7fa783d1682eef1411/python-package/lightgbm/plotting.py#L88-L89

Done

Also, please update the docstring accordingly.

Gently ping @aaiyer

Gently ping @aaiyer

My bad, will get to this very shortly.


How do I dealloc WiFiEventHandler after BootWiFi is completed?

I have a wrapper class working properly to obtain WiFi credentials and store in NVS.  Once that is finished, I use C to extract credentials from NVS and try to connect to a C based WiFi project.  When I do this, the WiFiEventHandler::getEventHandler() still seems to be called during WiFi events.   I have tried to resolve the issue by deleting the m_pWifiEventHandler pointer in the WiFi class but it still gets called.
I would like to use my own event handler in C that I have already written and previously used.
esp_event_loop_init(&app_event_handler, NULL);
Is there a preferred method for removing the reference to the old wifi class instance?

@zachjacobs Im not sure, but try to use "empty" event handler WiFi class and your own event handler from C.

@zachjacobs Thank you sir ... good catch.  We have now removed the old event handler after a successful boot so it is now "out of the event processing state".
However, I don't think you'll have luck with esp_event_loop_init().  What this does is start a task to process events.  This task can only be created / initialized once and has already been created / initialized when we started boot processing.  However ... given that you want to process your own events AFTER the WiFi environment has already started, you can plugin in your own event handler by calling esp_event_loop_set_cb().   The purpose of that function (which is provided by ESP-IDF) is to change the callback that is invoked and I think that is what you are after.

I tested f323d99245a68904106f8f9b3abaa29dfbb634ec and it works great in my application!  Thanks for the heads up on esp_event_loop_set_cb().  I didn't run across that before and it makes my life much easier.
Thanks for the quick response!


KYLIN-3847 Flink cubing step : fact distinct

Refer jira: https://issues.apache.org/jira/browse/KYLIN-3847
Add flink fact distinct columns step, to avoid a mass of duplicated code with Spark and Flink implement self fact distinct step, add base class FactDistinctColumnsBase, extract core methods and variables from mapper/reducer class.
About different engine will implement the abstract method FactDistinctColumnsBase.Visitor.collect(...) to output the result from Spark/Flink engine framework.
Please help to review this code changes

Codecov Report

Merging #1154 into master will decrease coverage by 0.14%.
The diff coverage is 0%.

@@             Coverage Diff              @@
##             master    #1154      +/-   ##
============================================
- Coverage     25.05%   24.91%   -0.15%
+ Complexity     6248     6245       -3
============================================
  Files          1446     1449       +3
  Lines         88305    88803     +498
  Branches      12357    12413      +56
============================================
- Hits          22128    22124       -4
- Misses        64007    64506     +499
- Partials       2170     2173       +3

Impacted Files
Coverage Δ
Complexity Δ

...kylin/engine/mr/steps/FactDistinctColumnsBase.java
0% <0%> (ø)
0 <0> (?)

...ylin/engine/flink/FlinkBatchCubingJobBuilder2.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

.../java/org/apache/kylin/common/KylinConfigBase.java
12.24% <0%> (-0.02%)
44 <0> (ø)

.../java/org/apache/kylin/common/util/StringUtil.java
40.81% <0%> (-0.43%)
22 <0> (ø)

...kylin/engine/flink/HadoopMultipleOutputFormat.java
0% <0%> (ø)
0 <0> (?)

...e/kylin/engine/flink/FlinkFactDistinctColumns.java
0% <0%> (ø)
0 <0> (?)

...he/kylin/dict/lookup/cache/RocksDBLookupTable.java
72.97% <0%> (-5.41%)
6% <0%> (-1%)

...a/org/apache/kylin/dict/Number2BytesConverter.java
81.74% <0%> (-0.8%)
17% <0%> (-1%)

...ain/java/org/apache/kylin/dict/TrieDictionary.java
72.55% <0%> (-0.47%)
56% <0%> (-1%)

... and 2 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ebc4c26...bc5a7b8. Read the comment docs.

Pull Request Test Coverage Report for Build 5731

0 of 504 (0.0%)  changed or added relevant lines in 6 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.2%) to 27.364%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

core-common/src/main/java/org/apache/kylin/common/util/StringUtil.java
0
1
0.0%

core-common/src/main/java/org/apache/kylin/common/KylinConfigBase.java
0
6
0.0%

engine-flink/src/main/java/org/apache/kylin/engine/flink/FlinkBatchCubingJobBuilder2.java
0
22
0.0%

engine-flink/src/main/java/org/apache/kylin/engine/flink/HadoopMultipleOutputFormat.java
0
33
0.0%

engine-flink/src/main/java/org/apache/kylin/engine/flink/FlinkFactDistinctColumns.java
0
157
0.0%

engine-mr/src/main/java/org/apache/kylin/engine/mr/steps/FactDistinctColumnsBase.java
0
285
0.0%

Files with Coverage Reduction
New Missed Lines
%

core-dictionary/src/main/java/org/apache/kylin/dict/lookup/cache/RocksDBLookupTable.java
1
81.08%

Totals

Change from base Build 5720:
-0.2%

Covered Lines:
24300

Relevant Lines:
88803

💛  - Coveralls


Add data table column for vulnerabilities that indicates if it was in suppressions.xml

Would we still want to parse suppressions.xml files based on https://jeremylong.github.io/DependencyCheck/dependency-suppression.1.3.xsd given that it's fairly common, even if we nowadays use the GitHub Advisory database over the NIST source we shared with that tool (which is included in GHADB)?


Update CODE_OF_CONDUCT.md

Added comma after 'gender identity' -- oxford comma for the win!

The added comma is not grammatically correct.

Yeah you’re right lol. Just realized.
Sent from my iPhone
On Apr 15, 2021, at 10:29 AM, Prokop Schield @.***> wrote:

The added comma is not grammatically correct.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/benawad/dogehouse/pull/2042#issuecomment-820605091, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AQOS7NF4X3OHDUBDNBBJG7DTI4PALANCNFSM4275NCEA.

wrong grammar?


feat: Update input 'required' indicator

feat: Update input required indicator
feat: Update input 'required' indicator

The type of this PR is: Feature

This PR resolves CX-2243
Description
Updates input 'required' indicator from * to Required and adds Optional indicator (needed for the address form).

Address Form
Artwork Form

Input
Select Form

PR Checklist (tick all before merging)

[x] I have included screenshots or videos to illustrate my changes, or I have not changed anything that impacts the UI.
[x] I have tested my changes on iOS and Android.
[x] I have added tests/stories for my changes, or my changes don't require testing/stories, or I have included a link to a separate Jira ticket covering the tests.
[x] I have added a feature flag, or my changes don't require a feature flag. (How do I add one?)
[x] I have documented any follow-up work that this PR will require, or it does not require any.
[x] I have added an app state migration, or my changes do not require one. (What are migrations?)
[x] I have added a changelog entry below or my changes do not require one.

To the reviewers 👀

[ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Changelog updates
Changelog updates

Cross-platform user-facing changes

iOS user-facing changes

Android user-facing changes

Dev changes

Warnings

:warning:

❌ An error occurred while validating your changelog, please make sure you provided a valid changelog.

  Generated by :no_entry_sign: dangerJS against<PHONE_NUMBER>128f7383b814db9d705cfec5a73a81

Are these changes required only for the Address form?

Are these changes required only for the Address form?

Since these changes are applied to a Palette element they will be global. The specific thing about the address form is that we decided to just indicate the only optional field (as you can see in the screenshot).


Define arch-specific set of memory attributes

For #61009 it was requested in https://github.com/zephyrproject-rtos/zephyr/pull/61009#pullrequestreview-1557351778 to have a comprehensive list of memory attribute that could make sense for the different architectures and define also a common set that is valid for all.
This issue will be used to gather this data from the various architecture maintainers (and other fellow devs).
So, dear all in the following list: could you list any memory-attribute that you think it could be useful for your architecture and specify if you can think of any generic attribute that could make sense besides the one already listed down here?
https://github.com/zephyrproject-rtos/zephyr/blob/5664796d1f5b525dc27bb6dfc862c35e7c5b7b13/include/zephyr/dt-bindings/memory-attr/memory-attr.h#L11-L21

[ ] ARM (@microbuilder @SgrrZhf @ithinuel)

[ ] ARC (@ruuddw @evgeniy-paltsev)

[ ] ARM64 (@carlocaione @povergoing)

[x] POSIX (@aescolar)

[ ] NIOS-2 (@nashif)

[x] RISC-V (@fkokosinski @kgugala @tgorochowik)

[ ] Xtensa (@dcpleung)

[ ] X86 (@jhedberg)

[ ] others (@hubertmis @galak @teburd)

I think @SgrrZhf and @ithinuel can also be involved in terms of ARM

@carlocaione I might miss something, but what if someone wants to define an arch-specific mem attr (e.g. inner/outer sharable attr for Arm64), we still have a chance to customize and define the arch-specific mem attr right?

@carlocaione I might miss something, but what if someone wants to define an arch-specific mem attr (e.g. inner/outer sharable attr for Arm64), we still have a chance to customize and define the arch-specific mem attr right?

Yes, basically part of the mask of zephyr,memory-attr is reserved for architectures (8-bits):
https://github.com/zephyrproject-rtos/zephyr/blob/5664796d1f5b525dc27bb6dfc862c35e7c5b7b13/include/zephyr/dt-bindings/memory-attr/memory-attr.h#L23-L32
So every architecture must have its own /include/zephyr/dt-bindings/memory-attr/memory-attr-ARCH.h file with the set of defines it cares about. For example for ARM64:
#include <zephyr/dt-bindings/memory-attr/memory-attr.h>
#include <zephyr/dt-bindings/memory-attr/memory-attr-arm64.h>

   mem: memory@10000000 {
       compatible = "mmio-sram";
       reg = <0x10000000 0x1000>;
       zephyr,memory-attr = <( DT_MEM_CACHEABLE | DT_MEM_ARM64_INNER_SHAREABLE )>;
   };

For RISC-V, we would additionally need to have attributes to decide the following:

the memory region type: is it main, I/O or empty/illegal?
the support atomic ops (AMO class): swap, logical or arithmetic?
for I/O memory type - is it idempotent or not?

So the list would be something like as follows:
DT_MEM_RISCV_TYPE_MAIN
DT_MEM_RISCV_TYPE_IO
DT_MEM_RISCV_TYPE_EMPTY
DT_MEM_RISCV_AMO_SWAP
DT_MEM_RISCV_AMO_LOGICAL
DT_MEM_RISCV_AMO_ARITHMETIC
DT_MEM_RISCV_IO_IDEMPOTENT_READ
DT_MEM_RISCV_IO_IDEMPOTENT_WRITE

For Xtensa, there are instruction ROM/RAM, data ROM/RAM and XLMI memory. So we will need these to indicate where the memory regions reside:
DT_MEM_XTENSA_INSTR_ROM
DT_MEM_XTENSA_INSTR_RAM
DT_MEM_XTENSA_DATA_ROM
DT_MEM_XTENSA_DATA_RAM
DT_MEM_XTENSA_XLMI

Also will need DT_MEM_XTENSA_IDMA for each region to indicate whether the integrated DMA engine can do DMA transfer on them.

Also will need DT_MEM_XTENSA_IDMA for each region to indicate whether the integrated DMA engine can do DMA transfer on them.

Uhm, this could be very well a generic attribute TBH, like DT_MEM_DMA  or something similar.

Generally some form of indicator of connectivity/placement would be useful I'd think.
TCM, SOC, BOARD kind of indicators of some sort.
E.g. intel adsp has a bit of each in a way. NXP's RT series absolutely has all 3 if external sdram/hyperram is used.
These different regions may have varying behavioral differences you want to check pointers for.

@teburd which architectures are we talking about here?

Generally some form of indicator of connectivity/placement would be useful I'd think.
TCM, SOC, BOARD kind of indicators of some sort.
E.g. intel adsp has a bit of each in a way. NXP's RT series absolutely has all 3 if external sdram/hyperram is used.
These different regions may have varying behavioral differences you want to check pointers for.

At least arm (nxp imxrt) and xtensa (intel adsp) that I know of that could use this sort of memory locality indicator

Generally some form of indicator of connectivity/placement would be useful I'd think.
TCM, SOC, BOARD kind of indicators of some sort.
E.g. intel adsp has a bit of each in a way. NXP's RT series absolutely has all 3 if external sdram/hyperram is used.
These different regions may have varying behavioral differences you want to check pointers for.

@teburd which architectures are we talking about here?

intel adsp is xtensa lx6/lx7, nxp imxrt is arm cm7

About the generic attributes: first of all I'm wondering why do we have two options for some attributes (CACHEABLE vs NON_CACHEABLE; VOLATILE vs NON_VOLATILE) and only one option for other (DT_MEM_OOO in case of out of order)?
 #define DT_MEM_CACHEABLE		BIT(0) /* cacheable */
 #define DT_MEM_NON_CACHEABLE		BIT(1) /* non-cacheable */
 #define DT_MEM_VOLATILE		BIT(2) /* volatile */
 #define DT_MEM_NON_VOLATILE		BIT(2) /* von-volatile */
 #define DT_MEM_OOO			BIT(3) /* out-of-order */

Yes, that is something I'm going to fix in the next push. All the _NON_ variants are going to be removed.

For ARC there are various memories, e.g. closely coupled instruction and data (ICCM, DCCM) and XY memory for improved DSP performance. And more, like cluster shared memory for multicore clusters.
To be honest, I'm not fully sure about these extra attributes, or rather about how they will be used. It looks like main purpose is to avoid programming MPU in C code board initialization, but move that to DTS. That may work for some specific and static cases, but not sure if it provides enough flexibility to avoid some dedicate logic in C code board initialization.
If the main purpose is programming of MPU attributes, shouldn't the attributes simply be aligned with the MPU programming attributes (user/kernel/supervisor read/write/execute etc.)?

@carlocaione In the POSIX arch we are not modelling any kind of MPU, and type of access limitations do not really apply. So this attributed would be ignored.

For ARC there are various memories, e.g. closely coupled instruction and data (ICCM, DCCM) and XY memory for improved DSP performance. And more, like cluster shared memory for multicore clusters. To be honest, I'm not fully sure about these extra attributes, or rather about how they will be used. It looks like main purpose is to avoid programming MPU in C code board initialization, but move that to DTS. That may work for some specific and static cases, but not sure if it provides enough flexibility to avoid some dedicate logic in C code board initialization. If the main purpose is programming of MPU attributes, shouldn't the attributes simply be aligned with the MPU programming attributes (user/kernel/supervisor read/write/execute etc.)?

@ruuddw  No, this is not related to MPU. MPU is only one way to use this attribute but the memory attributes can be used as one pleases. Please, refer to the PR description in #61009.
The zephyr,memory-attr property is a generic way to define the memory capabilities, and MPU is only one use-case for that but you can have many more.

@carlocaione I might miss something, but what if someone wants to define an arch-specific mem attr (e.g. inner/outer sharable attr for Arm64), we still have a chance to customize and define the arch-specific mem attr right?

Yes, basically part of the mask of zephyr,memory-attr is reserved for architectures (8-bits):
https://github.com/zephyrproject-rtos/zephyr/blob/5664796d1f5b525dc27bb6dfc862c35e7c5b7b13/include/zephyr/dt-bindings/memory-attr/memory-attr.h#L23-L32
So every architecture must have its own /include/zephyr/dt-bindings/memory-attr/memory-attr-ARCH.h file with the set of defines it cares about. For example for ARM64:
#include <zephyr/dt-bindings/memory-attr/memory-attr.h>
#include <zephyr/dt-bindings/memory-attr/memory-attr-arm64.h>

   mem: memory@10000000 {
       compatible = "mmio-sram";
       reg = <0x10000000 0x1000>;
       zephyr,memory-attr = <( DT_MEM_CACHEABLE | DT_MEM_ARM64_INNER_SHAREABLE )>;
   };

You have the same concept of shareable in ArmV{7|8}-M, which can be one of:

Shareable: Shareable between multiple cores or bus masters
Non-Shareable: The memory region is not shareable between multiple cores or bus masters.
Outer Shareable: The memory region is shareable among processors in the same system but outside the processor cluster.
Inner Shareable: The memory region is shareable within a processor cluster.

If it exists in both Aarch64 and Aarch32, is it 'arch' specific at that point, or should it be represented generically? Any other arches have a comparable concept?
There is also a concept of Bufferable with Device memory (memory mapped peripherals, etc.) or Normal memory -- when set, write operation might not immediately affect the memory, allowing for more efficient burst writes if there is a wait state with the memory system.

You have the same concept of shareable in ArmV{7|8}-M for Normal memory, which can be one of:

At this point I really think we should limit the attributes to the ones we actually use. Do these have any real use-case in the Zephyr context?

There is also a concept of Bufferable with Device memory (memory mapped peripherals, etc.) or Normal memory -- when set, write operation might not immediately affect the memory, allowing for more efficient burst writes if there is a wait state with the memory system.

The zephyr,memory-attr property is supposed to be companion only to the mmio-sram compatible than is Normal memory. The Device (MMIO) memory is the one associated to devices and it is outside the scope of this PR. We are only dealing with Normal memory at this stage.


Add flag to not transpile dynamic import() when module is CommonJS

Suggestion
🔍 Search Terms
List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily and help provide feedback.
dynamic import, commonjs, esm, node
✅ Viability Checklist
My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion
Add a tsconfig flag to not transpile dynamic imports when module is CommonJS. Something like transpileDynamicImport which would be true by default and only take effect when "module": "CommonJS".
📃 Motivating Example
Since Node 12, it is possible to use dynamic imports. Yet I'm not able to tell the TS compiler to not transpile this into Promise.resolve().then(() => __importStar(require('..')));. This prevents users from importing ES modules into CommonJS, which will become increasingly common now that Node is transitioning to ES modules.
💻 Use Cases
The main use case is to be able to import ES modules into CommonJS, which is possible to do with import(). The workaround today involves an additional build step which does replacements to hide the import() statement from TS so it does not get transpiled and re-add it later on, which is suboptimal.

Just ran into this myself and noticed that this breaks ESM interop in node. Per node's documentation it is possible to load esm files from commonjs via import(). Therefore the dynamic import statement must not be transpiled to require calls. This is currently broken when using TypeScript.

@weswigham any additional context you might provide here?

I can as I've been asked about this in a few contexts. Today we assume that all requires and imports have the same end result post-transpilation, as either commonjs or esmodules.
However, it's a bit more nuanced because node supports the same keywords working differently depending on if you're in an ESM context or CommonJS context. So in a commonjs context, you normally can't use import/export, but you can use await import to import an esm module:
// index.cjs
let module = await import('/modules/my-module.js');

What TypeScript thinks today is that this import should be switched to a require
const a = Promise.resolve().then(() => __importStar(require("/modules/my-module.js")));

Which is what you want for existing cases because that was a normal feature of require statements. It's a signal that the thing you're about to grab is a ESM module.
What's tricky is that TypeScript has no way to disambiguate whether you want await import in a cjs context to continue being a = require( or now stay as a = await import(
This seems to be hitting a few big projects because people want to have config files in ESM but let the app stay in cjs.

Greets... Thanks @dummdidumm for filing this issue. I was about to post the same thing about a week ago.
@orta not transpiling dynamic import is an important aspect to enable for Node v12+ in regard to loading ESM for CommonJS targeted TS efforts. It will be used for a lot more than loading configuration files. I am an outside contributor attempting to get Heroku / Salesforce to add ESM loading capabilities to their Oclif v2 CLI framework that is due for launch in the coming months. I have already worked out the essential changes with a proof of concept that is discussed in the issue linked above, but it required a workaround. Oclif is a TS project which targets CommonJS for release. One can build CLIs in CommonJS or TS; my proposed changes adds ESM to the mix which is quite relevant as the Node ecosystem moves to ESM.
The least worst workaround I could come up with is the following:
const _importDynamic = new Function('modulePath', 'return import(modulePath)') which is used internally to an encapsulated addition for loading ESM via dynamic import or require for non-ESM code - module-loader.ts.
As an outside contributor I certainly could not touch the build process, so the above seems to do the trick until a flag can be added to Typescript which is certainly desirable.

What's tricky is that TypeScript has no way to disambiguate whether you want await import in a cjs context to continue being a = require( or now stay as a = await import(. We'd either need a flag like the above which handles it app wide, or a pragma at the import call-site.

If node style module resolution is enabled, and you encounter a bare module specifier in a dynamic import, would it make sense to check the imported package's package.json for "type": "module" and preserve the dynamic import if it is present?

If node style module resolution is enabled, and you encounter a bare module specifier in a dynamic import, would it make sense to check the imported package's package.json for "type": "module" and preserve the dynamic import if it is present?

If you also checked the extension of the file being imported for ".mjs", then yes I think that would be appropriate.
This has become a big problem for using some packages in a CommonJS app that are MJS only.
https://github.com/sindresorhus/meta/discussions/15

The beauty of await import() is that it can import both ESM and CJS:
// index.cjs

const one = await import('./new.mjs');
const two = await import('./old.cjs');
const three = await import('./unknown.js');

This is highly desirable to maintain interop as the ecosystem slowly moves towards ESM because I can import a file without knowing the module system. The current all-or-nothing approach is too painful.

We'd either need a flag like the above which handles it app wide, or a pragma at the import call-site.

I would be okay with either solution, but the pragma would give the most flexibility if it can be configured per call site.

This is going to be coming in natively and without a flag/pragma I expect, when more of the node ESM support starts rolling after https://github.com/microsoft/TypeScript/pull/44501

For future reference: A workaround for this issue can be had by moving the import() to a non-compiled dependency, such as inclusion.
Biggest drawback of this, apart from it being confusingly non-standard, is that types won't get imported. That can be worked around by manually importing the types.
Complete example:
import inclusion from 'inclusion';

export async function foo(): Promise<void> {
  const pMap: typeof import('p-map')['default'] = (await inclusion('p-map')).default;
}

as I workaround I use
eval('import("node-fetch")') as Promise<typeof import("node-fetch")>

Fixed by the addition of module: node12 with #45884

Fixed by the addition of module: node12 with #45884

@weswigham While debugging someone's question on Stack Overflow, I observed that setting TSConfig compilerOptions.module to "node12" doesn't resolve the issue of preventing transformation of dynamic import() into require(), but that using eval does.

Version info:
$ node --version
v16.13.1

$ npm --version
8.3.0

$ npm ls typescript
<EMAIL_ADDRESS>/so-70545129
└──<EMAIL_ADDRESS>

package.json
{
  "name": "so-70545129",
  "version": "1.0.0",
  "description": "",
  "type": "commonjs",
  "main": "dist/index.js",
  "scripts": {
    "compile": "tsc",
    "test": "npm run compile && node dist/index.js"
  },
  "author": "",
  "license": "MIT",
  "devDependencies": {
    "@types/node": "^17.0.5",
    "typescript": "^4.6.0-dev.20211231"
  },
  "dependencies": {
    "unified": "^10.1.1"
  }
}

tsconfig.json
{
  "compilerOptions": {
    "exactOptionalPropertyTypes": true,
    "isolatedModules": true,
    "lib": [
      "ESNext"
    ],
    "module": "node12",
    "moduleResolution": "Node",
    "noUncheckedIndexedAccess": true,
    "outDir": "dist",
    "strict": true,
    "target": "ESNext",
  },
  "include": [
    "./src/**/*"
  ]
}

Fixed by the addition of module: node12 with #45884

@weswigham While debugging someone's question on Stack Overflow, I observed that setting TSConfig compilerOptions.module to "node12" doesn't resolve the issue of preventing transformation of dynamic import() into require(), but that using eval does.

Version info:
$ node --version
v16.13.1

$ npm --version
8.3.0

$ npm ls typescript
<EMAIL_ADDRESS>/so-70545129
└──<EMAIL_ADDRESS>

package.json
{
  "name": "so-70545129",
  "version": "1.0.0",
  "description": "",
  "type": "commonjs",
  "main": "dist/index.js",
  "scripts": {
    "compile": "tsc",
    "test": "npm run compile && node dist/index.js"
  },
  "author": "",
  "license": "MIT",
  "devDependencies": {
    "@types/node": "^17.0.5",
    "typescript": "^4.6.0-dev.20211231"
  },
  "dependencies": {
    "unified": "^10.1.1"
  }
}

tsconfig.json
{
  "compilerOptions": {
    "exactOptionalPropertyTypes": true,
    "isolatedModules": true,
    "lib": [
      "ESNext"
    ],
    "module": "node12",
    "moduleResolution": "Node",
    "noUncheckedIndexedAccess": true,
    "outDir": "dist",
    "strict": true,
    "target": "ESNext",
  },
  "include": [
    "./src/**/*"
  ]
}

This is great. But this one's even better:
(await Function('return import("node-fetch")')()) as typeof import("node-fetch")

We also cannot confirm that using node12 as module setting solves the problem. We're still getting dynamic imports transformed to require, as @jsejcksn mentions

We also cannot confirm that using node12 as module setting solves the problem. We're still getting dynamic imports transformed to require, as @jsejcksn mentions

This functionality has never made it into released TypeScript. It was reverted
https://github.com/microsoft/TypeScript/issues/46452

This functionality has never made it into released TypeScript. It was reverted
#46452

should this issue be reopened then?

Since the function was reverted, the documentation needs t be adopted. Here is written that the moduleResolution node12 and nodenext are supported from typescript 4.5 onwards:
https://www.typescriptlang.org/tsconfig#moduleResolution

It wasn't reverted, per sey, it just issues an error in stable builds to let people know the feature is still a bit unstable.

I was hoping to fix a storybook build issue by using "nodenext". Unfortunately "import" is still being transpiled.

Also, we close issues once they're fixed in nightly)

How come a fix from nightly from September last year is still not available in stable? And in general shouldn't an issue be marked as fixed when it is reported as fixed? Developers should not assume an issue is closed just because code is merged.

Is this fixed already with nodenext?

Correct - cjs format files in node12 or nodenext retain dynamic imports as-is, even while other imports are transformed.

Workaround: https://github.com/brillout/load-module.
If someone can re-open this for folks that subscribe to the close status of this ticket, that would be great.

Correct - cjs format files in node12 or nodenext retain dynamic imports as-is, even while other imports are transformed.

I get this:
error TS4124: Compiler option 'moduleResolution' of value 'nodenext' is unstable.
Use nightly TypeScript to silence this error. Try updating with 'npm install -D typescript@next'.

I'm just seeing it does work with<EMAIL_ADDRESS>though.

Correct - cjs format files in node12 or nodenext retain dynamic imports as-is, even while other imports are transformed.

Is this still nightly-only, even in 4.7? With module set to node16, dynamic import is still getting transformed. For example
  await import("got")

becomes
  await Promise.resolve().then(() => __importStar(require("got")));

Here's a playground link

I can also confirm that I'm still having this issue on version 4.7.4 with the following compiler options:
    "outDir": "./lib",
    "rootDir": ".",
    "module": "esnext",
    "target": "ES2021",
    "types": ["node"],
    "importHelpers": false
  }```

Many of the packages that have started being distributed as ESM only (even those intended to be used in node) use the rationale "You can use import() to load ESM packages into commonjs files."  However, this is not possible in typescript (stable) when targeting commonjs as far as I can tell.  Am I missing something, or is that the case?  So, for example, all of the latest packages from sindresorhus are off-limits to typescript developers compiling to cjs until this issue is resolved and nodenext is released out of nightly, right?

Yes and he has been aware of this. There are a number of very long horrible threads now spanning years asking people like him to stop doing this until the community can catch up. But they ignored us.

Many of the packages that have started being distributed as ESM only (even those intended to be used in node) use the rationale "You can use import() to load ESM packages into commonjs files." However, this is not possible in typescript (stable) when targeting commonjs as far as I can tell. Am I missing something, or is that the case? So, for example, all of the latest packages from sindresorhus are off-limits to typescript developers compiling to cjs until this issue is resolved and nodenext is released out of nightly, right?

It is possible, hacky, but at least possible.

same issue closed with not correctly resolved:

https://github.com/microsoft/TypeScript/issues/50109
https://github.com/microsoft/TypeScript/issues/48103

I spent a good afternoon reading up on everything and I did not find a good example of how to do this so here is my solution.
Wrap your ESM package into a .cjs commonjs script that will not be transpiled and import like this.
import { fileTypeFromBuffer } from './file-type.cjs';

file-type.cjs

/**
 * @type {typeof import('file-type').fileTypeFromBuffer}
 */
module.exports.fileTypeFromBuffer = async (buffer) => {
  const { fileTypeFromBuffer } = await import('file-type');
  return await fileTypeFromBuffer(buffer);
};

tsconfig.json
"module": "CommonJS",
"moduleResolution": "node",
"target": "ES2021",
"lib": ["ES2021"],

package.json
  "type": "commonjs",
   "dependencies": {
     "typescript": "4.8.2"
   },

.nvmrc
16.17.0

I worked around this with the magic of eval!
...and a js file.
getPhonemeLibs.js

/* eslint-disable no-eval */

// these libs are ESM only and typescript doesn't yet have great support for that when you
// want to compile to commonjs. the only way I've found to get typescript to not compile a dynamic
// import is to use eval.
export async function getPhonemeLibs() {
  let { soundex } = await eval("import('soundex-code')")
  let { doubleMetaphone } = await eval("import('double-metaphone')")
  return { soundex, doubleMetaphone }
}

and!
getPhonemeLibs.d.ts
import type { doubleMetaphone } from 'doubleMetaphone'
import type { soundex } from 'soundex-code'

export declare async function getPhonemeLibs(): Promise<{ soundex: soundex; doubleMetaphone: doubleMetaphone }>

Hey, the issue is still there.
Any updates on it?

@abenhamdine use node16 instead.

@xiaoxiangmoe Unfortunately, that doesn't solve the originally-reported issue of using import() of an ESM module into CommonJS.
Given that:

Node supports dynamic import() of ESM into CJS;
^ is the main way to adopt ESM-only modules in existing CJS projects;
CommonJS is going to be around for years as the ecosystem slowly migrates to ESM; and
That same ESM migration is made much harder without dynamic import() of ESM into CommonJS projects

It seems like it would be an enormous help to have a flag to allow typescript targeting CommonJS to preserve dynamic import(). Whether on a project-wide basis ("never transpile my dynamic imports") or a call-site pragma ("don't transpile THIS dynamic import"), this really would be an extremely helpful feature.
+1 for reopening this issue.

@abenhamdine use "moduleResolution": "node16" instead.

We are stuck on nodejs 14 due to an incompatibility of an old module.
Is modeResolution node16 possible with nodejs 14 ? Sounds like not but I will give a try.

@abenhamdine改用。

Note that using "moduleResolution": "Node16" may not be appropriate if you are using a bundler, and could cause you some pain in that case.  See discussion in https://github.com/microsoft/TypeScript/issues/50152 for a proposal of a more flexible moduleResolution for bundlers.

We are in 2023 and I am still having this issue.
{
  "compilerOptions": {
    "target": "es2021",
    "moduleResolution": "node",
    "module": "node16",
    "esModuleInterop": true,
    "resolveJsonModule": true,
    "strict": true,
    "lib": ["es2017"],
    "rootDir": "./src",
    "baseUrl": ".",
    "outDir": "./dist",
    "skipLibCheck": true,
    "strictNullChecks": true,
    "noImplicitAny": false
  },
  "exclude": ["node_modules", "**/test/**"]
}

With the config above
const { default: imageType } = await import('image-type')
still gets transpiled into:
const { default: imageType } = await Promise.resolve().then(() => __importStar(require('image-type')));

Please sort this out finally!

@codan84 change your moduleResolution to node16. Having it out-of-sync with your module option makes us not pick up some metadata that influences the transform we choose.

Why was this closed? It still doesn't work :-/.

We are in 2023 and I am still having this issue.
{
  "compilerOptions": {
    "target": "es2021",
    "moduleResolution": "node",
    "module": "node16",
    "esModuleInterop": true,
    "resolveJsonModule": true,
    "strict": true,
    "lib": ["es2017"],
    "rootDir": "./src",
    "baseUrl": ".",
    "outDir": "./dist",
    "skipLibCheck": true,
    "strictNullChecks": true,
    "noImplicitAny": false
  },
  "exclude": ["node_modules", "**/test/**"]
}

With the config above const { default: imageType } = await import('image-type')
still gets transpiled into: const { default: imageType } = await Promise.resolve().then(() => __importStar(require('image-type')));
Please sort this out finally!

you can solve it like this
const { default: imageType } = await eval("import('image-type')")

We are in 2023 and I am still having this issue.
{
  "compilerOptions": {
    "target": "es2021",
    "moduleResolution": "node",
    "module": "node16",
    "esModuleInterop": true,
    "resolveJsonModule": true,
    "strict": true,
    "lib": ["es2017"],
    "rootDir": "./src",
    "baseUrl": ".",
    "outDir": "./dist",
    "skipLibCheck": true,
    "strictNullChecks": true,
    "noImplicitAny": false
  },
  "exclude": ["node_modules", "**/test/**"]
}

With the config above const { default: imageType } = await import('image-type')
still gets transpiled into: const { default: imageType } = await Promise.resolve().then(() => __importStar(require('image-type')));
Please sort this out finally!

you can solve it like this
const { default: imageType } = await eval("import('image-type')")

I was struggling with this issue for weeks, esm modules kept breaking jest. For me, using await eval was the solution to this issue. Thanks a lot!

Hello everyone, has anyone else encountered a problem while using this workaround with Jest?

This is brilliant. But I like this:
Function('return import("node-fetch")')() as Promise<typeof import('node-fetch')>

Apparently it's much(?) faster, not sure but maybe even safer.

Unfortunately, on our use case none of the proposed workarounds work, because they are incompatible with a strict Content Security Policy. We cannot add unsafe-eval to the CSP policies due to client requirements, so doing await eval or new Function('') is not possible for us.
If you are asking why would I transpile to CJS even though I'm using the module in the browser: a) I'm already using webpack so I don't care about module formats, and b) Jest doesn't support ESM and I don't want my users to be messing up with Jest and babel transforms just to run some tests.
Is there any workaround that doesn't require to eval code, or is there a flag planned to solve this issue? Thanks

It is work for me after set tsconfig.json compilerOptions to node16
 "compilerOptions": {
   "moduleResolution": "node16",
 }

It is work for me after set tsconfig.json compilerOptions to node16
 "compilerOptions": {
   "moduleResolution": "node16",
 }

That doesn't work with module CommonJS:
Option 'module' must be set to 'Node16' when option 'moduleResolution' is set to 'Node16'.

I also had to enable "skipLibCheck": true:
		"lib": ["ES2022"],
		"target": "ES2022",
		"module": "Node16",
		"moduleResolution": "Node16",
		// currently necessary due to ESM only imports
		"skipLibCheck": true,

This is brilliant. But I like this:
Function('return import("node-fetch")')() as Promise<typeof import('node-fetch')>

Apparently it's much(?) faster, not sure but maybe even safer.

Hello everyone, has anyone else encountered a problem while using this workaround with Jest?

I did but not exactly your case. I faced an error using the eval() workaround.
At the end, I decided to add --experimental-vm-modules option to NODE_OPTIONS before calling Jest. For reference, I am using Jest 29.5 at the moment with node 20.13.
My script line in package.json looks like:
...
    "jest": "NODE_OPTIONS=\"$NODE_OPTIONS --experimental-vm-modules\" jest ..."
...

I'm dying of this problem.
I tried using tsconfig.json to exclude file but it didn't work
In the end, I chose to just make a simple npm package await-import-dont-compile to prevent compilation
This is how he uses it
import awaitImport from "await-import-dont-compile";
import { pathToFileURL } from "url";

export const dynamicImport = async (filepath: string) => {
  return await awaitImport(pathToFileURL(filepath).href);
};

Hope it helps!!!

If someone else is facing this issue but doesn't want to install an additional package, this is an ugly but possible workaround:
      const { Provider } = await new Function(return import('oidc-provider'))()
Found this solution here:
https://github.com/panva/node-oidc-provider/discussions/1249

2024 and it is still an issue. sigh...


Add ddev release-stats tool for agent's release

What does this PR do?
It adds a command called release-stats in the ddev tool to output statistics about the agent's release process in a CSV format.
Motivation
Need to introspect our release process and now when it got better and when it got worse.
Additional Notes
Tested it with this command: python -m datadog_checks.dev release-stats csv-report [OPTIONS] in the datadog_checks_dev folder.
Review checklist (to be filled by reviewers)

[ ] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
[ ] PR title must be written as a CHANGELOG entry (see why)
[ ] Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
[ ] PR must have changelog/ and integration/ labels attached

I'm getting rate-limited testing it:
$ ddev release-stats csv-report -f 7.18.0-rc.1 -t 7.18.0 -r 7.18.0
[...]
requests.exceptions.HTTPError: 403 Client Error: rate limit exceeded for url: https://api.github.com/search/issues?q=sha:fdc630656a010c141c8f8fa2631f825f9a3fac1a+repo:DataDog/datadog-agent

I have a GITHUB_TOKEN in my env vars.

rebase

@kbogtob @ofek Is this good to merge?

CI failing


Fix time fetch on initialization

There was a big security hole where the server was not fetching the correct date. This PR fixes that. The issue involved the unsafePerformIO call, I don't know why I just know that when I removed it things worked 😊 (see more at #344, this discussion specifically @begriffs).
Closes #391.
And I promise, no bugs 😊 (#355).

Looks like Nikita released a new version of hasql and something is failing.
Try restricting hasql version to the last one we know it was working
https://hackage.haskell.org/package/hasql-0.7.4

That pesky getPOSIXTime had a problem after all... What value did it return from inside unsafePerformIO?
I think we still have a bug in this PR code. Although this PR will get the correct time on startup, the timestamp will always stay the same as long as the server runs. Then in
jwtClaims :: JWT.Secret -> Text -> NominalDiffTime -> Maybe JWT.ClaimsMap
jwtClaims secret input time =
  case join $ claim JWT.exp of
    Just expires ->
      if JWT.secondsSinceEpoch expires > time
        then customClaims
        else Nothing
    _ -> customClaims

It is checking that expires is greater than time and time will never change. Hence no tokens will expire. That is my hypothesis at least.

@begriffs from my duck testing, this version works and the unsafePerformIO value was a constant (start of server).
@ruslantalpa Restricted the values to the versions I have locally. Still failing.

The test failing is another issue. One of the test commands I'm running is packdeps: https://github.com/begriffs/postgrest/blob/master/circle.yml#L16
Packdeps fails if there are any packages on hackage which have versions newer than we allow in our cabal file. I added the check there so that our program would not fall behind and start having problems building in newer stackage snapshots.
However in this case we're hitting a real problem: the changes in Hasql are big. Our code is incompatible with those changes. So I think we should turn packdeps into a warning rather than error. To do that you could probably add || true to the end of that line in the circle config.

On second thought I think you're right. That runSettings calls our code for each client connect and recalculates the time. I thought the warp listening loop was later for some reason.

@begriffs you were right about packdeps, it's been changed in this PR and the tests are now passing.
@ruslantalpa took out the version restrictions, good call.

What a nasty bug, glad you spotted it and got rid of that gross unsafe perform. Throw a line in the changelog and it looks good.
Wish we could test it somehow but like I mentioned before I don't know a way an easy way to mock time in the tests.

Changelog's got it.

Maybe add an
## Unreleased

before your fix line. Such a nitpick, sorry. :ant:

Done, hope you don't mind the extra commit. Used the GitHub editor :relaxed:


manually test IBC cli cmds

Summary
The IBC cli is not being used or tested. It should be refactored to support more dynamic usage.
Problem Definition
While working through 03-connection I noticed the cmd for the OpenTry handshake passed in proofInit to the proofConsensus field. Any attempt at using this command successfully should fail showing that no one has attempted to use this command (which is essential to doing anything IBC).
The iqlusioninc relayer, one of the more widely used relayers, does not rely on these commands and instead has its own custom cli commands. There should be at least a few usable commands it could import instead of implementing all of its own. This should be true for any relayer.
Proposal
Refactor and test the IBC cli/rest commands with usability in mind. Currently proofs are passed in directly or by json file. There should be an option to pass in a connection endpoint to the counterparty chain to query and parse the proofs directly. Perhaps there should also be commands to query and store proofs (if there isn't already)
This should probably be punted until after the gRPC refactor across the sdk codebase.

A concrete list of things that need to be done to close this issue:
manually test the following cmds:

[x] create client
[x] update client
[x] client misbehaviour
[ ] upgrade client
[x] transfer tx cmd
[ ] transfer query demon trace
[ ] transfer query denom traces
[x] query client state
[x] query client states
[x] query consensus state
[x] query consensus states
[ ] query header
[x] query node consensus state
[x] query connection
[x] query connections
[x] query client connections
[x] query channel
[x] query channels
[x] query connection channels
[x] query channel client state
[x] query packet commitment
[x] query packet commitments
[ ] query unreceived packets
[ ] query unrelayed acks
[x] query next sequence recv

cmds to add and test:

[ ] relay packet
[ ] relay acknowledgement

Also consider applying the original proposal of this issue, allowing an endpoint to be passed/queried for counterparty proofs. Maybe this can be opened in a separate issue and implemented if users request the same feature

closing this issue, most cli commands have been tested. We can address issues as they arise


upgrade to caddyserver v0.7.6

and remove the cherry-pick that was needed in
commit c1c5bbdf5c8870c6325f2c2ce69b55d73ac80c43
since it's no longer needed.

https://circleci.com/gh/jumanjihouse/docker-caddy/41 is clean
:ship:


Idea: Be able to highlight and copy code snippets

Improvement Idea:
Be able to highlight and copy code examples. Right now you can't, except "try it".
Why:
Sometimes I want to be able to lazily copy something to try out locally, where I work 100% of the time. This just restricts it for no reason, and I immediately think it's an image. Some examples don't even have the try feature, so this feels like a significant UX issue for me.
Alternative ideas:
Allow default browser behaviour for code snippets.
Platform

MacOS Chrome ARM (100.0.4896.75)

Thanks so much and appreciate the time!

You make it sound like it's not possible to select the text and copy it in the page? If that's the case, then what is your browser? But all code samples should be OS-level copy and pastable, if it's not that's a real UX issue.
From my perspective, adding a button to copy each code sample seems ok - it's a feature that's useful for mobile where copy & pasting is tricky but far less valuable but when working with code on a desktop (which is about 95% of the traffic) it's value is low. I'd be open to a small bit of JavaScript in documentation pages which adds a copy command to code samples, with a button to the left of 'try'.
Any compiler backed code sample gets a try button because it can be guaranteed to run in the playground, but I think the copy button could exist on any code sample.

I'm seeing this running MacOS Monterrey w/ Chrome ARM (100.0.4896.75) (Macbook Pro 14")
Just checked on x86_64 Windows 11 (Chrome), and I can copy fine so must be a MacOS issue.
Here is what I see on MacOS ARM FWIW:

Given I can actually just copy as normal, that is totally enough IMO, but the button idea is cool too!

Update: I realized it does actually copy to the clipboard if you mouse just right and hit CMD+C (but there is no highlight styling).

Yeah, I think your mouse selection is somehow not showing - I tested on linux chrome dark/light, and macos crome dark/light and didn't get a repro - perhap you have browser extensions doing something to the site?

Interesting. I don't have any extensions that mod.
I asked a few devs at work to reproduce if they could. One ran into it on a M1 Pro 14", then randomly couldn't after restarting chrome. Another dev couldn't reproduce at all. So idk, presuming it's a local thing I don't know what. 😆
I did some more testing though, and FWIW:

Safari (Dark Mode) highlights but selection is black;
Safari and Chrome (Light Mode) highlights are visible
Chrome (Dark Mode) highlights are invisible

Welcome to close btw. Thanks again for the time!


Exit cli on no config file found

It's allowed to call webpack without config file.
i. e. webpack file.js bundle.js...

Ahh right. Closing.


COMP: Export BRAINSCommonLib target for build tree

This commit allows the target "BRAINSCommonLib" to be re-used from project
building against a build tree. This was implemented while working on
simplifying the build tree of DTIPrep Slicer extension.
It also removes unused GenerateBRAINSCommonLibConfig.cmake

Cc: @hjmjohnson

Cc: @ihnorton

No problem. Thanks for integrating.


Unable to force input value

Hi,
I have an integer field (in which I store money amount so "10.34" becomes "1034"), when I edit my model I have a form like this:
<%= f.input :original_amount, as: :string, value: incoming_invoice.original_amount_to_s %>

(incoming_invoice.original_amount_to_s returns something like "10.34")
As you can see I forced it to be a :string but with this line I'm getting a text field (correct) but with "1034" as content (wrong).
Am I missing anything or something doesn't work as expected?
Thank you

Hi,
It's <%= f.input ..., input_html: { value: incoming_invoice.original_amount_to_s} %>

Please use the mailing list or StackOverflow for questions/help, where a wider community will be able to help you. We reserve the issues tracker for issues only.


"SocketException: Address already in use" when trying to start REPL.

I'm stopping and starting REPL from menu and get this error:
System.Net.Sockets.Socket.Bind (System.Net.EndPoint local_end)
System.Net.Sockets.UdpClient.InitSocket (System.Net.EndPoint localEP)
System.Net.Sockets.UdpClient..ctor (System.Net.IPEndPoint localEP)
arcadia/repl$start_server__16640.invokePrim (Int64 )
arcadia/repl$start_server__16640.invoke (System.Object )
clojure.lang.Var.invoke (System.Object arg1)
ClojureRepl.StartREPL () (at Assets/Arcadia/Editor/ClojureRepl.cs:31)```

Apparently REPL is not stopping.

Fixed in aa8b3ad0aecf716a387eb6af06d3f337f8714c9b


Fabio not removing nodes with failed health check

Fabio doesn't seem to be removing nodes/routes which have a failed healthcheck. It seems to notice that the health of the service has changed, but keeps trying to send requests to the failed node (resulting in a 'connection refused').
Only when all nodes are failed, the routes are removed. Adding one of the nodes back, puts all nodes back in the routes, resulting in intermitted 'connection refused' responses again.
DNS lookups to consul return the expected result, which are just the passing nodes.

Is this with 1.0.7?

So far I've tested 1.0.7, 1.0.6 and 1.0.5.

which consul version are you using?

Consul v0.6.0

Ah, haven't tested with consul 0.6.0 yet. Can you post the output of curl localhost:8500/v1/health/state/any?pretty and let me know which services should be omitted?

or if you don't want to do that send me a secret gist

https://gist.github.com/lensen/0a7814ba07ce6c41718e
The first healthcheck of that node is currently in a critical state, and should be removed.
Killing the consul agent and causing the serfHealth healthcheck to fail as well doesn't seem to remove the node either.

If I look at this code https://github.com/eBay/fabio/blob/master/registry/consul/passing.go I can't see how it would be included with a status of "critical". Once the service went critical can you check the fabio logs whether the route for this service is actually there. (reminder to dump raw routing table via api...) Could you post the routing table as well, please?

I think the problem is that it isn't so much the service is failing (the 002 node is still working, so the service is technically OK), but just one of the nodes is.
Anyway, here is the routing table:
#	Service	Host	Path	Dest	Weight
1	local-overview-swap		/overview	http://local-overview-swap-002.localdomain:8080/	50%
2	local-overview-swap		/overview	http://local-overview-swap-001.localdomain:8080/	50%
3	local-content-swap		/content	http://local-content-swap-002.localdomain:8080/	50%
4	local-content-swap		/content	http://local-content-swap-001.localdomain:8080/	50%

fabio goes through the health checks for all instances and not per service. If a health check is for a service (ServiceID != "") and has a Status != "passing" then it is omitted. That's why I don't understand how this can happen. However, I've just spotted something in your health checks. Your ServiceID fields are not unique, i.e. you use "local-overview-swap" for both instances. Try making them unique, e.g. "local-overview-swap-node001-8080". I don't think the way you're doing it is correct but I need to check to be sure.

Specifying a (unique) ServiceID seems to fix it. Looks like a part of the consul puppet module bit me in ***:
define consul::service(
  $ensure         = present,
  $service_name   = $title,
  $id             = $title,

I dunno if you want to keep this issue open or not, but it might make sense to change some logic here, since the consul DNS interface does seem to assume those nodes are really broken and doesn't return them.
Anyway, thanks for the help.

I'll keep that in mind but for now I'd consider this a config issue and close it. Let me know if there are other issues.


Move architecture to latest deb release?

Jessie release of debian is approaching 4 years and end of LTS.
it seems an automate end-of-life of openxpki, to not move to support strech release.
i mean no plans have been released to support a future move to a supported platform, and instructions specifically tells users to use a relase on the last 20% of its lifespan, yet still claiming to be enterprise-grade!?

Jessie ends in June 2020 so there is still 16 month left and we currently tend to skip stretch and directly go for Buster which should be released end of the year.
The current build is not working due to openssl 1.1 and some changed build deps - if you can contribute an updated build script we can add this to our build routines.
If you need "enterprise grade" support we offer packages for "enterprise" distros (Ubuntu, SLES, RHEL) as a paid service.

how is the move towards Buster/Docker compatability coming along?
is Buster supported? (docs still says Jessie)

The docker containers are working but still based on Jessie.
Buster ist basically working but there are some unsolved issues with OpenSSL 1.1 but I expect we gat the solved for the next release towards the end of summer (likely with a major version bump)


Refactor the entire code

The main functionalities are now finished. Refactor and clean-up the code to make future updates more manageable.

Too broad and vague. Create another issue specifying what to clean.


Memperf: reduce allocations in SerializeEncodingChar/WriteEncodingChar and some options boxing

these changes reduce unnecessary memory allocations which results in decreased memory pressure on the garbage collector and better performance.  the changes are all localized so hopefully are easy to review and accept.

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

The test that is failing seems to be unrelated to my change:
Microsoft.Data.SqlClient.Tests.SqlErrorCollectionTest.CopyTo_Throws [1s]

The HasFlags changes aren't needed and I put them in because I was advised to by the jit team because HasFlags is a jit intrinsic on netcore2.1 and later and gets optimized out. sharplab example compare the il and asm in release and you'll see the box is totally removed. If you're using netfx then you've got a lot bigger problems with memory than these calls.

@Wraith2 ok, i've reverted that change.  is there a blog post or documentation on the jit optimization/intrinsic you are referring to?

It's covered in this blog post https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-core-2-1/ but I found it while reviewing PR's in the runtime repo where it was suggested to use HasFlag instead of the masking. The advantage is that the jit sees the call and has a direct transformation for it instead of relying on the translation and simplification steps that should result in the same codegen but might not.


Create a sequence diagram for Archiving to ENA

A high-level sequence diagram for Archiving to ENA, including main interactions between the components:

Archiver
Ingest API
Biosamples API
Biostudies API
ENA API

Think this is done.

ingest-archiver/README.md contains the sequence diagram (HCA Ingest to EBI Archives Flow), and
ingest-archiver/doc (Data files to EBI Archives)


Stub out new Orleans IAsyncBatchObserver functions

Stop gap solution to allow OrleansTestKit to work with Orleans 2.3.0, however no support for IAsyncBatchObserver methods have been added.
In my unit tests, my code base didn't use any of the IAsyncBatchObserver methods so I don't know how to proceed with writing/testing for it

Just noticed my file endings differ, I'll revert those changes in a few...

Thanks for the quick fix, @DarkCow! I'm going to dig in to the new IAsyncBatchObserver, and I'll try to flush out a mock implementation in the near future.


🔥 Get rid of the unused sphinx Makefile

Summary of changes
This change drops the Makefile from docs/ because it's
unused and its existence is misleading. If somebody were to
maintain it, they'd have to keep its configuration in sync
with all the other Sphinx invocation so it's a maintenance
burden to have it in the repo.
Pull Request Checklist

[ ] Changes have tests
[x] News fragment added in changelog.d. See documentation for details

(per https://github.com/pypa/setuptools/pull/2419#discussion_r503460779)

@jaraco mind labeling this PR as hacktoberfest-accepted?


feat: upgrade CI workflows to get them running again

CI is back working, alas not for Python 3.6 as the updated GH Actions don't have access to the installers for this deprecated version.
Will merge as is and track deprecation of Python 3.6 under #91


use environment variables for SHARE URLs

Ticket: []
Feature flag: n/a

Purpose
make it easier to run SHARE with OSF locally

Summary of Changes

update the registries discover page to use config instead of hard-coded URLs
update the collections discover page to stop referencing config it does not use

Screenshot(s)

Side Effects

QA Notes

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.006%) to 72.45%

Totals

Change from base Build<PHONE_NUMBER>:
0.006%

Covered Lines:
5735

Relevant Lines:
7701

💛  - Coveralls


  Users should not need to do anything in order to ensure that EBS volumes share the same tags as all other CloudFormation assets associated with a stack.
Additional context:
ParallelCluster does not currently provide support for applying tags defined in the pcluster-config file to EBS volumes.  Since large provisioned EBS volumes could compose a significant portion of the cluster's operational costs, we should provide a mechanism to track these assets.  As a short term fix, I have submitted a pull request (https://github.com/aws/aws-parallelcluster/pull/864) that will permit an operator to apply tags from the postinstall script.
Ideally, Chef will handle this as part of the stack installation process.  Including code to tag the EBS instances makes sense to include in aws-parallelcluster-cookbook/blob/develop/recipes/base_config.rb or as a separate recipe.

I verified with ParallelCluster 3.0.2 with a configuration like this:
HeadNode:
  ...
  LocalStorage:
    RootVolume:
      Size: 50
    EphemeralVolume:
      MountDir: /test
...
SharedStorage:
  - MountDir: /ebs
    Name: myebs
    StorageType: Ebs
  - MountDir: /efs
    Name: myefs
    StorageType: Efs
Tags:
  - Key: testtag
    Value: tagvalue

and I can confirm the tags are correctly attached to both the ephemeral volume, the external EBS volume and EFS. Closing this.


[ROCm]: Disable some tests on ROCm platform

Disable some failing tests on ROCm for now

tests/experimental_rnn_test.py::test_lstm
tests/linalg_test.py::testEighIdentity
tests/linalg_test.py::testTridiagonal
tests/linalg_test.py::testToeplitzSymmetricConstruction
tests/linalg_test.py::testDirichlet
tests/linalg_test.py::testDirichletSmallAlpha

Looks good aside from the lint error (trailing whitespace).

Fixed.

@jakevdp  If it looks good, then please merge whenever you get a chance. Thanks!


Added non-template scaling

I'm adding my code from before, with an alternative non-template based scaling approach.

This looks great @Milo-Moses! I've merged your branch into a Python project format to make it easy for people to navigate the code. I'll go ahead and merge the other PR.

Stale.


Multi-language support through i18n

Hello. I like your theme and since I'm using it on a blog written in Italian, I think it would be nice if it could support multi-language through i18n if you might like it.

Quick question, do you want to do this for localizing dates, too?
https://gohugo.io/content-management/multilingual/#customize-dates


week of 6/20

[ ] update proposal document

@ebridge2: these things due by Thursday

[ ] full quality control results for KKI dataset (deliverable is a folder on google drive containing 7 figures and 1 statistical summary for each scan)

[x] implement quality control from CPAC; figure out what they do differently from Harvard (deliverable is a three column spreadsheet, with unique from Harvard, overlap, and unique from CPAC)
https://docs.google.com/spreadsheets/d/14P_ot2f2XpJsINiRrOYN1FC_SDIyIsHRM2xzXqWDJU0/edit?usp=sharing

[ ] discriminability results for KKI dataset (figure showing distance matrix and discriminability, and another figure with intra vs inter subject kde and hellinger distance between the two)

by Monday:

[ ] pseudocode for deciding a way to compare spatial smoothing effectiveness, decide how/when to resample, how to compare before/after of registration properly

@ewalke31: by thursday

[ ] reproduce figures from PLDS project
by Monday:
[ ] summarize ch. 4-7 of fmri data analysis book

TODOs 1 and 3 may take until Friday or weekend as NKI dataset (being used since it is isotropic while KKI is antisotropic) has far more timesteps than KKI (like 5x more timesteps per graph as the most reliable scans were TR = 645 ms), and the runs will not be up until tomorrow since I am modifying the QC pages extensively

:ok_hand:
On Tue, Jun 21, 2016 at 7:18 PM, ebridge2<EMAIL_ADDRESS>wrote:

TODOs 1 and 3 may take until Friday or weekend as NKI dataset (being used
since it is isotropic while KKI is antisotropic) has far more timesteps
than KKI (like 5x more timesteps per graph as the most reliable scans were
TR = 645 ms), and the runs will not be up until tomorrow since I am
modifying the QC pages extensively
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Upward-Spiral-Science/fngs/issues/17#issuecomment-227600670,
or mute the thread
https://github.com/notifications/unsubscribe/AACjcnwC8U93IJNa40Q6HK2cNnaU1uTFks5qOHE5gaJpZM4I6JRE
.

--
the glass is all full:  half water, half air.
neurodata.io, jovo calendar
https://calendar.google.com/calendar/embed?src=joshuav%40gmail.com&ctz=America/New_York


Improve optimization of lazy properties.

There are two main changes here:

Prevent inlining of lazy property getters

Lazy property getters are usually non tivial functions (otherwise the user would not implement it as lazy property).
Inlining such getters would most likely not benefit other optimizations because the top-level switch_enum cannot be constant folded in most cases.
Also, not inlining lazy property getters enables optimizing them in CSE.

Optimize calls of lazy property getters

If such a call is dominated by another call to the same getter, it is replaced by a direct load of the property - assuming that it is already computed.
rdar://problem/34715412

@swift-ci test

@swift-ci benchmark

Performance: -O

Regression
OLD
NEW
DELTA
RATIO

StringToDataEmpty
500
550
+10.0%
0.91x (?)

Code size: -O
Performance: -Osize

Regression
OLD
NEW
DELTA
RATIO

FlattenListFlatMap
3382
4399
+30.1%
0.77x (?)

Code size: -Osize
Performance: -Onone

Regression
OLD
NEW
DELTA
RATIO

DataAppendDataMediumToMedium
3000
3300
+10.0%
0.91x (?)

Code size: -swiftlibs

How to read the data
The tables contain differences in performance which are larger than 8% and
differences in code size which are larger than 1%.
If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.
Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview
  Model Name: Mac mini
  Model Identifier: Macmini8,1
  Processor Name: Intel Core i7
  Processor Speed: 3.2 GHz
  Number of Processors: 1
  Total Number of Cores: 6
  L2 Cache (per Core): 256 KB
  L3 Cache: 12 MB
  Memory: 64 GB

Build failed
Swift Test Linux Platform
Git Sha - 0d7b64147267db22cfdb52cae8bc783d1385faa1

Build failed
Swift Test OS X Platform
Git Sha - 0d7b64147267db22cfdb52cae8bc783d1385faa1

@swift-ci test

Build failed
Swift Test Linux Platform
Git Sha - 0d7b64147267db22cfdb52cae8bc783d1385faa1

@swift-ci test


Github beta discutions repo [suggest]

Did you think the admin of this repository might consider adding support for discussions Github Vercel beta?
I have nothing vs Stackoverflow but centralizing issues, supports and discutions about VsCode at the same place would be ideal I think.
Many projects are starting add and use this discutions tab.

https://github.com/vercel/vercel/discussions/3874
thanks

/duplicate of #113561


Pop up window are tiled

Sorry to bother you again, but I notice that in settings if a pop-up window appear, is tiled and not floating.
Like that

I don't know if I had to insert something in the whitelist, I try but that window is see as "setting" and i can't put setting in the whitelist because it'll make all setting floating, not only the pop.up one.

I know about this issue but I don't know if KDE on Wayland supports EWMH hints, including the _NET_WM_WINDOW_TYPE that the scripts need to figure out what type of window a selected window is and whether it's a pop up or not. Most windows I've inspected have had all properties set, so they get tiled no matter what. I'll test it later and see what I can do.

I found out that KWin on Wayland has no support for EWMH outside of knowing that Plasmashell is a desktop. However, pure Wayland clients have xdg-shell support, which tells whether a window is normal or a popup. The script now does not tile windows that are marked as popups, however some windows (including lots of systemsettings windows) are not marked this way. v1.0.1 will not fix that specific issue, but it will fix most other similar issues with non XWayland apps.

So, there is nothing that can be done?
Or we have to wait that Wayland include support for EWMH?

If the specific popup in question still doesn't work, then I don't know if there's more that I can do on the scripting side. v1.0.1 works for me for supported popups though.

Yeah, for supported popuo it works for me too.
the problem is with the setting popup, with them don't work

I'm sorry, but now for some strange reason it have start working fine.
Maybe it was my fault, i didn't reboot when i update the script

That's good. Closing as completed