🪲[Bug]: Contact Section color is too dark due to that contact us is not visible

Describe the bug
🪲[Bug]: Contact Section color is too dark due to that contact us is not visible.
I'll fix all these issues and also add some new features in contact section if you assign me this
SS-

@akshitagupta15june
can you please assign me this under gssoc'24.

i want to work on this issue...please assign me @akshitagupta15june  @sakeel-103

Go for it!

Hello @akshitagupta15june
I would like to work on this issue, please assign it to me :)

@akshitagupta15june
ma'am you didn't give a level.


脚本生成自定义出码方案，run build报错

Describe the bug (required) / 详细描述 bug（必填）
脚本生成自定义出码方案run build报错
A clear and concise description of what the bug is. / 请提供清晰且精确的 bug 描述

To Reproduce (required) / 如何复现 bug？（必填，非常重要）
Steps to reproduce the behavior: / 详细复现步骤：
1.npx @alilc/lowcode-code-generator init-solution
2.npm i
3.npm run build
Expected behavior (required) / 预期行为（必填，非常重要）
A clear and concise description of what did you expect to happen. / 请清晰和精确的描述你预期的行为

Screenshots (optional) / bug 截图（可选）
Sceenshots for further information. (If applicable.) / 一些有用的截图将会帮助我们更好的明确以及定位问题

Environments (please complete the following information) (required): / 请提供如下信息（必填）

AliLowCodeEngine version: [e.g. 1.0.0] / 低代码引擎版本
AliLowCodeEngineExt version: [e.g. 1.0.0] / 低代码引擎扩展包版本
Browser [e.g. chrome, safari] / 浏览器版本
materials / plugins / tools / 其他物料 / 插件 / 工具链版本

(this information can be collected via the manual plugin / 版本信息可通过低代码用户手册插件收集)

Additional context (optional) / 更多额外信息（可选）
Any other context of the problem here. / 可以追加更多的额外信息，帮助定位问题

看不懂~
检查下是不是用了 wsl？是不是某些包没装？乱码问题也解决下

@YuXiang940421 我跟你一样

Active code page: 65001

<EMAIL_ADDRESS>build
npm run clean && concurrently 'npm run build:ts' 'npm run lint'

<EMAIL_ADDRESS>clean
rm -rf build dist lib generated

[0] ''npm' is not recognized as an internal or external command,
[0] operable program or batch file.
[1] 'run' is not recognized as an internal or external command,
[1] operable program or batch file.
[2] The filename, directory name, or volume label syntax is incorrect.
[3] ''npm' is not recognized as an internal or external command,
[3] operable program or batch file.
[4] 'run' is not recognized as an internal or external command,
[4] operable program or batch file.
[5] 'lint'' is not recognized as an internal or external command,
[5] operable program or batch file.
[4] run exited with code 1
[3] 'npm exited with code 1
[2] build:ts' exited with code 1
[1] run exited with code 1
[0] 'npm exited with code 1
[5] lint' exited with code 1


Control: Anchor is now 0 to 1 float (WIP)

Partially fixes #9520
It kinda works now but still needs some changes to be user-friendly.

We had ratio anchoring in the past, which provided a similar function, but
was removed as it was very user unfriendly.
Thanks for the work, though I myself am not convinced this is an
improvement.
The reasoning is that, In 99.99% of cases, you just want to anchor to begin
or end so making the user experience worse for a different, corner case is
generally not a good idea
On Thu, Jul 6, 2017 at 9:41 AM, Poommetee Ketson<EMAIL_ADDRESS>wrote:

Partially fixes #9520 https://github.com/godotengine/godot/issues/9520
It kinda works now but still needs some changes to be user-friendly.
You can view, comment on, or merge this pull request online at:
https://github.com/godotengine/godot/pull/9527
Commit Summary

Control: Anchor is now [0,1] float

File Changes

M editor/plugins/canvas_item_editor_plugin.cpp
https://github.com/godotengine/godot/pull/9527/files#diff-0 (2)
M editor/plugins/canvas_item_editor_plugin.h
https://github.com/godotengine/godot/pull/9527/files#diff-1 (2)
M scene/gui/control.cpp
https://github.com/godotengine/godot/pull/9527/files#diff-2 (87)
M scene/gui/control.h
https://github.com/godotengine/godot/pull/9527/files#diff-3 (23)
M scene/gui/popup.cpp
https://github.com/godotengine/godot/pull/9527/files#diff-4 (16)

Patch Links:

https://github.com/godotengine/godot/pull/9527.patch
https://github.com/godotengine/godot/pull/9527.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/pull/9527, or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z22H3HMiXNzIil1fZphSM701paUZwks5sLNYEgaJpZM4OPlCy
.

I'm little late. but I got evidence what @reduz said.

This is screenshot with Godot 1.1

Still the PR is not exactly the same, I think what it does is pretty cool,
but It's not very user friendly. This is why for more complex behaviors,
containers are preferred.
On Thu, Jul 6, 2017 at 10:02 AM, volzhs<EMAIL_ADDRESS>wrote:

I'm little late. but I got evidence what @reduz https://github.com/reduz
said.
[image: image]
https://user-images.githubusercontent.com/8281454/27912131-bb61fd4e-6296-11e7-93b1-0b01556174c8.png
This is screenshot with Godot 1.1
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/pull/9527#issuecomment-313389518,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z29Y0BN4XYQnbdR2kCLQUKEN2pTZ5ks5sLNrogaJpZM4OPlCy
.

How can I make a Button keep align Bottom-Left by 10px after this change?

How can I make a Button keep align Bottom-Left by 10px after this change?

I wonder that too.

I don't think this is a good idea as this would break almost all of the ui scenes imported from 2.x in the feature.

How can I make a Button keep align Bottom-Left by 10px after this change?

Anchor
Margin

Top
1 (ANCHOR_END)
?

Left
0 (ANCHOR_BEGIN)
10

Right
0 (ANCHOR_BEGIN)
?

Bottom
1 (ANCHOR_END)
10

I'm not denying it's a good idea from the technical standpoint. just that
it's not as user friendly.
On Jul 6, 2017 12:22 PM, "Poommetee Ketson"<EMAIL_ADDRESS>wrote:

How can I make a Button keep align Bottom-Left by 10px after this change?
Anchor Margin
Top 1 (ANCHOR_END) ?
Left 0 (ANCHOR_BEGIN) 10
Right 0 (ANCHOR_BEGIN) ?
Bottom 1 (ANCHOR_END) 10
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/pull/9527#issuecomment-313429098,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z24GlluZZvRYm5DO2861HtV8d39kKks5sLPvKgaJpZM4OPlCy
.

I think the frontend could be left unchanged (keeping the Begin,End,Center in the property selector) while internally support float via scripting.


Support for React-Native

Hi, I read the code and you're using ReactDOM. I wonder if you plan to support React Native?

I can help take a look on this one

@n3tr I've checked your PR, would it be better if you programatically detect if the environment is web or mobile? Instead of hardcoded imports from react-native? Or separate path for import for react-native, for example import useSwr from  '@zeit/swr/react-native'?

For projects using react-navigation, it'd be possible to support revalidateOnFocus and refreshWhenHidden via useIsFocused or useFocusEffect I think. That would likely be a separate package since not all react-native projects use react-navigation.

Any update on support for React Native?

Any update on support for React Native?

It's already working in React Native.

For projects using react-navigation, it'd be possible to support revalidateOnFocus and refreshWhenHidden via useIsFocused or useFocusEffect I think. That would likely be a separate package since not all react-native projects use react-navigation.

@Jarred-Sumner Have you seen anyone implement this already for react-navigation? If not, I would be happy to help.

Using https://reactnative.dev/docs/appstate to enable revalidateOnFocus and refreshWhenHidden could work I think:

When appState go to background -> refreshWhenHidden
When appState go to active -> revalidateOnFocus

What do you think?

For projects using react-navigation, it'd be possible to support revalidateOnFocus and refreshWhenHidden via useIsFocused or useFocusEffect I think. That would likely be a separate package since not all react-native projects use react-navigation.

@Jarred-Sumner Have you seen anyone implement this already for react-navigation? If not, I would be happy to help.

Did you do any implementation for this?

For projects using react-navigation, it'd be possible to support revalidateOnFocus and refreshWhenHidden via useIsFocused or useFocusEffect I think. That would likely be a separate package since not all react-native projects use react-navigation.

@Jarred-Sumner Have you seen anyone implement this already for react-navigation? If not, I would be happy to help.

Did you do any implementation for this?

+1

@Jarred-Sumner @mrgiacomini @jbowa
How about this?
import { useCallback, useRef, useEffect, useMemo } from 'react';
import { useFocusEffect } from '@react-navigation/native';
import useSWRLib, { keyInterface, responseInterface, ConfigInterface } from 'swr';
import { fetcherFn } from 'swr/dist/types';

export default function useSWR<Data = any, Error = any>(
  key: keyInterface,
  fn?: fetcherFn<Data>,
  config?: ConfigInterface<Data, Error>
): responseInterface<Data, Error> {
  const query = useSWRLib(key, fn, config);

  const isMountedRef = useRef(false);

  const revalidateOnFocus = useMemo(() => {
    if (config && config.revalidateOnFocus === false) {
      return false;
    }
    return true;
  }, [config]);

  useFocusEffect(
    useCallback(() => {
      // do not refetch when query is initially mounted
      if (isMountedRef.current && revalidateOnFocus && query.revalidate) {
        console.log('Revalidating on focus!');
        query.revalidate();
      }
    }, [query, revalidateOnFocus])
  );

  useEffect(() => {
    isMountedRef.current = true;
  }, []);

  return query;
}

I've published @nandorojo/swr-react-native on npm. It adds compatibility for focus events, reconnection, and react navigation.
Link: https://github.com/nandorojo/swr-react-native
The usage is as simple as:
- import useSWR from 'swr'
+ import useSWRNative from '@nandorojo/swr-react-native'

You can also use it like this:
import { useSWRNativeRevalidate } from '@nandorojo/swr-react-native'

const { data, revalidate } = useSWR(key, fetcher)

useSWRNativeRevalidate({
  // required: pass your revalidate function returned by SWR
  revalidate

  // optional, defaults copied from SWR
  revalidateOnFocus: true,
  revalidateOnReconnect: true,
  focusThrottleInterval: 5000,
})


Feature/add uri link to commit for targetprocess comment

It would be nice to be able to link back to the commit on github from the story in TargetProcess.

Hi!  Thanks for the pull request.  I see two things here.  First, the simple line break (\n) may not display as a line break within TargetProcess - the comment blocks aren't wrapped in <pre> tags.  That will need to (more than likely) be changed to a <br/>.  Also, while you're in there, I would move the commit_url = commit["url"] line on line 40 outside the .each block (between lines 29 and 30) for consistency's sake and since there's no point in assigning the commit_url variable the same value over and over again.
If you could just take care of those two things and add the commit to this pull request, I'd be more than happy to merge.
Cheers!

Jonathan

Hope this works out better. It should be super helpful.
Thanks, Tom

Hi Tom,
I merged this request in with the code and submitted another pull request up to GitHub to merge it into their codebase (github/github-services#240).  As soon as they've done their merge, the code should be live.
Thanks!

Jonathan


Organization Name Change

The organization name changed. I've updated the CircleCI Badge.

Ugh, apparently I started this on master without realizing.

Seems that master was ahead of develop. This will actually probably be good for the repository since I have the changes in master in here, to push them through develop branch.


Reaction widget

A widget that allows for people to, in the middle of an interview without triggering a page reload, give reactions (thumbs up and thumbs down for now) and text feedback. A much more light weight solution than an entirely separate interview, that can help us triage which interviews need more attention, directly from our users. Screenshots at the bottom of this PR description.
To get the widget, you call the reaction_widget function, passing in:

an up_action that will be executed on the server if the thumbs up is pressed,
a down_action (same, but for the thumbs down)
(optionally) a feedback_action, which will can get the actual feedback text with action_argument('feedback_text').
Once you press either of the thumbs, a text input screen with a submit button appears, and once the text feedback is submitted, those fade away, leaving a final "thank you" message.
The user displayed text is also customizable.

I followed the existing pattern that the al_document uses currently, it's pretty clean and flexible enough.
Despite mentioning otherwise in https://github.com/SuffolkLITLab/docassemble-GithubFeedbackForm/issues/17, it actually does make sense to add a feedback widget to ALToolbox, and just leave the idea of saving the feedback to the Feedback package.
Only other changes that were made in this PR were to allow passing in 'md' to the fa_icon function, which broke the icons before.
Open to CSS suggestions, I know I'm not the person to polish it to a tee so I just got something that looked okay to me, and didn't try to make it too flashy.
The Thumbs widget (everything in and including the box)

The Text portion of the feedback

The final thanks

using a lighter weight would be helpful

What do you mean by this again? Like a lighter color (or just an outline) for the icons?

I also think we might decide to use a built-in Bootstrap component, like a modal, to simplify styling and make it easier to keep consistent with a Bootstrap theme: https://getbootstrap.com/docs/5.0/components/modal/
Maybe even better: https://getbootstrap.com/docs/5.0/components/offcanvas/ (the one that comes up on the bottom)

That's fair. While those do look better, personally I have a visceral negative reaction to little popups like that on other websites, reminds me too much of stuff like https://how-i-experience-web-today.com/detail.html. If we want to stick with bootstrap, I like the idea of using a card (this version looks good: https://getbootstrap.com/docs/5.0/components/card/#titles-text-and-links).

Using the bootstrap card looks like it solves most of the box styling problems. Would love to still get a review on if my JS and CSS is up to par as well.
Here's what the widget looks like now:

I like the card--very nice and clean look with that change. Looks ready to merge--will let you do that.

After some conversation on today's standup, I changed the main keyword feature to be "review", not "reaction", and also changed some of the default wording in the widget. Should be ready to go, I'm going to merge


Does not check for type returned by other function

def f(x: String)
  x
end

def g(y: Integer)
  puts y.class
  y
end

def h(a)
  g(f(a))
end

h("should throw an exception")

This actually works as expected, but it's bug-prone so I think it's time we fix this.
In your example, Integer doesn't exist. The name of the class you are looking for is Int. This gives the correct compile-time error:
def f(x: String)
  x
end

def g(y: Int)
  puts y.class
  y
end

def h(a)
  g(f(a))
end

h("should not compile") # and does not

In fact, you don't need f, g, and h to trigger the "bug":
def foo(x : SomeRandomWord)
end

foo "hello" # works

However...
class SomeRandomWord
end

def foo(x : SomeRandomWord)
end

foo "hello" # error!

From this you can tell the compiler works like this: if it finds a type with the name on the type restriction, it checks if you pass the correct type. Otherwise, it lets the type pass, and makes that name capture the given type. That is, it acts as a free variable. For example:
def foo(x : T)
  puts T
end

foo "hello" # prints String
foo 1 # prints Int32

Of course, if I go and define a type named "T", it stops working.
The above lets you do some nice things, like this:
# Pass me two variables of the same type, I don't care which type
def foo(x : T, y : T)
end

# Pass me a type and an array of that type
def foo(x : T, a : Array(T))
end

But the rule "if the type is not defined then it's a free var" is very fragile and bug-prone. How can we improve this?
My ideas are:

Use a new symbol to denote free vars. For example def foo(x : @T) or def foo(x : 'T).
Use the convention that in order to declare a free var it must be a single uppercase letter: def foo(x : T). With this, the above example using Integer would have given an error.
Some other idea...?

I personally like number 2. Of course this won't work if someone defines a class named "T", but we can either disallow those names or just assume they won't be used for real programs (but it's nice to be able to use A, B and C in sample code). Another good thing about point 2 is that it's easy to implement and backwards compatible, and keeps noise at a minimum.
What do you think?

So I use Scala a lot and over there we have sth like that:
def function[T](variable: T)
  puts variable
end

I think that introducing generic types for methods or even classes would be an awesome idea. It may allow also use inheritance and Variance like:
def function[-T](variable: T)
  puts variable
end

or
def function[+T](variable: T)
  puts variable
end

Have a look: https://twitter.github.io/scala_school/type-basics.html

I'd go for number 2 with conventions:

a generic is denoted as a capital letter (eg: T);
convention says the first parameter should be T, and the return type should be R;
convention says that single letter constants are allowed, but discouraged to avoid conflicting with generic types.

A quick grep into Crystal's source code, shows that these are used: T (first generic), U (second generic), R (return), I (iterator), K, V (key, value).


Ubuntu 22.04 poetry run reflex run on an app ends up with bun install error

Describe the bug
I cloned the reflex repo on a ubuntu machine, then made a folder examples and clones all the examples into that example folder. Then I ran poetry run reflex run. It ended in error.
I was able to get around it by first creating a poetry subshell, then run reflex run instead that subshell works. Not sure if this is a reflex issue, maybe a poetry issue.
To Reproduce
Steps to reproduce the behavior:

Code/Link to Repo:

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
This is the debug log.
Compiling:  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 2/2 0:00:00
Debug: Running command: ['/home/ubuntu/.local/share/reflex/bun/bin/bun', 'install', '--loglevel', 'silly']
Debug: Installing base frontend packages
Debug: bun install v1.0.4 (745b6b94)
Debug:  Resolving dependencies
Installing base frontend packages failed with exit code -9
bun install v1.0.4 (745b6b94)
 Resolving dependencies
Run with --loglevel debug  for the full log.

Specifics (please complete the following information):

Python Version: 3.10
Reflex Version: 0.3.1
OS:  ubuntu 22.04.3 LTS
Browser (Optional):

Additional context
Add any other context about the problem here.

Do you have the full log for this ?
Saw the same exit code on Discord for someone where bun was using the wrong node version.

Closing as we've made major updates since this - we can reopen if this issue persists.


Offset feature (skip_updates).

By the way, IDK if i wrote it correct, but this should add skip_updates feature in init of the client, which will skip all old updates, and get the new ones.

You forgot to create new branch habibi, now 2 commits at one.
close this pr and open new one from new beanch.

LOL, sorry.

also you might have to use ruff check tgram and ruff format to pass all checks


ptpwd doesn't compile on MacOS Monterey 12.3[BUG]

Looking at the makefile, there doesn't seem to be anything to figure out what kind of system it will be compiled on.
Somethings compile with warnings and others error from the linux headers in the main.c code.
Downloading a fresh repo copy and running make give the following error:
mkdir -p build
rm -rf build/*
mkdir -p build/bin
mkdir -p build/share
mkdir -p build/share/ptSh
gcc src/common/*.c src/ptls/*.c -lm -o build/bin/ptls
src/ptls/fields.c:46:32: warning: format specifies type 'int' but the argument has type '__darwin_ino64_t' (aka 'unsigned long long') [-Wformat]
  sprintf(fields->inode, "%d", file->stats->st_ino);
                          ~~   ^~~~~~~~~~~~~~~~~~~
                          %llu
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/secure/_stdio.h:47:56: note: expanded from macro 'sprintf'
  __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
                                                       ^~~~~~~~~~~
1 warning generated.
gcc src/common/*.c src/ptpwd/*.c -lm -o build/bin/ptpwd
src/ptpwd/main.c:1:10: fatal error: 'linux/limits.h' file not found
#include <linux/limits.h>
         ^~~~~~~~~~~~~~~~
1 error generated.
make: *** [all] Error 1

System Info
gcc --version
Apple clang version 13.1.6 (clang-13<IP_ADDRESS>)
Target: x86_64-apple-darwin21.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

uname -a
Darwin genes-iMac-Pro.local 21.4.0 Darwin Kernel Version 21.4.0: Mon Feb 21 20:34:37 PST 2022; root:xnu-8020.101.4~2/RELEASE_X86_64 x86_64

Duplicate: https://github.com/jszczerbinsky/ptSh/issues/47


rtabmap: 0.11.7-1 rtabmap_ros: 0.11.7-2 in 'indigo/distribution.yaml'

Increasing version of package in repository rtabmap to 0.11.7-1 and rtabmap_ros to 0.11.7-2:
upstream repository: https://github.com/introlab/rtabmap.git https://github.com/introlab/rtabmap_ros.git
release repository: https://github.com/introlab/rtabmap-release.git https://github.com/introlab/rtabmap_ros-release.git
distro file: indigo/distribution.yaml
bloom version: 0.5.21
previous version for package: 0.11.7-0 and 0.11.7-1

holding releases until indigo sync is complete


[Feature Request] Ability to save/unsave post.

Hello I can access my saved post using u/saved. But I can't find a way to save new post or to unsave them. It would be very useful if this could be added.
Another little ting that would be great is that when going to an user profile only the overview is available. That mix all the post and comment that the user make and is not very practical to use. Most android app propose two other sections,  posted (to show only the post the user make) and comment (for the comment). It would be great to also have this section in rtv.
Thank you.

This is already possible. The default binding isw to (un)save.
As to your second point, that is a good idea. One should be able to go to seperate pages like this: u/spez/posts u/spez/comments. While u/spez defaults to the overview page.

RTV now supports separate URLs to distinguish between comments and submissions
/u/me/overview (both comments and submissions)
/u/me/submitted
/u/me/comments


add libc++ compatibility by checking for <experimental/memory_resource>

Until LLVM 16 is released, and until Android and Apple platforms incorporate the forthcoming std::pmr support in their forks of libc++, this workaround is needed to use pmr containers on those platforms.

Those CI check results are unfortunate. I can easily fix the clang-format issue but making the pmr unit test pass on macos would involve some pretty intrusive changes.
In my project I have to jump through several hoops to get pmr working on macos. It basically  involves creating an alias for every pmr type and use the preprocessor to make sure they resolve to the correct namespace.

I'm fine with you just #ifdef-ing the test out for macos, e.g. add something to the condition of
#if ANKERL_UNORDERED_DENSE_PMR in pmr.cpp. Not sure though how to detect macos

Thanks for your contribution!

I created a new release v3.0.2 with your changes


fixset replication_allocation = 1

What problem does this PR solve?
pick from master https://github.com/apache/doris/pull/44199
Related PR: #xxx
Problem Summary:
Release note
None
Check List (For Author)

Test

[ ] Regression test
[ ] Unit Test
[ ] Manual test (add detailed scripts or steps below)
[ ] No need to test or manual test. Explain why:

[ ] This is a refactor/code format and no logic has been changed.
[ ] Previous test can cover this change.
[ ] No code files have been changed.
[ ] Other reason

Behavior changed:

[ ] No.
[ ] Yes.

Does this need documentation?

[ ] No.
[ ] Yes.

Check List (For Reviewer who merge this PR)

[ ] Confirm the release note
[ ] Confirm test cases
[ ] Confirm document
[ ] Add branch pick label

run buildall


Add unboxed single-type Array backends

The discussion on Twitter regarding GH-320 brought up a paper on storage strategies for collection types in dynamic language VMs.
The paper makes two claims:

H1  It is uncommon for a homogeneously typed collection storing objects of primitive types to later type dehomogenise.
H2  When a previously homogeneously typed collection type dehomogenises, the transition happens after only a small number of elements have been added.

Artichoke's Array class cluster would support specializing the backend by value type in addition to length. The Aggregate type would also mean that we would not have to reallocate as an Array dehomogenises.

[ ] Int-valued Array (Ruby Integer)
[ ] Float-valued Array (Ruby Float)
[ ] true + false-valued Array (Ruby TrueClass and FalseClass)
[ ] byte slice/str-valued Array (Ruby String)
[ ] Option of the above types (above Ruby type or NilClass)

I'm not sure how useful this would be, but we could also store unboxed non-primitives such as Regexp or Array.
Ruby Float and String are not "immediates."  This struct is also used for equal? identity and tracking an object_id. Unboxed Arrays of non-immediates also need to track a parallel set of RBasic pointers for GC marking and reboxing.
There are some operations on these unboxed Arrays that are more convenient and more performant to do in Rust, like Array#sort, Array#sum, Array#index.

GH-458 removed the polymorphic Array backends. This ticket is obsolete.


Allow user to override manifest entries with dotted keys

Resolves https://github.com/istio/istio/issues/19196
The syntax from bash is istioctl manifest generate --set "values.sidecarInjectorWebhook.injectedAnnotations.container\.apparmor\.security\.beta\.kubernetes\.io/istio-proxy=runtime/default"
The quotes are necessary because Bash will eat the \ without them.
Although the generated output is seems correct I noticed that setting the injectedAnnotations this way causes proto: tag has too few fields: "-" to be written to stdout.  I believe this is not a new bug, but another example of https://github.com/kubernetes/kubernetes/issues/86739

@esnible: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

pilot-e2e-envoyv2-v1alpha3_istio
12fc5a168bb63393902c18cd8ce811d49d6a2968
link
/test pilot-e2e-envoyv2-v1alpha3_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@richardwxn Which README?
I will also add an example of \. to the examples in operator/cmd/mesh/manifest-apply.go and friends so that the CLI help text shows it.

@esnible thx, I think that would be great

@esnible: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
eb9f802db354630ccdc9803589d5601e2eb1d57f
link
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

In response to a cherrypick label: #20949 failed to apply on top of branch "release-1.5":
error: Failed to merge in the changes.
Using index info to reconstruct a base tree...
M	operator/pkg/tpath/tpath.go
M	operator/pkg/tpath/tpath_test.go
M	operator/pkg/util/path.go
Falling back to patching base and 3-way merge...
Auto-merging operator/pkg/util/path.go
CONFLICT (content): Merge conflict in operator/pkg/util/path.go
Auto-merging operator/pkg/tpath/tpath_test.go
CONFLICT (content): Merge conflict in operator/pkg/tpath/tpath_test.go
Auto-merging operator/pkg/tpath/tpath.go
Patch failed at 0001 Allow user to override manifest entries with dotted keys


docs: fix bug in usage block

Description

Release required?

[x] No release
[ ] Patch release (x.x.X)
[ ] Minor release (x.X.x)
[ ] Major release (X.x.x)

Release notes content

Run the pipeline
If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.
Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:
/run pipeline

Checklist for reviewers

[ ] If relevant, a test for the change is included or updated with this PR.
[ ] If relevant, documentation for the change is included or updated with this PR.

For mergers

Use a conventional commit message to set the release level. Follow the guidelines.
Include information that users need to know about the PR in the commit message. The commit message becomes part of the GitHub release notes.
Use the Squash and merge option.

Lets hold off for now - scope is now a first class citizen, but the provider hasn't been updates yet to support managing scopes (coming in https://github.com/IBM-Cloud/terraform-provider-ibm/issues/5731)

/run pipeline

:tada: This PR is included in version 1.8.25 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Use test class assertions instead of raw assert?

Should we use assertion methods inherited from Django's TestCase class or raw Python assert statements?

On Tue, Jan 20, 2015 at 06:01:07PM -0800, Greg Wilson wrote:

Should we use assertion methods inherited from Django's TestCase
class or raw Python assert statements?

I think so, since you'll get automatically generated messages
explaining why the test failed.  You can write that out by hand, but I
think that's just extra code to maintain (e.g we currently hard-code
the expected value in the error string here 1, which is not very
DRY).

+1 to clear reporting.
Additionally, some behaviors (eg exceptions) are difficult to test using bare assertions, whereas Testcase offers functionality such as self.assertRaises. Might as well use the capabilities of the framework in a consistent manner.

Personally I prefer py.test with assert statements over Java-ish unittest TestCases.
Having assertions in my tests seems more natural.
Additionally I have test marking (you can for example, run only tests marked as "regression" or "fast"), parametrization (no more for-loops in tests), or even test parallelization (for testing on multiple cores).
The are some downsides, too, like loosing client and response objects…
Anyway, I know we're not considering switching to py.test, but that's only my 2 cents on "assert vs self.assert*".

On Thu, Jan 22, 2015 at 03:22:03PM -0800, Piotr Banaszkiewicz wrote:

Additionally I have test marking…,

You can do this in Python ≥3.1 with skipIf 1.

parametrization …,

You can do this in Python ≥3.4 with subTest 2.

or even test parallelization…

This isn't possible with the current unittest implementation, but
since it's just a speed issue, I don't consider it to be a big enough
loss to be worth requiring an external testing library.

Hey @wking,

You can do this in Python ≥3.1 with skipIf [1].

Skipping and conditional skipping is only a small subset of what you can do with tests marking.

You can do this in Python ≥3.4 with subTest [2].

That's a horrible syntax… But I'm glad this feature has finally landed in mainline Python.

This isn't possible with the current unittest implementation, but since it's just a speed issue, I don't consider it to be a big enough loss to be worth requiring an external testing library.

In my opinion, py.test is worth considering. Here are prons:

you don't have to worry about compatibility and different tests for different Python versions (nice unittest features like comparing data structures landed in Python 2.7, but some, as @wking mentioned, are only available in Py3) - this automatically enables us to use goodness from newer py.test versions on both Python 2.x and 3.x

your tests are more "pythonic"

you don't have to remember all "assert*" methods, because you only need "assert" statement (and perhaps pytest.raises context manager)

much, much more

However there are some cons, too:

migration effort

learning curve (when people are used to xUnit testing style)

Personally I really like using py.test and highly recommend it.
This thread is turning into off-topic "vim vs emacs" kind of war, so let's say that if we stick to unittest we should use unittest-style testing with .assert* methods; otherwise (in case of switching to py.test) we should use Python assertions.

How's this as a new rule? Every post on this thread must be accompanied
by at least one test case for a part of Amy that isn't currently
exercised.  First up: testing CSV upload... :-)

First up: testing CSV upload... :-)

Yeah, I'm waiting for https://github.com/pbanaszkiewicz/amy/pull/3 (@sburns) :)

Do you need a review?

I need to know if @sburn is going to finish https://github.com/pbanaszkiewicz/amy/pull/3, otherwise I can do it.
Then I'll send a ready for review PR.

On Fri, Jan 23, 2015 at 03:57:09AM -0800, Piotr Banaszkiewicz wrote:

This thread is turning into off-topic "vim vs emacs" kind of war, so
let's say that if we stick to unittest we should use
unittest-style testing with .assert* methods; otherwise (in case
of switching to py.test) we should use Python assertions.

Works for me.  I think some tooling debate is good though.  For
example, I wasn't aware of the parallel py.test / serial unittest
distinction before you mentioned it.
I think the best argument for sticking with unittest is that it's in
the standard library, and I don't think we're doing anything exciting
enough in our testing to justify the bells and whistles of an extra
dependency (which is the same argument I made against using requests
#118).  Tracking another external dependency is fine (like we'll be
doing with DataTables after #134, but I'd rather have stronger
motivation (“sortable tables are much more usable than unsortable
tables”) before adding a given dependency.

A few months have passed and what we see in the test suite is that we often use assert statement and only go back to unittest methods when necessary. This brings a conclusion that we should look into py.test in the future.
However, I don't think anyone would be willing to rewrite >80 tests (well py.test claims to be supporting Django TestCases easily, but we'd need to check). So for now I'm closing this issue.


Perform constant time string comparison when validating signatures

String#== is not safe for the purposes of validating cryptographic
signatures because it enables timing attacks.

@mloughran are you still interested in maintaining this gem, or should we fork and take over?

Thanks @stevegraham. I'm quite happy to keep it @mdpye – would you like me to release a new version with this change?


Use peerDependencies to avoid duplicate dependencies

See codemirror/dev#858.

Closing, figured out that this is not necessary in this package, see https://github.com/codemirror/dev/issues/858#issuecomment-1154725448.


Flatpak Obsidian - On File Modify Not Working

For flatpak obsidian version, the on modify event does not detect changes to xopp files. Does work on appimage version of obsidian.
(this is for the render-inside-obsidian branch)

Seems to be a problem with the DBUS on when using the flatpak on wayland: https://github.com/flathub/md.obsidian.Obsidian/issues/317


My Created Markets should only show SB created Markets

Not seeing any markets in my created markets. Created both sportsbook and non-sportsbook to test

Only seeing sportsbook now which is correct. Closing


Remove custom webpack chunk hash and external manifest plugins

The custom chunk hash plugin currently being used will erroneously yield identical hashes in some cases.
This PR makes the following changes

Remove the custom chunk hash plugin (which should not be required in Webpack 4 anyways)
Remove the custom external manifest plugin. This plugin is currently doesn't work correctly (as a result of Webpack 4), but even if it did, the manifest global variable isn't set anywhere. In any case, it seems using the new Webpack 4optimization.runtimeChunk option (and inlining this chunk) is preferred over external manifest plugins.

We should revisit optimization of bundle splitting/assets/chunking/naming configuration, but for now this PR resolves correctness problems. We will likely want to take a different approach in the future anyways (as part of per-browser bundles).

Yeah, I had trouble reproducing this issue constructively via a simple fixture. I think I could create one if I spent more time working backwards from a production app where I can reproduce this.
That said, bcause this PR just removes custom plugins, in theory we move closer to vanilla webpack and can rely more on webpack test coverage for things isolated to build-related concerns.

!merge


v2.7.25 now requires Go v1.21?

After v2.7.25, our test failed with the following error:
./go/pkg/mod/github.com/sijms/go-ora/v2@v2.7.25/connection.go:101:19: undefined: atomic.Bool
Our Go v1.18.x was running ok with sijms/go-ora/v2 pre v2.7.25
And the current go.mod of sijms/go-ora/v2 says go 1.17.
We tested again with Go v1.21.x and the error message was gone.
Is this unintended bump of Go version?

I should change go version in go.mod

I review the code and no need for atomic package as the field is not sharable
so I change it to bool

return back to bool v2.8.0


Device Tree verification

https://github.com/openbmc/openbmc/issues/421
https://github.com/openbmc/openbmc/issues/629

I dint think we would need this as part of the functional test.. this is more of the unit test..

@gkeishin We need to check all the REST interfaces population, right.

@sivassrr The best way to get answer is to put this question to the development team, if we need anything on this.

@gkeishin yup, As discussed, we thought of having this discussion in our last design interlock. But it was cancel, we can touch base it on Monday.

Device Tree check was requested by development.  And there is a difference between AST2500 and AST2400.  Need to check right things are populated and verification should be done.


add debounce as Event Modifier

What problem does this feature solve?
Add a standard debounce feature on events like input, keyup etc.
With data driven apps 'debounce' functionality is a must for not over-loading the backend.
What does the proposed API look like?
example <input type="text" @input.debounce="ajaxSearchBackend" />

Hello, this was intentionally removed. See #2873 for more details


Fix constructor wording to use allocator_traits<A>::construct

Perhaps find related wording from https://eel.is/c++draft/#containers

Fixed by #293
There should be wording in indirect.general and polymorphic.general that gives enough detail about allocator use (taken from https://eel.is/c++draft/container.requirements.pre)


Simplified Chinese Update

Could you update your branch and fix the changes to en_us? it's causing me to not be able to automerge :(

Here I made a new pr


Min height fix

@robyweb Thank you very much for your support

focus end ?
1.0.8 fix focus Locate last position
Please allow me to extract part of the code to insert video

1.1.0 This function has been implemented, the usage method has been modified https://github.com/stulip/react-native-pell-rich-editor/commit/cde745ce56644b6609906800c00805c496466838


Show Line of Sight Between Geoelements

Description
PR to add a new Kotlin sample "Show_Line_Of_Sight_Between_Geoelements" in Analysis category.
Links and Data
Sample Epic: runtime/kotlin/issues/2932

a vTest Job for this PR has been run

[x] link: https://runtime-kotlin.esri.com/view/all/job/vtest/job/sampleviewer/

What To Review

Review the code to make sure it is easy to follow like other samples on Android
README.md and README.metadata.json files

How to Test
Run the sample on the repo.

Resolved PR conflicts, merging this into v.next


Refresh provenance of global allocator

It would seem nice if Miri could detect an error in the following code:
#![feature(allocator_api, slice_ptr_get)]

use std::alloc::{Allocator, Global, Layout, System};

#[global_allocator]
static A: System = System;

fn main() {
    let l = Layout::from_size_align(1, 1).unwrap();
    let ptr = Global.allocate(l).unwrap().as_non_null_ptr();
    unsafe {
        System.deallocate(ptr, l);
    }
}

That would basically reflect that the global allocator entry points are special magic and cannot be interchanged with directly calling the underlying allocator. (This doesn't catch all possible issue called by the magic of these symbols, e.g. it does not reflect that LLVM can replace heap allocations by stack allocations or even remove them entirely under some circumstances.)
To implement this we'll probably want the __rust_alloc shim to generate new provenance for the allocation (to distinguish it from the underlying allocation generated by System) and __rust_dealloc should undo that transformation. The details are pretty unclear though -- do we have two AllocId with the same address or do we use something more like Stacked Borrows to realize this "stacking" of allocations?
Related discussion: https://github.com/rust-lang/wg-allocators/issues/108.

do we have two AllocId with the same address or do we use something more like Stacked Borrows to realize this "stacking" of allocations?

Given how up in the air these semantics are, I'd suggest doing whatever is simplest that catches this would be best (that sounds like the former, but I have no knowledge of what that actually means, so I cannot say).

It turns out that the semantics to justify the LLVM attributes are even wilder than I thought -- return-position noalias  even applies to pointers that exist before the function call. Basically the returned pointer must not alias with any pointer that ever was or will be used in the program before or after the call.
I assume many custom global allocators will be incorrect under those semantics, and in practice that will work solely because LLVM doesn't know what happens on "the other side" of that allocation call.

There is a "missed UB" aspect here as well: if the allocator registered via #[global_allocator] returns memory that is also reachable from Rust via other means, and if everything happens via raw pointers, we won't currently detect any aliasing violation.


tool to convert README metadata to json.

Includes little python script to parse the READMEs and spit out JSON.  Entire devcontainer-collection.json is auto-generated by the script from the /containers folder, so we can make changes to the source READMEs directly while we stabilize.
cc/ @Chuxel @chrmarti
context/
https://github.com/github/codespaces/issues/6384
https://github.com/github/codespaces/issues/6265
https://github.com/microsoft/vscode-remote-containers/pull/191

retroactively updating the devcontainer-collection.json on release v0.224.2 to allow for easier testing

@edgonmsft  ^


release v1.3.0

:exclamation:

Updated.

Updated.

The patches look good to me. I am running more tests.

Results of my tests:

all distros:
FAIL: TestServiceFile https://github.com/coreos/rkt/issues/2323
Fedora 22/23 without SELinux
no failures (except "all distros")
Fedora Rawhide, with SELinux enabled:
most tests failed: https://github.com/coreos/rkt/issues/2322 (needs to test again without running tests as a systemd service)
Ubuntu 15.10
TestFetch

	rkt_tests.go:214: Error: ExpectRegex didn't find regex 'sha512-[0-9a-f]{32,64}'.
		Output: image: searching for app image coreos.com/etcd
		image: remote fetching from URL "https://github.com/coreos/etcd/releases/download/v2.1.2/etcd-v2.1.2-linux-amd64.aci"
fetch: unexpected EOF=                                         ] 589 KB/5.61 MB  0 B/5.61 MB

Debian 8 (Jessie)
FAIL: TestAPIServiceCgroup https://github.com/coreos/rkt/issues/2363
FAIL: TestRktListCreatedStarted https://github.com/coreos/rkt/issues/2220
CentOS 7:
FAIL: TestAPIServiceCgroup https://github.com/coreos/rkt/issues/2363

Rebased.

Smething about all the dependency bumps?

surely we picked up some bug fixes, etc in the CNI bump? @steveeJ

Added something about docker2aci

Let's polish the CHANGELOG later.

LGTM


old style reduce/aggregate processes in glossary

the (1.0) glossary references some old style process in various places like filter, reduce, aggregate, resample

Thanks for the report, I fixed that.


Prediction with a single thread

I'm trying to do prediction with a single thread. To hack something together, I've modified AutoFlow to take an extra input argument session_config in the constructor. The session is then created using:
storage['session'] = tf.Session(config=tf.ConfigProto(**self.session_config))
Now I've changed the @AutoFlow decorator of predict_f to be:
@AutoFlow((float_type, [None, None]), session_config={"intra_op_parallelism_threads": 1,
                                                      "inter_op_parallelism_threads": 1,
                                                      "use_per_session_threads": True})

But prediction still uses all my cores! Does anyone have any idea what's causing this? Has anyone limited core usage in TensorFlow before?

@alexggmatthews has code to limit core usage, and I recall there were some difficulties.

@markvdw I'm assuming this issue is out of date now; if for some reason there's still something to be done please re-open.


Use class cache instead of ray actor as a more scalable approach

When there are too many metrics being emitted, actor dies due to a very high load it gets. This commit will aim to use a separate feature that allows us to configure metrics while not using actors.

Did you test this?

Did you test this?

Yes, tested it. Scale testing in progress.

Seeing all the emf logs in the log group without any issues.


Update README.md

fix typo availble --> available

I just completed  CLA verification.  I'm trying to submit pull request again.


Fix formatting

This is trying to address #237. I turned on formatting checking, and I also reformatted all files. There is still thousands of warnings being issued. Lots of them make sense and I think they do improve code readability. Others we can probably suppress.
The question is whether we want to go down this route to fix/improve formatting and make it consistent in the long run, or not. There is quite a lot of work left to fix all/most of the warnings, which is why I created this branch in the main repo so that everyone can contribute :).

I did two configuration changes.

Enable StyleCop globally in one place (the file Directory.Build.props).
Put the exclusion comments for scanner/parser into Copyright.frame. Otherwise they would not survive a regeneration.

Some thoughts.

If we go for this, I think that any reformatting needs to be merged rather quickly. Otherwise it will be hard to resolve merge conflicts (we already have some now).
We will lose some value of the Git history (similar to a past commit that touched almost all files to fix line endings), and going piece by piece (either in terms of files or types of warning we enable) will be worse than a single commit. On the other hand, I'm not sure if fixing 27251warnings quickly and at once is realistic.
Did you do all the already applied fixes manually? Or is there some automation support?
The reason why CI is currently failing is the following :)The job exceeded the maximum log length, and has been terminated.

Yeah, git blame/history won't work as well any more. So there are trade-offs here.
I did all the fixes automatically using Rider IDE, which I think uses the same tool under the hood. But it doesn't fix everything.
I think the way to do this (if we want to go that route) is to suppress all the warnings we still have (there must be a way to do that), and then merge whatever we have. That way we will catch all future style issues going forward and we will avoid merging them.
Once that is done, then we slowly patch up other warnings one by one until we are happy.
Thoughts?

I don't understand the issue with git blame/history.  Specifically, what will not work?

Since these massive updates touch a lot of lines of code, many git blames will land on this large commit. I think one can usually get past that by repeating git blame, and all is good. But I also vaguely remember that I think that sometimes I did not manage to do that in SMACK, where we did similar major reformatting at some point several years ago.
In short, I don't think it is a major problem, but more of an annoyance. Maybe @bkragl knows more?

I looked a bit at the huge number of warnings being issued by Style Cop. There is a lot of unnecessary drama going on there.  May I ask what are the specific pet peeves of the folks interesting this cleanup.  Mine are the following:

inconsistent indentation
inconsistent naming of fields, variables, and methods
Consistent positioning of braces for blocks of code would be good to have but less of a concern than the two issues above.

We could simply take the union of the concerns expressed here, fix things up, and land the PR ASAP.  Later on, when somebody cares about the consistency of something else, they can initiate it.

I like some of the other suggestions as well. But yeah, the ones you listed are the most important to me as well.
So I will try to figure out how to turn on checking of just these rules, and then merge it in. I'll probably do that later tonight.

@shazqadeer and @bkragl : I got this into a reasonable stage. I reformatted everything and I have StyleCop up and running. There are a bunch of rules I had to disable, and so I am not totally sure what is being checked right now. I will slowly enable the important ones as I keep fixing the code.
Honestly, I am not totally sure this is the right move, but hopefully it'll help us to maintain code consistency in the long run.

I am in the middle of some other PRs. Should  I wait until your PR lands?

I just want to say that I am supportive of the change.  This makes for a good starting point for other highly-overdue code refactoring and clean up.

I was just about to write the same thing. While StyleCop is not perfect and has some issues (e.g., do-while is a problem), based on my experience so far, it does help with maintaining consistency. Also, code reformatting was a step in the right direction as well I think. So I say we merge this in.
People with outstanding pull requests will have to put some effort into merging.

@bkragl Done and done. Thanks!

@zvonimir :  Are you close to landing this?  I am blocked behind you.


Subscription dies when an unchecked exception is thrown in the message handler

Consider this code:
nats.subscribe(
    "someTopic",
    new MessageHandler()
        {
            @Override
            public void onMessage(Message message)
            {
                someOperation(message); // This throws an unchecked exception for some reason
            }
        }
    );

When someOperation(...) throws an unchecked exception, the subscription dies and no further messages are delivered to the handler.
The expected behaviour would be that the message handler keeps receiving messages.

This has been already addressed in master: https://github.com/nats-io/java-nats/blob/master/src/main/java/io/nats/client/ConnectionImpl.java#L1406
There are plans to have a release soon.

Ah ok. I was testing this on version 1.0. Just ignoring it seems like a bad idea, although processing continues, your messages would still be disappear and you'd have no idea why. Wouldn't it be better if the exception was logged or at least t.printStackTrace()?

It's a library, so logging may not mean anything (or not be wise) depending on how the library is used. I think that ignoring user level exceptions at the library level is perfectly fine. If the user is concerned that some code he/she calls inside the message callback may throw an exception, then he/she should catch it and do appropriate actions based on the application logic.

I agree with @kozlovic.  While ignoring exceptions and dropping messages can cause some confusion during development, how to handle those exceptions is entirely application dependent.

Perhapss rethrow it as a checked exception then?

Not sure what you are asking here. The issue you reported is that your message handler is not handling an exception that some code you invoke may throw. As we explained, the current code in master will ignore all exceptions thrown by the user so that dispatching of other messages continues. If you want to catch exception thrown by your code you should catch it.


xmlbeans plugin doesnt work with java9

[INFO] --- xmlbeans-maven-plugin:2.3.3:xmlbeans-test (default) @ dozer-core ---
warning: [options] bootstrap class path not set in conjunction with -source 1.4
error: Source option 1.4 is no longer supported. Use 1.6 or later.
error: Target option 1.4 is no longer supported. Use 1.6 or later.
https://github.com/DozerMapper/dozer/issues/555

https://github.com/DozerMapper/dozer/issues/321


fix CVEs

 C:\Code\alba\src> dotnet restore
    C:\Code\alba\src\IdentityServer.New\IdentityServer.New.csproj : error NU1902: Warning As Error: Package 'Microsoft.IdentityModel.JsonWebTokens' 6.10.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-59j7-ghrg-fj52 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\IdentityServer.New\IdentityServer.New.csproj : error NU1902: Warning As Error: Package 'Microsoft.IdentityModel.JsonWebTokens' 6.10.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-8g9c-28fc-mcx2 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\IdentityServer.New\IdentityServer.New.csproj : error NU1902: Warning As Error: Package 'System.IdentityModel.Tokens.Jwt' 6.10.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-59j7-ghrg-fj52 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\IdentityServer.New\IdentityServer.New.csproj : error NU1902: Warning As Error: Package 'System.IdentityModel.Tokens.Jwt' 6.10.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-8g9c-28fc-mcx2 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\NUnitSamples\NUnitSamples.csproj : error NU1902: Warning As Error: Package 'Microsoft.IdentityModel.JsonWebTokens' 6.10.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-59j7-ghrg-fj52 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\NUnitSamples\NUnitSamples.csproj : error NU1902: Warning As Error: Package 'Microsoft.IdentityModel.JsonWebTokens' 6.10.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-8g9c-28fc-mcx2 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\NUnitSamples\NUnitSamples.csproj : error NU1902: Warning As Error: Package 'Microsoft.IdentityModel.JsonWebTokens' 6.15.1 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-59j7-ghrg-fj52 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\NUnitSamples\NUnitSamples.csproj : error NU1902: Warning As Error: Package 'Microsoft.IdentityModel.JsonWebTokens' 6.15.1 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-8g9c-28fc-mcx2 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\NUnitSamples\NUnitSamples.csproj : error NU1902: Warning As Error: Package 'System.IdentityModel.Tokens.Jwt' 6.10.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-59j7-ghrg-fj52 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\NUnitSamples\NUnitSamples.csproj : error NU1902: Warning As Error: Package 'System.IdentityModel.Tokens.Jwt' 6.10.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-8g9c-28fc-mcx2 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\NUnitSamples\NUnitSamples.csproj : error NU1902: Warning As Error: Package 'System.IdentityModel.Tokens.Jwt' 6.15.1 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-59j7-ghrg-fj52 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\NUnitSamples\NUnitSamples.csproj : error NU1902: Warning As Error: Package 'System.IdentityModel.Tokens.Jwt' 6.15.1 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-8g9c-28fc-mcx2 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\WebAppSecuredWithJwt\WebAppSecuredWithJwt.csproj : error NU1902: Warning As Error: Package 'Microsoft.IdentityModel.JsonWebTokens' 6.25.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-59j7-ghrg-fj52 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\WebAppSecuredWithJwt\WebAppSecuredWithJwt.csproj : error NU1902: Warning As Error: Package 'Microsoft.IdentityModel.JsonWebTokens' 6.25.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-8g9c-28fc-mcx2 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\WebAppSecuredWithJwt\WebAppSecuredWithJwt.csproj : error NU1902: Warning As Error: Package 'System.IdentityModel.Tokens.Jwt' 6.25.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-59j7-ghrg-fj52 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\WebAppSecuredWithJwt\WebAppSecuredWithJwt.csproj : error NU1902: Warning As Error: Package 'System.IdentityModel.Tokens.Jwt' 6.25.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-8g9c-28fc-mcx2 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\Alba\Alba.csproj : error NU1902: Warning As Error: Package 'Microsoft.IdentityModel.JsonWebTokens' 6.10.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-59j7-ghrg-fj52 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\Alba\Alba.csproj : error NU1902: Warning As Error: Package 'Microsoft.IdentityModel.JsonWebTokens' 6.10.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-8g9c-28fc-mcx2 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\Alba\Alba.csproj : error NU1902: Warning As Error: Package 'Microsoft.IdentityModel.JsonWebTokens' 6.15.1 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-59j7-ghrg-fj52 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\Alba\Alba.csproj : error NU1902: Warning As Error: Package 'Microsoft.IdentityModel.JsonWebTokens' 6.15.1 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-8g9c-28fc-mcx2 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\Alba\Alba.csproj : error NU1902: Warning As Error: Package 'Microsoft.IdentityModel.JsonWebTokens' 7.0.3 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-59j7-ghrg-fj52 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\Alba\Alba.csproj : error NU1902: Warning As Error: Package 'Microsoft.IdentityModel.JsonWebTokens' 7.0.3 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-8g9c-28fc-mcx2 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\Alba\Alba.csproj : error NU1902: Warning As Error: Package 'System.IdentityModel.Tokens.Jwt' 6.10.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-59j7-ghrg-fj52 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\Alba\Alba.csproj : error NU1902: Warning As Error: Package 'System.IdentityModel.Tokens.Jwt' 6.10.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-8g9c-28fc-mcx2 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\Alba\Alba.csproj : error NU1902: Warning As Error: Package 'System.IdentityModel.Tokens.Jwt' 6.15.1 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-59j7-ghrg-fj52 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\Alba\Alba.csproj : error NU1902: Warning As Error: Package 'System.IdentityModel.Tokens.Jwt' 6.15.1 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-8g9c-28fc-mcx2 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\Alba\Alba.csproj : error NU1902: Warning As Error: Package 'System.IdentityModel.Tokens.Jwt' 7.0.3 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-59j7-ghrg-fj52 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\Alba\Alba.csproj : error NU1902: Warning As Error: Package 'System.IdentityModel.Tokens.Jwt' 7.0.3 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-8g9c-28fc-mcx2 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\Alba.Testing\Alba.Testing.csproj : error NU1902: Warning As Error: Package 'Microsoft.IdentityModel.JsonWebTokens' 6.25.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-59j7-ghrg-fj52 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\Alba.Testing\Alba.Testing.csproj : error NU1902: Warning As Error: Package 'Microsoft.IdentityModel.JsonWebTokens' 6.25.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-8g9c-28fc-mcx2 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\Alba.Testing\Alba.Testing.csproj : error NU1902: Warning As Error: Package 'Microsoft.IdentityModel.JsonWebTokens' 7.0.3 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-59j7-ghrg-fj52 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\Alba.Testing\Alba.Testing.csproj : error NU1902: Warning As Error: Package 'Microsoft.IdentityModel.JsonWebTokens' 7.0.3 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-8g9c-28fc-mcx2 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\Alba.Testing\Alba.Testing.csproj : error NU1902: Warning As Error: Package 'System.IdentityModel.Tokens.Jwt' 6.25.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-59j7-ghrg-fj52 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\Alba.Testing\Alba.Testing.csproj : error NU1902: Warning As Error: Package 'System.IdentityModel.Tokens.Jwt' 6.25.0 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-8g9c-28fc-mcx2 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\Alba.Testing\Alba.Testing.csproj : error NU1902: Warning As Error: Package 'System.IdentityModel.Tokens.Jwt' 7.0.3 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-59j7-ghrg-fj52 [C:\Code\alba\src\Alba.sln]
    C:\Code\alba\src\Alba.Testing\Alba.Testing.csproj : error NU1902: Warning As Error: Package 'System.IdentityModel.Tokens.Jwt' 7.0.3 has a known moderate severity vulnerability, https://github.com/advisories/GHSA-8g9c-28fc-mcx2 [C:\Code\alba\src\Alba.sln]

can we get a release of this. to avoid transitive CVEs in consuming projects

can we get a release of this.

There's still a few issues queued up for v8 I'd like to see done first, I'll look at getting a release out later in the week.
I exclude test projects from scanning tools to avoid this issue though.


Doesn't work under pipenv

The login UI doesn't work under pipenv (the officially recommended application dependency management tool).
I think it has to do with Pipenv running pip in subprocesses and hiding the stdout/stderr streams. This broke our development workflow.
Workaround

generate a Personal Access Token with Packaging Read permission manually
store in OS keyring (secret service on ubuntu, keyring on macos, credential manager on windows)
use a shell script with-artifacts.sh|.ps1 to load the PAT from the keyring and expose it as an environment variable ARTIFACTS_TOKEN for the duration of a single command invocation
use environment variable interpolation in your Pipfile to load the PAT from the environment when calling with-artifacts pipenv lock|sync

[[source]]
url =<EMAIL_ADDRESS>verify_ssl = true
name = "artifacts"

We have had new devs that just started and the new UI workflow removed the step where they could easily generate a PAT.
Using keyring and artifacts-keyring with pipenv breaks.
We already have to run the following as separate steps:
pipenv shell
pipenv install

This loads in our .env that loads in our PAT so our Azure Artifacts URL will be valid for that source.
With pipenv it needs to be able to resolve our Azure Artifacts URL to extract dependency information.
But it can't do that if artifacts-keyring needs to already be installed.
Since the dependencies can not be resolved, a lock file can't be created and nothing gets installed.
The following documentation has screenshots on where the Personal Access Tokens can still be found and generated for the older workflow.
Microsoft Docs: use personal access tokens to authenticate

Just want to point out that storing PATs in .env/plain text files or environment variables is a security risk and should be avoided as described in the workaround in the opening post: once attackers do get access to your system, your environment variables and .env files will be among the first things they steal from you as they are likely to contain secrets.

Thanks for pointing that out @Korijn! No one wants to be the person that left the front door key under the mat.
Just so I'm clear (and we can turn this into a learning opportunity for myself and others) what would an example of with-artifacts.sh look like?
I'm presuming that you have pipenv, keyring and artifacts-keyring  installed as tools in your system/user python?
You then have the with-artifacts.sh script as a boilerplate helper script in each repo?

ok interestingly easy:
Set Credentials
Run the CLI tool to install the creds into the Windows Credential Manager
python -m keyring set 'pkgs.dev.azure.com/myorganization' username
Password for 'username' in 'pkgs.dev.azure.com/myorganization':

Fetch Credentials
then the respective helper script to fetch the credentials from keyring
with-artifacts.sh
PAT=$(python -m keyring get 'pkgs.dev.azure.com/myorganization' username)

or with-artifacts.bat
FOR /F "tokens=* USEBACKQ" %%g in (`python -m keyring get pkgs.dev.azure.com/myorganization username`) do (SET "PAT=%g")

Reference:

Stackoverflow: How to set commands output as a variable in a batch file

Here's our approach on Linux and macOS. It is not dependent on Microsoft's keyring tool but instead relies on the OS keyring, meaning you don't need to install anything into your system python environment.
It's much more involved on Windows since there aren't any native keyring CLI tools available, we wrote a library in C# and PowerShell and I would rather not share it.
Linux Setup
Install prerequisites

We'll need the command line tool secret-tool to access the OS keyring from CLI so install it with apt install libsecret-tools

Configure your shell

Copy dev.sh (see below) to a folder you like and make it executable with chmod +x dev.sh
Add to your shell's aliases (e.g. ~/.bash_aliases) the following line and
customize the path: alias env-dev='env $(~/PATH/TO/dev.sh)'
Reload your shell for the alias to become available (e.g. . ~/.bashrc)

dev.sh:
#!/bin/bash
TOKEN=$(secret-tool lookup secret MY_PAT)
echo MY_PAT=$TOKEN

Configure the credential

Create a Personal Access Token (PAT) on Azure DevOps and give it Packaging -
Read permission

You can do that here: https://dev.azure.com/<organization>/_usersSettings/tokens

Add the key to your keyring under the name MY_PAT and set the
password (username is irrelevant but cannot be blank; can be anything) using
the secret-tool command line: secret-tool store --label=MY_PAT secret MY_PAT

Make sure to refresh the PAT when it expires!
Profit
Now you can prefix any command with env-dev to expose MY_PAT as an environment variable just for the duration of that
command. Typically that will only be necessary for commands such as pipenv lock, pipenv install and pipenv sync.
MacOS Setup
MacOS ships with a keyring CLI tool security built-in so there are no prerequisites to install. You also don't need to add the secret via the CLI tool, you can just use the OS keyring UI. Here's dev.sh for macOS:
#!/bin/bash
TOKEN=$(security find-generic-password -s MY_PAT -w)
echo MY_PAT=$TOKEN

Thanks for the input @neozenith. However, python -m keyring get pkgs.dev.azure.com/<organization> <username> returns the azure password and not the artifacts PAT. I don't see how this can be used to generate a valid url for pipenv. Also, the solution @Korijn proposed won't work in my case because my organization uses Windows machines for developers.

@rinman24 My explanation wasn't particularly clear and I see now how it reads that way.
If you already have a password for a given username for that website already stored in the Windows Credential Store that way then yeah it returns the password.
I used the website as a meaningful key; although the username could be anything like artifact_pat, and then the credential that is stored, is the PAT.
Then exporting it from the credential store as an environment variable allows for pipenv to perform string interpolation.
So if we export the PAT to ARTIFACTS_TOKEN environment variable we can add the following to our Pipfile:
[[source]]
url =<EMAIL_ADDRESS>verify_ssl = true
name = "artifacts"

Whilst in a pipenv shell this ARTIFACTS_TOKEN must be available for the URL to resolve.
Then pipenv lock can extract the version information it needs about all packages to start the lock resolving algorithm.
Once versions are resolved, then and only then do packages get downloaded.
Running any of sync, update and install will actually check the lock status as far as I know. So if you can't lock because the URL doesn't contain the PAT, pipenv gets stuck.
References

https://pipenv-fork.readthedocs.io/en/latest/advanced.html#injecting-credentials-into-pipfiles-via-environment-variables
https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page

Thanks, @neozenith . The clarification helped. I understand everything except setting the PAT. We had previously used the PAT in an environment variable in .env and we had to pipenv --three, pipenv shell,l and then pipenv install as you had mentioned before. Still, I cannot seem to get the PAT set for artifacts, I keep getting the password for my username returned, even if I switch username to artifact_pat. Perhaps I am misunderstanding how the keyring works.
When you said:

I used the website as a meaningful key; although the username could be anything like artifact_pat, and then the credential that is stored, is the PAT.

did you mean to run
python -m keyring set 'pkgs.dev.azure.com/myorganization' artifact_pat
Password for 'username' in 'pkgs.dev.azure.com/myorganization':

and then
python -m keyring get 'pkgs.dev.azure.com/myorganization' artifact_pat

to access the PAT? This still returns my password, unless this is also the PAT.

Thanks for the input @neozenith. However, python -m keyring get pkgs.dev.azure.com/<organization> <username> returns the azure password and not the artifacts PAT. I don't see how this can be used to generate a valid url for pipenv. Also, the solution @Korijn proposed won't work in my case because my organization uses Windows machines for developers.

It does work as I mentioned before, the script required for Windows is just a lot bigger. Anyway, I decided to share it anyway in a gist, because it's so big. Hope it's useful for you all. https://gist.github.com/Korijn/6b0e444e7c131680dacdd397f8574c50

Thanks @neozenith  and @Korijn. Both very helpful!

This workaround doesn't seem to work for me anymore (PAT in environment variable). If I try the index URL directly with curl the response is 404 with a very strange message in the body:
This functionality is currently not available.
Example:
curl<EMAIL_ADDRESS>

You might be dealing with the new project scoped feeds with also have a {project} part in the URL...

Oh wow... it's fine now. I was running an old version of pipenv on this machine. :man_facepalming:

@LTArnas I'm glad you figured it out. For reference, we are currently still using this workaround without any issues.

Anyone else experienced this workaround failing recently?

Has anyone else experienced this workaround failing recently?

Not yet...

For the sake of joined-up-ness, note that I think this issue is the same as https://github.com/pypa/pipenv/issues/4074.
Unless more qualified people than me think differently, I believe this is really pipenv's problem to solve, not Microsoft's.

Hey,
Closing due to inactivity, please reopen this if it is still an issue.

I managed to get this working today =]
Be sure to replace the url:
#powershell
python -m pip install --user azure_devops_artifacts_helpers artifacts-keyring
[Environment]::SetEnvironmentVariable("VIRTUALENV_SEEDER", "azdo-pip", "Machine")
[Environment]::SetEnvironmentVariable("PIP_INDEX_URL", "https://pkgs.dev.azure.com/XXXXX/_packaging/YYYYY/pypi/simple/", "Machine")

Open a new powershell/cmd window so those environment variables get loaded and pipenv install should work. It does for me at least, let me now if it doesn't and I'll try to figure out wat else I did during all the trial and error.


Missing xpack.apm.ui.enabled in kibana_vars

Documented here: https://www.elastic.co/guide/en/kibana/6.2/apm-settings-kb.html
The current kibana_vars white list has xpack.apm.enabled but not xpack.apm.ui.enabled

@sqren, should the documentation be updated to reflect using xpack.apm.enabled?

Are we talking about two different things?
xpack.apm.enabled
It is an xpack-wide feature that users can disable a plugin via xpack.<plugin-name>.enabled. If other plugins document this we should too.
xpack.apm.ui.enabled
This was a hack requested by cloud. We considered adding it to the whitelist but decided against it. It is my understanding that we can remove this setting in 6.4 since APM will be officially supported on Cloud at this time.
(although people might still want to hide APM in the menu - I honestly don't know)

Well the docs and the whitelist are not on sync.
The docs describe apm.ui.enabled but not apm.enabled. The whitelist is the opposite.
That's a pretty terrible experience for docker users.
I have no opinion on which option(s) should be recommended to users, but let's at least be consistent.

Again, I think it makes sense to document xpack.apm.enabled so it matches the whitelist.
I'm not really sure what the future is for xpack.apm.ui.enabled. If we want to keep it, it should be added to the whitelist, if not it should be removed from the docs. That would bring consistency, right?
@joegallo Is xpack.apm.ui.enabled still needed by cloud to hide the APM menu item?

@joegallo Is xpack.apm.ui.enabled still needed by cloud to hide the APM menu item?

Yes.

@joegallo Okay, thanks!


Removed reference to travis in readme

Version 1.0.17 removed .travis.yml and now the build status is broken.
If travis is reimplemented then the link is to https://app.travis-ci.com/github/yjs/y-prosemirror

Right, thanks!


Create tasks to printout AST representation

This should help developers willing to add support for different specification formats or generate code in different languages/frameworks

Implemented


Log the first gRPC request and response object

Motivation:
Instead of logging no parameters and return values, we can keep the
first request and response object in a gRPC call, so that a user gets at
least some information about the call.
Modifications:

Defer both request and response content logging for gRPC
Set the first request/responseContent()
Add LoggingService to GrpcServiceServerTest so that a dev can check if
request/responseContent is recorded correctly

Result:

More information in gRPC RequestLog

Adding more test cases..

I have relaxed some test cases because a gRPC RequestLog may not have RpcRequest or RpcResponse depending on when an error occurs, and it's not always easy to control the timing precisely.

Let me re-run the builds a few more times just in case I broke anything.


TP2000-519: Fix measure condition link

TP2000-519: Fix measure condition link

Why

Measure condition get_url used the measure condition sid to create the url for the linked measure and this was causing a 404

What

Use the dependent_measure sid instead when generating the url

Codecov Report
Base: 93.91% // Head: 93.91% // Decreases project coverage by -0.00% :warning:

Coverage data is based on head (e0c8ae6) compared to base (b940192).
Patch coverage: 100.00% of modified lines in pull request are covered.

:exclamation: Current head e0c8ae6 differs from pull request most recent head add06ee. Consider uploading reports for the commit add06ee to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #686      +/-   ##
==========================================
- Coverage   93.91%   93.91%   -0.01%
==========================================
  Files         343      343
  Lines       22351    22358       +7
  Branches     1703     1703
==========================================
+ Hits        20992    20997       +5
- Misses       1045     1046       +1
- Partials      314      315       +1

Impacted Files
Coverage Δ

common/tests/test_models.py
99.11% <100.00%> (+<0.01%)
:arrow_up:

measures/models.py
96.47% <100.00%> (+0.05%)
:arrow_up:

importer/taric.py
78.43% <0.00%> (-1.31%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


只检查特定ApplicationContext

for #4

https://github.com/funkygao/cp-ddd-framework/commit/43ecc42103f17402cb5fbbd38d3264f9d28d3dde

thanks @carllhw


Accessing numpy array from a Tensor object using dataset map

I am trying to access the numpy array from a tensor object that is processed with  https://www.tensorflow.org/api_docs/python/tf/data/Dataset#map.
I get the error: AttributeError: 'Tensor' object has no attribute 'numpy'
When I try to access the tensor as: np_array = tensor.numpy()
While if I use: dataset.take(n), i am able to access the numpy array.
For more clarity on the situation I am facing, here is a short reproducible example of the error in a google colab:
https://colab.research.google.com/drive/13ectGEMDSygcyuW4ip9zrWaHO3pSxc3p?usp=sharing
Tensorflow version: 2.4.1

I have resovled the issue. The answer is that I cannot access .numpy() inside a .map() function since .numpy() is Python code not pure TensorFlow code. I need to wrap my python function with https://www.tensorflow.org/api_docs/python/tf/py_function in order for it to work.
Happy to close this ticket.


Make connection errors between services more verbose

This is a feature request for the backend.

What do you want to do?

Setup a private TTN

What steps did you take?

Basically this: https://github.com/lobaro/ttn-private-network/issues/1

What went wrong or what is missing?

I missed a port in the ttn.yml configuration of the broker
I got the following error when turning on "debug logs" for the broker.
DEBUG grpc: addrConn.createTransport failed to connect to {networkserver.local.thethings.network 0  <nil>}. Err :connection error: desc = "transport: Error while dialing dial tcp: address networkserver.local.thethings.network: missing port in address". Reconnecting...

Even worse, the handler did not started because the broker did not and subsequent errors were leading to the handler, but the miss configuration was inside the handler.
I would love to see any kind of connection errors / retries inside the INFO or ERROR level logs.

This is not going to get fixed in V2 anymore.


Add message option to some assert* functions.

This will pass the message to the PHPUnit assertion to receive a custom error message on failure.
I found out that I wanted to set a custom message on an assertion and that it wasn't supported, this was the reason to create this PR.
The message field is add to:

assertCount and assertJsonCount
assertExact and assertExactJson
assertSimilar and assertSimilarJson
assertMissingPath and assertJsonMissingPath
assertPath and assertJsonPath
assertSubset

For the assertions that had a custom message inside I tried to keep that if the message isn't provided.
I didn't found any test for this functions where I could add the message. If I missed that or anything else: please let me know.

Wouldn't we loose the default messages with this change?

An empty message is the default for PHPUnit so you keep the default working.

Thanks for your pull request to Laravel!
Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.
If possible, please consider releasing your code as a package so that the community can still take advantage of your contributions!
If you feel absolutely certain that this code corrects a bug in the framework, please "@" mention me in a follow-up comment with further explanation so that GitHub will send me a notification of your response.


Does aliyun-cli support upload SSL certificate to OSS bucket?

Just like aliyun slb UploadServerCertificate

Just like aliyun slb UploadServerCertificate

Hi, this feature is already supported in lastest version. We recommand that you download the lastest version of cli and try again.
Thank you for your attention to AliCloud CLI Project!

Just like aliyun slb UploadServerCertificate

Hi, the new features related to oss products are not part of CLI project now. If you have some other questions, please contact us.
Thank you for your attention to AliCloud CLI Project!


Resolve failed when the same name file and directory

Reproduction: https://github.com/sxzz/esbuild-esm-loader-issue
src/
├── index.ts
├── utils        # this is a directory
└── utils.ts

node --loader @esbuild-kit/esm-loader src/index.ts

Error [ERR_UNSUPPORTED_DIR_IMPORT]: Directory import '/path/esbuild-esm-loader-issue/src/utils' is not supported resolving ES modules imported from /path/esbuild-esm-loader-issue/src/index.ts
    at __node_internal_captureLargerStackTrace (node:internal/errors:465:5)
    at new NodeError (node:internal/errors:372:5)
    at finalizeResolution (node:internal/modules/esm/resolve:433:17)
    at moduleResolve (node:internal/modules/esm/resolve:1009:10)
    at defaultResolve (node:internal/modules/esm/resolve:1218:11)
    at i (file:///path/esbuild-esm-loader-issue/node_modules/.pnpm/@esbuild-kit+esm-loader@2.1.0/node_modules/@esbuild-kit/esm-loader/dist/index.js:87:17)
    at ESMLoader.resolve (node:internal/modules/esm/loader:580:30)
    at ESMLoader.getModuleJob (node:internal/modules/esm/loader:294:18)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:80:40)
    at link (node:internal/modules/esm/module_job:78:36) {
  code: 'ERR_UNSUPPORTED_DIR_IMPORT',
  url: 'file:///path/esbuild-esm-loader-issue/src/utils'
}

If rename or remove src/utils, it works.
IMHO, the problem caused by here.
https://github.com/esbuild-kit/esm-loader/blob/0d64195031bb599034be6c2d29427efd4d9d6334/src/loaders.ts#L79-L81

Hmm, I'm not sure if this is a bug.
When you import a path ./utils, and it explicitly matches a directory name, I think that should take precedence over an implicit file name match.
Besides, since this is how Node.js resolves it (rename your files to .js and run node src/index.js), changing this behavior will introduce a breaking change to how native ESM resolves files.

I think a better way is to be consistent with ts-node, esbuild and esmo (<0.14.x).

If you try to click the import path with ctrl key, the VSCode will jump to src/utils.ts. We should respect resolution algorithm of TypeScript.

esbuild Demo
> esbuild src/index.ts --bundle

(() => {
  // src/utils.ts
  var foo = "bar";

  // src/index.ts
  console.log(foo);
})();

Also, native ESM has no default extension and resolve index, so changing .ts to .js directly will not work. (even if the utils folder does not exist)

To use Node.js's classic resolution algorithm, you can use the --experimental-specifier-resolution=node flag:
$ node --loader @esbuild-kit/esm-loader --experimental-specifier-resolution=node src/index.js
(node:34643) ExperimentalWarning: --experimental-loader is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
(node:34643) ExperimentalWarning: The Node.js specifier resolution flag is experimental. It could change or be removed at any time.
bar

Or with tsx:
$ npx tsx --experimental-specifier-resolution=node src/index.js
bar

With this flag, users have a way to toggle between both resolution algorithms. If we override the default behavior to force Node's classic resolution algorithm, users will be limited to one behavior. For this reason, I don't think we should change it.
I agree we should try to resolve /index.js instead of /index though. Hasn't happened yet but it's bound to. Happy to accept a PR to fix that.


Update Readme

part of #8762

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


[QUESTION] is there a way to get the number of likes and retweets for given tweet within a given period?

Just had a quick question here: Is there a way, using twint, to get the number of likes and retweets for given tweet within a given period?

The get-retweets feature is currently broken
Anyway you should get the tweets first, and then filter them out
Currently a solution where you specify the date range and get the tweets that match that request, it's not available
We could do no more than filter them out while scraping, so something like automating the filtering-out process. In this case, if you would be interested in the retweets of a specific user in the year 2016, you  would still have to get every-single-tweet until that year.


Spectrum Native Fee

DEV-450

I checked swapBuy, swapSell, swap contracts - tree templates don't depend on boolean constants

I checked swapBuy, swapSell, swap contracts - tree templates don't depend on boolean constants


New object syntax

Related to #766

I will update this PR with the new method invocation syntax once we have made a decision on that.

I will update this PR with the new method invocation syntax once we have made a decision on that.

Can we actually do them separately? This diff is still good even without that right?

(I notice there's some merge conflicts)

@jordwalke

Rebased on the latest master
I still need to add extra test cases
Not sure about unifying with class_instance_type, it's not clear to me what we would gain from it.

This PR is ready for review.

Might be nice to simultaneously get some documentation update for http://facebook.github.io/reason/ on the new syntax

If so, then we might want to put it somewhere deep like in the "Diving Deeper" section because the object syntax is likely to change much (even though object type syntax might not much).

@sgrove @jordwalke
As requested I've added objects documentation in the "Diving Deeper" section.

Rebased
cc @chenglou @jordwalke

This looks pretty nice. I like the shorter names for methods.
I'm a little bit concerned about putting the '.' at the end of the block though. This would mean we couldn't use that information to determine the parsing context in any of the textmate based plugins (atom, sublime, vscode) because they can't do backtracking. So we would have to try to do some approximate parsing of both record and object types at the same time which could be messy especially as the syntax changes more in the future.
I would suggest changing it to where the syntax is {. and {... Not having a space between { and . there also makes the parsing for the highlighting much easier and more accurate.
Another alternative though that I think might be more visually distinct would be to use {= for the closed objects and {> for the open ones. This might work thematically because of similarity to the notation for polymorphic variants.
Thoughts?

Those are great points, @freebroccolo. Let's also consider how that would work with some kind of syntax for record types that could be inherited (not that we have a working implementation, but it would be a useful feature). Something like:
type point = {
  ...point2D,
  z: int
};

Which matches the record spread syntax.
Perhaps .. could be used for objects?
type hasZ 'a = {.., z: int} as 'a

And we can later add sugar for that common pattern to be written as:
type hasZ 'a = {..'a,  z: int};

Closed objects types could be:
type hasZ = {. z: int};

(Though those are less common, so I don't mind them looking a little strange.
I recall one reason why I preferred the .. at the end of the record was because the following looks a little strange:
type hasZ 'a = {.., z: int} as 'a

With a comma after the .., and omitting the comma looks confusing
type hasZ 'a = {.. z: int} as 'a

Because it looks like you're extending z, instead of appending z.

I'm growing more fond of the {= and {> syntax for several reasons:

.. is too ambiguous like mentioned before
{= and {> have a more heavy feeling which I like, while also being more descriptive (all subjective of course). And I don't think it clashes with existing syntax concepts.

@jordwalke those suggestions look pretty good to me. I agree that this case looks a bit wierd:
type hasZ 'a = {.. z: int} as 'a

But with the comma after the .. I don't think it looks so bad, although I would still prefer the sugared version instead of the { … } as 'a version.
I don't feel too strongly about which tokens are chosen at the moment but I do think that @SanderSpies makes a good point about ... The fact that we have ... for one part in the syntax and .. or . for a different part seems potentially confusing. I think it would be ideal if we could just stick to ... but I guess that is problematic because we use curly brackets for both objects and records now.
So as far as I understand the current issues, I might suggest trying a slightly different approach. What if we change the syntax to something like this?
// open
type hasZ 'a = #{ ...'a,  z: int };

// closed
type hasZ = #{ z: int };

The advantages of this syntax are that it's still lightweight and looks close to the record syntax but it allows us to reuse the ... token without ambiguity. It also doesn't require that the ... be connected to the opening { just to be easier to handle for syntax highlighters. And hopefully the # is suggestive of intent since # is used for method invocation.

I like @freebroccolo's suggestion the best. Though I'm wondering if we could push it further and allow implicit open objects thanks to the # in front.
Something like type bla = #{foo: int}; would really mean type bla = #{...'a, foo : int};.
I don't really know how the ...'a can be used, but I'm guessing that you can restrict that "rest" to be a "concrete type" rather than "abstract" like 'a? If so, then we definitely should support that syntax.

There is another advantage to using the type hasZ 'a = #{ ...'a,  z: int } syntax that I did not mention in the previous post. If we also used #{ for object terms, this would allow us to elide the pub and reuse the syntax for record fields. Maybe we would want to adjust it a little still but in any case not having to write pub could be nice I think.

@freebroccolo I believe this PR already comes close to what you want (by mixing objects and records). I think we should do this in another PR though.

@bsansouci: In type hasZ 'a = #{ ...'a, z: int } you can think of the 'a as a type variable representing representing "the rest of the rows not named. That's a bit of an over-simplification, because it actually represents the total set of rows. Most of the time we just use it as "the rest of the rows". What's really going on is the following: type hasZ 'a = {...'otherRows, z:int} as 'a. That is, there *is* a hidden variable for "and any other rows", but you can't bind it to a variable.  So therefore, you have to say "okay, and that *whole* set of rows should be considered 'a`, and we'll just be polymorphic in terms of the whole set, which is just as good. In Reason, we can simply make an over-simplification of that in the syntax because this is really the most common use case.
Regardless of the syntax, it allows you to be explicitly polymorphic in terms of the total set of rows in your annotations.
let myFunction :
  'a . #{...'a, z: int} => string =
    fun o => string_of_int o#z;

If you leave out the type definition, the row polymorphism will be inferred.

A couple of thoughts on #{} vs { x: ..}. I'm torn. Our feedback that we've gotten is that people don't like the hash. I do like that the hash is "up front", so you know immediately that the type is an object instead of record. Whereas with {x: ..} you have to wait until the end (imagine a long definition).
Things I like about the hash proposal:

We can make object definitions resemble it without needing pub/pri let x = #{bar: "hi"}.
I like that it's "up front" so when reading long definitions, you know immediate that they're not record definitions.

Things I dislike about the hash:

You end up having to put pri anyways to mark some methods private.
The mandatory pub/pri makes it possible to get rid of semicolons in objects (like JS).

I'm wondering  if we can get the best of both without any hashes at all. It might also simplify the parser greatly - it would no longer need to wait until the "end" to see what type of object/record it is.
/* Closed object type : These are very rare anyways */
type objType = {. doSomething: int => unit, foo: unit};

/* Row polymorphic object type - two dots. */
type objType 'a = {..'a, doSomething: unit => int, foo: unit};

/* Row polymorphic object type - two dots. */
type recordType = {doSomething: int => unit, foo: unit};

/* Faux-polymorphic records (one day?) Three dots */
type recordType 'a = {...'a, doSomething: int => unit, foo: unit};

/* Now if we give objects a comma, they look more like their definitions */
let myObject = {
  pub doSomething i => (),
  pub foo => ()
};
/* But the commas are optional! Printer will remove them  */
let myObject = {
  pub doSomething i => ()
  pub foo => ()
};

let myRecord = {doSomething: fun i => (), foo: ()};

/* We can also make the syntax for method dispatch be object.methodName: with
 * the trailing colon being attached to the method name like a label. They would be
 * highlighted as one token in the editor.
 */
let myRes = myObject.doSomething: 100;
let myRes = myObject.foo:;
let myRes = myRecord.doSomething 100;

The methodName: isn't easy to get right because we need to ensure that type annotations always have spaces around the : like let res = (someValue.recordField : int).
But the big advantage is that we can cary the label: to named arguments like:
let res = myObject.doSomething: withNamedArg:10 andAnotherNamedArg:[];

I'm also realizing that my original objection to type o 'a = {..'a, blah: int} was that that it looks strange when writing it in the as 'a form type o 'a = {.., blah: int} as 'a}. But I think that wouldn't be an issue if we just always write/print objType as 'a as {..'a, fields}. That is, if you wrote {.._, fields} as 'a, it would even be printed as {..'a, fields}. When making type definitions (as opposed to annotations), you're always forced to acknowledge the row polymorphism anyways so it's not likely we'd get stuck with something like {.._, fields} where there is no 'a. The only time you omit the type parameter is on inline definitions of values, where the type parameters are inferred.
let myFunc = fun (o: {.._, field: int}) => {
  o.field: + o.field:
};

In that case type of myFunc would be:
'unNamedType . {..'unNamedType, field: int} => int

We could provide special sugar for {.._, field: int} in the form of {_, field: int}.

@jordwalke Thanks for writing all of this up!
Here's my (lengthy) object syntax proposal: https://gist.github.com/bsansouci/ca4dee603ed2bd8ed0a8c4e939f9b2d2.
It's basically inlined with what this PR did for type declaration, but reuses that for object declarations. My goal with this was to make using objects basically like a record as simple as possible. Because sometimes I need the row polymorphism and I don't really care for anything else about Objects.

@bsansouci I replied on that gist.

We can always evolve the object syntax rapidly, but for now the best result that incorporates all the feedback here seems to be:
{..'a, fields}, {. fields} for open and closed object types respectively, where {..'a, fields} is simply sugared rewriting of {.. fields} as 'a). I believe it may also make this diff much simpler to implement (you might be able to delete some parts of it that degrade readability of the parser?). For now, I think we can even just implement it as {.. fields} as 'a and save the super sugared {..'a, fields} for later. That would by itself make a #goodFirstTask.

The only little weirdness to the resulting syntax would be that object values are of the form {field ; field}, but their types are of the form {field, field}. As a next step (in another diff) we should think about fixing that, by either making objects look more like records {field, field}, or something else.

The dots have been moved to the front.
What's important to note is that I also changed private for types to pri (see also: https://caml.inria.fr/pub/docs/manual-ocaml/extn.html#sec220).

🎉