[FEATURE] Centralize common Project Strings so code-reuse doesn't proliferate

I've noticed in recent checkins that the Assembly Product Version and Product Name are referenced as instanced strings in many places within the code-base. This necessitates code-reuse and raises the possibility of typos across the project. I'm recommending that these strings (and any others) be centralized into static class properties that can be referenced across the program.
Describe the solution you'd like
Product Name and Product Version should be set only 1 time in a centralized class (or other method if preferred) and referenced across the project as needed. Perhaps an AssemblyInfo class with static members instanced as a singleton and then referenced whenever desired so scrutiny of strings across the project are greatly reduced.
Describe alternatives you've considered
Global Variables - Ick
Extending the Assembly Class and referencing it widely - Possible
Centralized String collection that references internally - Allows for flexibility and centralized extensibility + language support. May not be instantiated when needed. Has fallen out of favor.
Additional context
Example change from recent Commit:

This is a good observation, but one thing to consider is that this was build originally as separate modules (VAICOM, Chatter, AIRIO) as separate dll's, so that could explain the different packages containing the information instead of it being centralized. In your example you have info for the files that build the Chatter.dll and AIRIO.dll so it would make sense they were once separate in the original source code.

Perfectly fair. I'd still push this into Project Settings instead of having it everywhere.  Not a priority. Just wanted to contribute my thoughts. Put it low-pri.

Added Directory.Build.targets to Development branch. Allow Version strings across multiple projects.
Will migrate to Beta and Master in time. Closing Issue.


[Feature Request] Add PyCon USA lightning talk in resources section

Add Lightning talk of Robyn at PyCon USA: https://www.youtube.com/watch?v=1IiL31tUEVk&ab_channel=PyConUS inside the resources section.

Yess. Great talk btw!


custom paths are not included in vscode env.

VSCode Version: 1.3.0-insider (1.3.0-insider)
OS Version: Mac OS X El Captain

Steps to Reproduce:

with latest insider build, append any custom path to PATH in .bashrc or using dotfile
create a node script using shelljs

console.log(shellJs.exec('echo $PATH').stdout);

launch debug (if you are using nvm, then you have to set runtimeExecutable to the version you want. vscode doesn't work any more with default node version set by nvm)

the log shows only /usr/bin:/bin:/usr/sbin:/sbin as path
it worked with stable version and old insider version (not nightly ones)

@joaomoreno has the env propagation been changed on OS X recently?

@gitawego Cmd Shift P, Developer Tools, what do you get with process.env in the console?

@joaomoreno  this is my process.env

the path variable should have much more content.

It's great that we're catching these issues before this hits the stable, so thanks for taking the time for filing the issue and helping us out!
Still in the developer tools, do you mind running this code and letting me know what you get? This is exactly the code we're running to figure out your environment. Make sure you put the right location of the Insiders app in the first line, in case you placed it in another place.
const electron = "/Applications/Visual Studio Code - Insiders.app/Contents/MacOS/Electron";
const cp = require('child_process');
const env = Object.assign({}, process.env, {
	ATOM_SHELL_INTERNAL_RUN_AS_NODE: '1',
	ELECTRON_NO_ATTACH_CONSOLE: '1'
});
const command = `'${electron}' -p 'JSON.stringify(process.env)'`;
const result = cp.spawnSync(process.env.SHELL, ['-ilc', command], {
	detached: true,
	stdio: ['ignore', 'pipe', process.stderr],
	env,
	encoding: 'utf8'
});
console.log(result.stdout);

Thanks!

sorry for the retard, voila the output:
(B{"MANPATH":"/Users/gitawego/.nvm/versions/node/v6.2.1/share/man:/usr/local/share/man:/usr/share/man:/opt/X11/share/man:/Applications/Xcode.app/Contents/Developer/usr/share/man:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/share/man","LESS_TERMCAP_md":"\u001b[38;5;136m","ATOM_SHELL_INTERNAL_RUN_AS_NODE":"1","NVM_CD_FLAGS":"","TERM":"xterm-256color","SHELL":"/usr/local/bin/bash","HISTSIZE":"32768","TMPDIR":"/var/folders/6t/5077bgf135d9kwn848lk8z5m0000gn/T/","NVM_PATH":"/Users/gitawego/.nvm/versions/node/v6.2.1/lib/node","Apple_PubSub_Socket_Render":"/private/tmp/com.apple.launchd.imA84ep7Za/Render","LC_ALL":"en_US.UTF-8","NVM_DIR":"/Users/gitawego/.nvm","HISTFILESIZE":"32768","PYTHONIOENCODING":"UTF-8","USER":"gitawego","LS_COLORS":"no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.avi=01;35:*.fli=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.ogg=01;35:*.mp3=01;35:*.wav=01;35:","NODE_REPL_MODE":"sloppy","SSH_AUTH_SOCK":"/private/tmp/com.apple.launchd.XKus3fylIG/Listeners","VSCODE_TSJS":"1","__CF_USER_TEXT_ENCODING":"0x1F5:0x0:0x0","GOOGLE_API_KEY":"AIzaSyAQfxPJiounkhOjODEO5ZieffeBv6yft2Q","PATH":"/Users/gitawego/.nvm/versions/node/v6.2.1/bin:/usr/local/sbin:/Users/gitawego/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Users/gitawego/workspace/android-sdk-macosx/platform-tools:/Users/gitawego/workspace/android-sdk-macosx/tools:/Users/gitawego/workspace/android-sdk-macosx/platform-tools:/Users/gitawego/workspace/android-sdk-macosx/tools","NVM_NODEJS_ORG_MIRROR":"https://nodejs.org/dist","PWD":"/","ELECTRON_NO_ATTACH_CONSOLE":"1","EDITOR":"vim","LANG":"en_US.UTF-8","XPC_FLAGS":"0x0","PS1":"\\[\\033]0;\\W\\007\\]\\[\u001b[1m\\]\\n\\[\u001b[38;5;166m\\]\\u\\[\u001b[97m\\] at \\[\u001b[38;5;136m\\]\\h\\[\u001b[97m\\] in \\[\u001b[38;5;64m\\]\\w$(prompt_git \"\\[\u001b[97m\\] on \\[\u001b[38;5;61m\\]\" \"\\[\u001b[38;5;33m\\]\")\\n\\[\u001b[97m\\]$ \\[\u001b(B\u001b[m\\]","HISTCONTROL":"ignoreboth","PS2":"\\[\u001b[38;5;136m\\]→ \\[\u001b(B\u001b[m\\]","XPC_SERVICE_NAME":"0","MANPAGER":"less -X","SHLVL":"1","HOME":"/Users/gitawego","VSCODE_NLS_CONFIG":"{\"locale\":\"en-us\",\"availableLanguages\":{}}","VSCODE_SHARED_IPC_HOOK":"/var/folders/6t/5077bgf135d9kwn848lk8z5m0000gn/T/Code - Insiders-c2fcce-shared.sock","LOGNAME":"gitawego","NODE_REPL_HISTORY":"/Users/gitawego/.node_history","VSCODE_IPC_HOOK":"/var/folders/6t/5077bgf135d9kwn848lk8z5m0000gn/T/Code - Insiders-c2fcce.sock","NVM_BIN":"/Users/gitawego/.nvm/versions/node/v6.2.1/bin","NVM_IOJS_ORG_MIRROR":"https://iojs.org/dist","VSCODE_PID":"3822","DISPLAY":"/private/tmp/com.apple.launchd.mcfO1QRHOx/org.macosforge.xquartz:0","NODE_REPL_HISTORY_SIZE":"32768","_":"/Applications/Visual Studio Code - Insiders.app/Contents/MacOS/Electron"}

@gitawego What are those �(B�[m characters at the beginning? Was that really printed by the console.log command?
To verify, run this snippet:
const electron = "/Applications/Visual Studio Code - Insiders.app/Contents/MacOS/Electron";
const cp = require('child_process');
const env = Object.assign({}, process.env, {
	ATOM_SHELL_INTERNAL_RUN_AS_NODE: '1',
	ELECTRON_NO_ATTACH_CONSOLE: '1'
});
const command = `'${electron}' -p 'JSON.stringify(process.env)'`;
const result = cp.spawnSync(process.env.SHELL, ['-ilc', command], {
	detached: true,
	stdio: ['ignore', 'pipe', process.stderr],
	env,
	encoding: 'utf8'
});

try {
	console.log(JSON.parse(result.stdout));
} catch (e) {
	console.log(e);
}

Let's see if that output isn't valid JSON...

the output's JSON isn't valid....

Very interesting... OK now jump to Terminal in OS X and run:
node -p 'JSON.stringify("hello world")' | node -e 'process.stdin.setEncoding("utf8"); process.stdin.on("data", data => console.log(JSON.parse(data)))'
You should see hello world.

first code returns:
hello world

second code returns:
hello world
Saving session...completed.

Hm... Let's maybe try another approach...
Back in the Developer Tools, try this:
const electron = "/Applications/Visual Studio Code - Insiders.app/Contents/MacOS/Electron";
const cp = require('child_process');
const env = Object.assign({}, process.env, {
	ATOM_SHELL_INTERNAL_RUN_AS_NODE: '1',
	ELECTRON_NO_ATTACH_CONSOLE: '1'
});
const command = `'${electron}' -p 'JSON.stringify(process.env)'`;
const result = cp.spawnSync(process.env.SHELL, ['-ilc', command], {
	detached: true,
	stdio: ['ignore', 'pipe', process.stderr],
	env
});

console.log(result.stdout.slice(0, 10));

It should show us the exact bytes that are in the beginning of the result, that should lead us to finding out where they come from.

the result is
[27, 40, 66, 27, 91, 109, 123, 34, 77, 65]

Et voilá. The offending bytes appear to be 1b 28 42 1b 5b 6d which appear to be two terminal escape sequences:

1b 28 42 seems related to Kanji
1b 5b 6d seems related to graphic rendition

The fix here would be to strip the JSON from any escape sequences...
Does this make it work?
const electron = "/Applications/Visual Studio Code - Insiders.app/Contents/MacOS/Electron";
const cp = require('child_process');
const env = Object.assign({}, process.env, {
	ATOM_SHELL_INTERNAL_RUN_AS_NODE: '1',
	ELECTRON_NO_ATTACH_CONSOLE: '1'
});
const command = `'${electron}' -p 'JSON.stringify(process.env)'`;
const result = cp.spawnSync(process.env.SHELL, ['-ilc', command], {
	detached: true,
	stdio: ['ignore', 'pipe', process.stderr],
	env,
	encoding: 'utf8'
});
const strip = s => s.replace(/[\u001b\u009b][[()#;?]*(?:[0-9]{1,4}(?:;[0-9]{0,4})*)?[0-9A-ORZcf-nqry=><]/g, '');

try {
	console.log(JSON.parse(strip(result.stdout)));
} catch (e) {
	console.log(e);
}

yup, it works. so this is the problem ?

Yeah man, let's push a fix! 👍

thanks a lot :)

Let's just keep it open until we push a fix. 😉


Update version: OpenWhisperSystems.Signal.Beta version 6.31.0-beta.2

Pull request has been created with WinGet Automation :rocket:
Microsoft Reviewers: Open in CodeFlow

Automatic Validation ended with:

Fixing the error obviated this PR. Reset PR.


update for oops PR, Update the UnstructuredInterpolator's geometric algorithms

make sure soca is up to date with upstream PR

https://github.com/JCSDA-internal/oops/pull/2532#event-11612220828

bonus points for actually testing it with the global 1/4 deg

bonus points for actually testing it with the global 1/4 deg

A test with a regional domain may be good to run as well, just to be sure I didn't break anything at regional domain edges...?


Updates projects as trash-notice

Using same LINE Messaging API, modify codes as trash-notice.

Modified the parameters in LINE Developers portal ( https://developers.line.biz/en/ ) and LINE Official Account Manager ( https://manager.line.biz/account/<ACCOUNT_ID> )

Account Config

Account Name : trash-notice
Status Message

Channel Config

Channel Name : trash-notice
Channel description


Remove outdated default index mapping error message

This error message is no longer relevant and should not be used now.
Closes: #7007
Description
Removing outdated error message.
Issues Resolved
#7007
Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[x] Commits are signed per the DCO using --signoff
[x] Commit changes are listed out in CHANGELOG.md file (See: Changelog)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #7008 (ced508e) into main (59e881b) will decrease coverage by 0.14%.
The diff coverage is n/a.

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

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@             Coverage Diff              @@
##               main    #7008      +/-   ##
============================================
- Coverage     70.77%   70.63%   -0.14%
+ Complexity    59270    59192      -78
============================================
  Files          4822     4822
  Lines        283940   283940
  Branches      40947    40947
============================================
- Hits         200963   200570     -393
- Misses        66454    66852     +398
+ Partials      16523    16518       -5

Impacted Files
Coverage Δ

...ava/org/opensearch/index/mapper/MapperService.java
75.10% <ø> (ø)

... and 468 files with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Apologies. This PR was auto closed without reaching a resolution from the maintainers.
Re-opening to move it forward.
Thanks for your contributions to OpenSearch!


[WIP] Refactor the hive input handling

Add the column information from hive, not from file
Better support for databricks tables (although still not working)
Add the partition information as columns
do not read in _success files etc
add debugging info

This should be a first step towards #83.
When I now create a databricks table with
import pandas as pd
d = {'col1': [1, 2], 'col2': [3, 4]}
pdf = pd.DataFrame(data=d)

df = spark.createDataFrame(pdf)
df.write.format("csv").saveAsTable("tmp.df")

I "at least" only end up with "dbfs:/user/hive/warehouse/tmp.db/df2/*.csv resolved to no files".
When the dbfs is integrated as additional fs, that might already do the trick.
For finishing up this PR, I now definitely need tests. Maybe I should spin up a test hive instance with docker.

Codecov Report

Merging #95 (1ed6297) into main (6fa88ed) will decrease coverage by 0.13%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##              main      #95      +/-   ##
===========================================
- Coverage   100.00%   99.86%   -0.14%
===========================================
  Files           34       34
  Lines         1446     1453       +7
  Branches       201      201
===========================================
+ Hits          1446     1451       +5
- Misses           0        2       +2

Impacted Files
Coverage Δ

dask_sql/input_utils.py
95.83% <100.00%> (-4.17%)
:arrow_down:

dask_sql/mappings.py
100.00% <100.00%> (ø)

dask_sql/physical/rel/base.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


Improve error messages in schema validation on unknown argument

Problem
When you write an attribute in the prisma schema and add an argument that isn't known to prisma, the error is just "No such argument".
Suggested solution
A better error message with more context, and maybe a list of accepted arguments.

Hi there,
As part of our effort to clean up our GitHub repo, we’re closing this issue to help focus on features and improvements that align with our focus areas and those of our community.
This issue was originally created for internal tracking purposes, but if you feel this is important to you, feel free to reopen the issue and get like-minded users to upvote as we will prioritize fixing issues based on community interest.
For more insight into our priorities and how we’re thinking about the future of Prisma, please see our blog post: https://www.prisma.io/blog/prisma-orm-manifesto.
Thank you for your understanding and support!


Design system site homepage

Adds several new sections to homepage plus integrates Konstantin's new highlight section component

Used PR for easy revert, merging now because it is going into shared working branch


CC2652P TX UART does not send serial

I configured zigbee CC2652P router mode end device does not send any serial

For coordinator I use Tasmota
serial log results when connected to an end device like this
15:08:06.310 ZIG: ZbZNPSent 250428DA28DA01
15:08:06.360 ZIG: {"ZbZNPReceived":"650400"}
15:08:06.411 ZIG: {"ZbZNPReceived":"458428DA0028DA14010401FEFF000400001400070006000200000600"}
15:08:06.416 RSL: RESULT = {"ZbState":{"Status":33,"Device":"0xDA28","Endpoint":"0x01","ProfileId":"0x0104","DeviceId":" 0xFFFE","DeviceVersion":0,"InClusters":["0x0000","0x0014","0x0007","0x0006"],"OutClusters":["0x0000","0x0006"]}}

@t0p1x Could you please describe how do you test UART on CC2652? Did you try to swap TX and RX wires?

data sent from the end device to the coordinator was successful, but not from the coordinator to the end device
for endpoints 1 and 2, the GenMultiStateValue part is input only

Thank you for your help
Finally I can send serial data using zigbee2mqtt
In the tasmota program there is no command to send serial data


feat: use small HTTP dependency

Use teenyRequest instead of request. This saves 900 ms at
startup time.
Improve load time from 1500 ms to 650 ms.
Before request:

After with teenyRequest:

There is a problem where teeny-request expects its body input to be an object, while request expects it to be a string. We exhibit the latter behavior currently, so this PR fails system tests. I'm currently trying to fix it.

Thanks, PRs to teeny are welcome! I had accidentally stringified a string, but fixed that in 3.8.

ping @kjin

@fhinkel Oh, I didn't know you were the author 😆 I'll open a PR if you haven't fixed that already.


Demo is broken

See the learn more here link.
Src: https://github.com/meteor-useraccounts/bootstrap#useraccountsbootstrap

agree, http://useraccounts.meteorapp.com/ is dead


OAuth authentication doesn't work even on demo in herokuApp

About http://ng-token-auth-demo.herokuapp.com/ OAuth authentication doesn't work.
Facebook opens a page stating:
Not Found:
Sorry, but the page you were trying to view does not exist.
(also I can't find how you configure it to open the url in a new window)
Github, Google:
New window is loaded, redirects to home, but no authentication occurs.

I didn't see this prior to opening on demo repo at https://github.com/lynndylanhurley/devise_token_auth_demo/issues/7

I'm also noticing this on the demo. For me, the auth parameters are present in the querystring after the redirect, but the app does not seem to pick up on them.

I have the same problem. How can I solve this?


Visual glitch when too many items are selected

Perhaps break the list into multiple lines when it becomes too long?

@aaronshaf maybe this issue is resolved already? I couldn't reproduce the error in the page


Import code mess

A mess of the starter code.
Docs are not behaving.

Codecov Report

Merging #2 into master will increase coverage by 8.84%.
The diff coverage is 8.87%.

@@            Coverage Diff            @@
##           master      #2      +/-   ##
=========================================
+ Coverage       0%   8.84%   +8.84%
=========================================
  Files           1      57      +56
  Lines           1     294     +293
=========================================
+ Hits            0      26      +26
- Misses          1     268     +267

Impacted Files
Coverage Δ

src/WebDriver.jl
0% <ø> (ø)
:arrow_up:

src/02_commands/04_Contexts/03_Switch_To_Window.jl
0% <0%> (ø)

src/02_commands/05_Elements/14_Element_Click.jl
0% <0%> (ø)

src/02_commands/05_Elements/10_Get_Element_Text.jl
0% <0%> (ø)

src/02_commands/06_Documents/03_Get_All_Cookies.jl
0% <0%> (ø)

src/01_structs/07_Errors.jl
0% <0%> (ø)

src/02_commands/03_Navigation/03_Back.jl
0% <0%> (ø)

...rc/02_commands/03_Navigation/02_Get_Current_URL.jl
0% <0%> (ø)

src/02_commands/07_Actions/02_Move_To.jl
0% <0%> (ø)

src/02_commands/03_Navigation/05_Refresh.jl
0% <0%> (ø)

... and 103 more

Continue to review full report at Codecov.

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


Does the genotype build make a difference on prediction??

Hello, I wanted to know if the genotype build makes any difference on the gene expression prediction. My genotype data is on hg18, and I am using GTEx v7 as reference in PrediXcan. Do I need to convert to hg19, then Gh38, and then do the prediction? Will that improve the accuracy of prediction ??
I have already done prediction using hg18 genotypes without any errors. Please advise.

Hi
the models in V7 were trained with hg19 so it will work best with that
build. Our models should be robust to using other builds since we are
matching rsids but of course there will be some corner cases where hg19
will do much better.
I hope this helps
Haky
On Mon, Apr 9, 2018 at 7:33 PM, gpwhiz<EMAIL_ADDRESS>wrote:

Hello, I wanted to know if the genotype build makes any difference on the
gene expression prediction. My genotype data is on hg18, and I am using
GTEx v7 as reference in PrediXcan. Do I need to convert to hg19, then Gh38,
and then do the prediction? Will that improve the accuracy of prediction ??
I have already done prediction using hg18 genotypes without any errors.
Please advise.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/hakyim/PrediXcan/issues/27, or mute the thread
https://github.com/notifications/unsubscribe-auth/AC2ouShscM0FRwkf2A65WbSEd9L6-y29ks5tm_3GgaJpZM4TNbR1
.


serialization writer doesn't escape double quotes in strings

If a string value contains a single quote the serialization writer doesn't escape it and this produces an invalid JSON representation.
A good example of that is the OData etag field (when trying to serialize to storage after retrieving from the service)
<EMAIL_ADDRESS>"W/\"CQAAABYAAAAs+XSiyjZdS4Rhtwk0v1pGAAC5bsJ2\""

ends up producing
<EMAIL_ADDRESS>"W/"CQAAABYAAAAs+XSiyjZdS4Rhtwk0v1pGAAC5bsJ2""

Is this related to the PR awaiting review?
PR https://github.com/microsoft/kiota-serialization-json-go/pull/6

For the string part yes. For the byte one and the comma trimming no. The author hasn't replied to my initial clarification request and it's missing unit tests. Feel free to submit one focused on the quote issue. We'll resolve conflicts if the author replies.


Generating based on local schema file instead of URL

We have a local graphql schema file generated from the server code.
I would prefer not having to spin up a server instance as part of our CI build, and
just point graphqelm at the generated schema file.
I already tried graphqelm file:///path/api.graphql
But alas not that lucky.

Found --introspection-file. Closing.


Get Replies of a Particular Tweet , By tweet Id

Great Library of Immense Utility by the Creators !!
Wanted to know if we could also get replies to a particular tweet when we have the id of the tweet available, which I think might be a critical use case for collecting data.
Regards,

I want it too


Error while using TwitchClient.withCredentials and checking for Subscriptions

Bug Report
When using TwitchClient.withCredentials and calling getSubscriptions or getSubscriptionForUser (and I tested with Kraken too with same credentials, and Kraken scopes). It returns no error object at all in the catch.
Note: I tested with the request package with same access tokens in the same session, just one line different, and it returns correctly.
Code
    let errors = [];
    let dailyPoints=0;

    let channelTwitchClient;
    let appTwitchClient;
    let channelSettings;
    if(!channelTwitchClient){
      let accessTokenCheck = await TwitchClient.getTokenInfo(APIKeys.twitchEXTClientID,<ACCESS_TOKEN>);
      errors.push({name:'accessTokenCheck',data:accessTokenCheck});
      if(accessTokenCheck){
        let [chanTwitchClient,chanTwitchClientError] = await handle(TwitchClient.withCredentials(APIKeys.twitchEXTClientID,<ACCESS_TOKEN>));
        if(chanTwitchClientError) errors.push({name:'chanTwitchClientError',error:chanTwitchClientError});
        if(channelTwitchClient && !chanTwitchClientError){
          channelTwitchClient=chanTwitchClient;
        }
      }
    }

    if(!appTwitchClient) {
      let [apTwitchClient,apTwitchClientError] = await handle(TwitchClient.withCredentials(APIKeys.twitchEXTClientID, <APP_ACCESS_TOKEN>));
      if(apTwitchClientError) errors.push({name:'apTwitchClientError',error:apTwitchClientError});
      if(apTwitchClient && !apTwitchClientError){
        appTwitchClient=apTwitchClient;
      }
    }
    if(!channelTwitchClient && appTwitchClient){
      channelTwitchClient=appTwitchClient;
    }
    let [follow,followError] = await handle(channelTwitchClient.kraken.users.getFollowedChannel(req.query.userID,req.query.channelID));
    channelTwitchClient.helix.subscriptions.getSubscriptions(req.query.channelID)
      .then(data=>{
        errors.push({name:'getSubscriptionForUser.then',data:data})
      })
      .catch(error=>{
        errors.push({name:'getSubscriptionForUser.catch',error:error})
      });
    let [subscription,subscriptionError] = await handle(channelTwitchClient.helix.subscriptions.getSubscriptionForUser(req.query.channelID,req.query.userID));
    //let [subscription,subscriptionError] = await handle(channelTwitchClient.kraken.channels.getChannelSubscriptionByUser(req.query.channelID,req.query.userID));
    //let [subscription,subscriptionError] = await handle(appTwitchClient.kraken.channels.getChannelSubscriptionByUser(req.query.channelID,req.query.userID));
    let [moderator,moderatorError] = await handle(channelTwitchClient.helix.moderation.getModerators(req.query.channelID,{userId:req.query.userID}));
    let [shadowFlipBotSub,shadowFlipBotSubError] = await handle(appTwitchClient.helix.subscriptions.getSubscriptionForUser('435188356',req.query.userID));
    //let [shadowFlipsSub,shadowFlipsSubError] = await handle(appTwitchClient.helix.subscriptions.getSubscriptionForUser('485311079',userID));

    if(!channelSettings){
      let [chanSettings,chanSettingsError] = await handle(getChannelSettings(req.query.channelID));
      if(chanSettingsError) errors.push(chanSettingsError);
      if(chanSettings && !chanSettingsError){
        channelSettings=chanSettings;
      }
    }

    if(channelSettings){
      dailyPoints += channelSettings.settings.goLivePoints.base * channelSettings.pointSKUs.flip.multiplier;
      //If they are following
      if(follow){
        dailyPoints += channelSettings.settings.goLivePoints.follow * channelSettings.pointSKUs.flip.multiplier;
      }
      //If notifications are on
      if(follow && follow.hasNotifications){
        dailyPoints += channelSettings.settings.goLivePoints.notification * channelSettings.pointSKUs.flip.multiplier;
      }
      //If Subscribed
      if(subscription && subscription.tier){
        dailyPoints+=channelSettings.settings.goLivePoints.subscription[subscription.tier] * channelSettings.pointSKUs.flip.multiplier;
      }
      if(shadowFlipBotSub && shadowFlipBotSub.tier){
        dailyPoints+=channelSettings.settings.goLivePoints.subscription[shadowFlipBotSub.tier] * channelSettings.pointSKUs.flip.multiplier;
      }

      //if(shadowFlipsSub && shadowFlipsSub.tier){
      //  dailyPoints+=channelSettings.settings.goLivePoints.subscription[botSub['sub_plan']] * channelSettings.pointSKUs.flip.multiplier;
      //}

      if(moderator){
        dailyPoints += channelSettings.pointSKUs.flip.multiplier;
      }
    }
    if(followError) errors.push({name:'followError',error:followError});
    if(subscriptionError) errors.push({name:'subscriptionError',error:subscriptionError});
    if(shadowFlipBotSubError) errors.push({name:'shadowFlipBotSubError',error:shadowFlipBotSubError});
    if(moderatorError) errors.push({name:'moderatorError',error:moderatorError});

    if(errors.length>0) pushError(req.query.channelID,createErrorObject(req.query.channelID,req.query.userID,errors,'testBotGoLivePointAmount')).catch(()=>{});
    if(dailyPoints>=0){
      console.log(JSON.stringify(dailyPoints) + ' - ' + JSON.stringify(errors));
    }
    else{
      console.log('Something went wrong - ' + JSON.stringify(errors));
    }

handle is just a async wrapper to grab the errors easily.
export const handle = (promise) => {
  return promise
    .then(data => ([data, undefined]))
    .catch(error => Promise.resolve([undefined, error]));
};

The results from the token check is
            {
                "client_id": "f32p3no3oxomqviy35liavolqb4gyo",
                "login": "wlg3r",
                "scopes": [
                    "channel:read:subscriptions",
                    "channel_check_subscription",
                    "channel_read",
                    "channel_subscriptions"
                ],
                "user_id": "145796834",
                "expires_in": 816929
            }

I left out moderation to check a call with the wrong scope, and the call to moderators returns nothing, just like subs.
Expected behavior
Returns subscription object.
Actual Behavior
No object, and no error object.
Environment

Version: 3.7.1
Node version: 10 and 8

I'm not really seeing through this whole bunch of code. Can you please post a reduced test case that clearly shows what is going on?

I think something may have been cached bad on Google's cloud, I went in this morning to re-do it simpler, and it just worked....


change Namedlist attributes into private naming schema (_*).

Provides a fix to issue #143 that does not break existing workflows
and leaves more flexibility when choosing attribute names.

Hi @troycomi I know. However, we need the ability to set attributes named as e.g. sort, for backwards compatibility (see e.g. the bwa mem wrapper). Also, it would be really inconvenient if all those names are suddenly unavailable. I plan to carefully watch this, such that nothing allowed is used internally.


The esm version of the vue3-sfc-loader in the nodejs environment

Since the 0.9.2 version the exprorts fields have been changed in the package.json in favor of the node version:
"main": "./dist/vue3-sfc-loader.js" => "main": "./dist/vue3-sfc-loader-node.js",
"module": "./dist/vue3-sfc-loader.esm.js" => "module": "./dist/vue3-sfc-loader-node.mjs",
"import": "./dist/vue3-sfc-loader.esm.js" => "import": "./dist/vue3-sfc-loader-node.mjs"
"require": "./dist/vue3-sfc-loader.js" => "require": "./dist/vue3-sfc-loader-node.js"
This led to the fact that the ESM version is unreachable.
import { loadModule } from "vue3-sfc-loader" - loads a node version;
import { loadModule } from "vue3-sfc-loader/dist/vue3-sfc-loader.esm" - gives an error
I dare to propose, that the simple solution of the problem is just added one string to the package.json file:
"exports": {
".": {
"import": "./dist/vue3-sfc-loader-node.mjs",
"require": "./dist/vue3-sfc-loader-node.js"
},
"./esm": "./dist/vue3-sfc-loader.esm.js"
},
Consider your attention on the line "./esm": "./dist/vue3-sfc-loader.esm.js", please.
This line allow to include esm version of the vue3-sfc-loader, like that:
import { loadModule } from "vue3-sfc-loader/esm";
Please review the ability of including the line "./esm": "./dist/vue3-sfc-loader.esm.js" in the package.json file.
Thank you in advance!

Or even if it's possible:
"exports": {
".": {
"import": "./dist/vue3-sfc-loader-node.mjs",
"require": "./dist/vue3-sfc-loader-node.js"
},
"./esm": "./dist/vue3-sfc-loader.esm.js",
"./umd": "./dist/vue3-sfc-loader.js",
},

The following export should work with all combinations I want to support:
nodejs for server-side compilation/caching (https://nodejs.org/api/packages.html#conditional-exports)
vitejs (https://vitejs.dev/config/shared-options.html#resolve-conditions)
webpack (https://webpack.js.org/guides/package-exports/#conditions)
jsdelivr CDN (https://www.jsdelivr.com/documentation#id-configuring-a-default-file-in-packagejson)
  "browser": "./dist/vue3-sfc-loader.js",
  "main": "./dist/vue3-sfc-loader.js",
  "module": "./dist/vue3-sfc-loader.esm.js",
  "types": "./dist/types/vue3-esm/index.d.ts",
  "exports": {
    ".": {
      "node": {
        "import": "./dist/vue3-sfc-loader-node.mjs",
        "require": "./dist/vue3-sfc-loader-node.js"
      },
      "import": "./dist/vue3-sfc-loader.esm.js",
      "require": "./dist/vue3-sfc-loader.js"
    },
    "./vue2": {
      "node": {
        "import": "./dist/vue2-sfc-loader-node.mjs",
        "require": "./dist/vue2-sfc-loader-node.js"
      },
      "import": "./dist/vue2-sfc-loader.esm.js",
      "require": "./dist/vue2-sfc-loader.js"
    },
    "./dist/*": "./dist/*",
    "./package.json": "./package.json"
  },

for the record, you said earlier:

I opened a new issue for the topic, please take a look: https://github.com/FranckFreiburger/vue3-sfc-loader/issues/179
As for the context, I'll try to explain.
Suppose, that you have a nodejs environment on your PC. Let's go step by step:

Import your absolutly brilliant library and develop the vite+vue software (node)
Buid the software (vite build). Literally, vite package all files in the assets directory (node)
Deploy the software to the static hosting without nodejs environment
Open the software in an appropriate browser (browser)

In a few words, before the version 0.9.2 the vite had packaged esm version of the vue3-sfc-loader in the step 2, and in the step 4 a user obtained esm version of the vue3-sfc-loader.
Since the version 0.9.2, the vite is has packaged the node version of the vue3-sfc-loader and a user get errors in the step 4.

Franck, your solution is even better. Absolutely perfect!

closed by https://github.com/FranckFreiburger/vue3-sfc-loader/commit/55b8d727c33028c513a2ee02829b1489a06f1fe1


I can not list ObjectStore content

Which part is this question about

My question is about ObjectStore api.
Describe your question

I'm trying to list content of a store. I'm trying to use exact copy of documentation about it:
// create an ObjectStore
let object_store: Arc<dyn ObjectStore> = get_object_store();

// Recursively list all files below the 'data' path.
// 1. On AWS S3 this would be the 'data/' prefix
// 2. On a local filesystem, this would be the 'data' directory
let prefix = Path::from("data");

// Get an `async` stream of Metadata objects:
let mut list_stream = object_store.list(Some(&prefix));

// Print a line about each object
while let Some(meta) = list_stream.next().await.transpose().unwrap() {
    println!("Name: {}, size: {}", meta.location, meta.size);
}

but the rust-analyzer and rustc compiler both claim there is no next() method in list_stream come from object_store.list() method.
Additional context

I'm using latest version of ObjectStore at the moment "0.10.1".
I tried to test version "0.9" but I received other errors due to breaking changes in WriteMultipart struct.
So I don't want to refactor my code to comply older version.

@tustvold thanks,
Your comment solved my problem.
As I'm new to use this crate I think it is better someone more experienced with this code make a PR to update the manual.


test_basic/progvar: fix 64bit atomic types error

Enable 64bit atomics extentions in order to use 64bit atomic types in
test_progvar_prog_scope_init and test_progvar_prog_scope_uninit.
See issue #369

Please prepare fixes to 20 master branches as well.

I just find cl20 is not affected. I'll modify the patch to align with cl20.

Fix for master branch: https://github.com/KhronosGroup/OpenCL-CTS/pull/374

Thanks!


update changelog.md to 1.0.1+5 version.

Changelog got up to 1.1.0 right now, but went past by 1.0.1+5.
Since most of the changes were minor (and some were documentation) this will not be worked on right now.


Record progress of multiple files

Hi,
I've found the plugins that you've been working on really useful--in particular pdf++--and want to thank you very much for that. This new plugin seems like a very useful addition.
I was wondering whether you would consider storing the reading progress of each file that is viewed, rather than storing the progress of only the current file viewed?
Currently, I rely on Omnivore for reading longer pdfs from beginning to end, because Obsidian tends to lose track of my reading progress when I'm reading across several sessions and/or devices. With this plugin recording the reading progress of each pdf, Obsidian may be able to replace this functionality of Omnivore.
I was wondering, also, whether bi-directional sync would be possible if at each recording of the page number, there was a timestamp? And then the most recent page number would be opened.
Would either of these features be likely to be implemented in this plugin?
Thanks again!!

Thanks!

I was wondering whether you would consider storing the reading progress of each file that is viewed, rather than storing the progress of only the current file viewed?

That would be a nice feature to have. It would be better handled by PDF++ rather than this plugin, though.
What I have in mind for now is:

Each device records the latest progress (page, zoom level etc) and a timestamp in its own dedicated file like pdf-progress-macbook.json.
When opening a PDF file, PDF++ looks up the latest progress in the file, then sets the page number and so on accordingly.

This way, we will be able to record progress in each device. In addition, we could add an option like "share progress across devices" and specify which file to read another device's progress from (e.g. pdf-progress-ipad.json).
If this option is enabled, PDF++ compares the timestamps from all the devices and follows the latest one.

I was wondering, also, whether bi-directional sync would be possible if at each recording of the page number, there was a timestamp? And then the most recent page number would be opened.

It's something this plugin might be able to handle. I will consider the possibilities.

That sounds like a great solution, thanks! The speed of development of this plugins is amazing and much appreciated!

I've just released 0.2.0, in which a timestamp will be included in the view state file. You can choose to sync view states only if the followed device has a newer state than the current device.
I haven't been able to do enough tests on this version so if you encounter any issues, please let me know.


Mercury support

Check if ipyvizzu works with Mercury after this PR merged:
https://github.com/vizzuhq/ipyvizzu/pull/107
See also:
https://github.com/mljar/mercury/issues/81

ipyvizzu works in mercury, nothing to be done. see demo:
https://huggingface.co/spaces/rajesh1729/animated-visualization-with-mercury-ipyvizzu


Remove dependencies on public container registries

We currently reference a couple images from quay.io and docker.io.  These should be brought into our ACR instance and referenced that way instead.  Update the instructions to include this step and changes.

Work for this is in progress.  Will come in two phases, one for the baseline settings (flux and friends) and then one for the workload (traefik)

Still another to go


docs: Add sub categories to the exploded output of "Starlark Reference"

Where did you see the issue in our documentation?
https://docs.kurtosis.com/starlark-reference/plan
Issue description
I can't quite tell what I am looking at here and this is quite confusing for me

I'd like something more informative as a quick example -
Starlark Reference/
   Kurtosis Types/
      ConnecitonConfig
      NormalPacketDistribution
   Non Plan Functions/
      read_file
      import_module
    Plan Functions/ # (doesn't have to be exploded but current Plan doesn't make it obvious that add_service will be there)
       add_service
       remove_service

Hey @h4ck3rk3y can you add more color about what's going through your mind when you expand "Starlark Reference?"

For me the search now feels enough and haven't felt this pain in a while. Closing now, will open if someone needs this.


Intellisence can't work in unity3d when double click a symbolic link c# file

Environment data
dotnet --info output:
VS Code version:1.27.1
C# Extension version:1.15.2
Steps to reproduce

Create an empty unity3d project and create a symbolic link c# file to point other location.
Set the vscode as the default editor, then double click the c# file and it will be opened, but the c# file does't appear any intellisence tip.

Expected  behavior
Actual behavior

@DFVSQY The latest version of the csharp extension is out. Could you try using that and seeing if the error still reproduces.

@akshita31 I have a try for it, the bug still exists.

@DFVSQY Thanks for filing the issue. We will look into this.

@DFVSQY Can you provide a sample repro project?

TestSymbolicFiles.zip
Please first click the init.bat file to init symbolic files, then open the project using unity, double click the Scripts Folder files, you will see there are no any intellisence in vscode.

@DFVSQY Could you try editing the files you are talking about ? I double clicked the files you mentioned and opened them. We recently added the support for misc files and when you will start editing thosefiles you will start getting intellisense.  Is that correct ?

@akshita31 yes, i have a try, it does behave what you describe.

@akshita31  note that if i open symbolic files via "ctrl+p" in vscode, the intellisence works well, but it opens another tab for the same file.

I have the same issue for Unity3D 2019.4.0f1
Under the Assets folder there is a symlink to a folder outside of project folder. When double click the symlinked folder script in Unity3d, Visual Studio does open the file but no intellisense or autocomplete occurs. Even "Go to declaration" of classes does not work.

Closing due to lack of activity. Recommend using the new Unity extension for VS Code.


CustomGamePlayedWhileFarming doesn't work as expected

First of all, great new feature idea! I really like it better than people thinking I am actually playing something.
It seems to be incomplete though - in complex mode it works for the pre-idling period, but as soon as single games are farmed, the actual game is shown. I am not sure if this is intended behaviour or a bug - personally I would prefer to show the custom game during all farming.
Edit: This might be related to starting a normal steam client while a game farms.

I added special note to configuration in wiki.

Please note that ASF cannot guarantee the actual display order of Steam Network, therefore this is only a suggestion that may, or may not, display properly

That should be clear now :+1:


Expose helpers

This is the other part to fix #2620. expose getDefaultFileName and textSpan helpers.
Check bin\typescript.d.ts to see the changes to the public API

:+1:

Changes Unknown when pulling a8e4803fcdc0db2bb8adc1685edfe5447501ade4 on exposeHelpers into ** on master**.


Emit color job progress and job failure messages by default

Set the default NINJA_STATUS and the "FAILED" text on job failure to
use ANSI color code escapes if running under a smart terminal.
Requires #1454 to be merged first.

This is inherently subjective. We think the current default is a good default; it looks like you'll be able to set the env var to include color codes to get this locally soon.

Eliding with ANSI escapes is slower (if done correctly, see WIP about this in #1494), that's why we're reluctant to change the default. You also can't use smart_terminal as that is still true for Windows <10, which doesn't support ANSI color escapes.
Coloring the "FAILED:" message does sound like a good idea to me though.

Thanks, @jhasse

@jhasse Thank you for providing legitimate reasons for not taking this. Do you want me to open a separate PR for the red failure messages or rebase this one for you guys to reopen? Also, what do you recommend in lieu of smart_terminal?


Consider switching to GitHub Actions for automated testing

Description of issue or feature request:
We switched from automated testing on Travis CI (Linux) and Appveyor (Windows) to GitHub Actions in our sister-project in-toto-golang (see https://github.com/in-toto/in-toto-golang/pull/72), mostly due to availability concerns about Appveyor and because it seems appealing to configure only one service for all platforms.
Let's consider switching here too and testing on more platforms than we currently do.
Current behavior:
Use Travis CI and Appveyor for automated testing on Linux for Windows (no tests on macOS)
Expected behavior:
Use GitHub Actions instead and also test on macOS.

Related:  https://github.com/in-toto/in-toto/issues/407 and https://github.com/secure-systems-lab/securesystemslib/issues/297

Being able to test on Windows/Linux/macOS with the same CI make this a no-brainer to me.

Also consider injection vulnerabilities reported in https://crbug.com/project-zero/2070

See @jku's https://github.com/theupdateframework/tuf/issues/1204#issuecomment-725291899 as backing data point for the "configure only one service for all platforms" argument.

I think the next step is someone testing this to see if it's good enough.
Documenting a potential test matrix:
python: Latest release of all supported cpython 3.x versions, cpython 2.7. Currently that would be [2.7, 3.6, 3.7, 3.8, 3.9]
platform: Latest release of Linux, Windows, Mac: [ubuntu-latest, windows-latest, macos-latest]
Github does offer specific platform versions as well but I'm not sure it makes sense to use those? The matrix size as proposed is 15 test runs. As a bonus it might be nice to add pypy3 to python version list (not sure how much additional benefits it gives -- but it is something pip tests with and currently TUF tests pass): that should probably be done separately as the build dependencies might require a bit of tweaking there.
There's also at least one special case that we want to test (does not need to be part of the matrix, should not fail a build):
special: Securesystemslib master branch on "ubuntu-latest" with python "3.x"
This should be a good starting point: https://docs.github.com/en/free-pro-team@latest/actions/guides/building-and-testing-python

Also, we just ran out of build minutes on Travis. :(

Also, we just ran out of build minutes on Travis. :(

Wow. I didn't even realise we had a build minutes limit. Does that mean we can't do any more Travis builds in December?

IIUC, GitHub actions has no limits for open source projects (see first sentence in Billing for GitHub Actions). I am happy to set this up first thing next week.

IIUC, GitHub actions has no limits for open source projects (see first sentence in Billing for GitHub Actions). I am happy to set this up first thing next week.

No limits for open source is my understanding too, thanks for prioritising this @lukpueh!

am happy to set this up first thing next week.

I did some experiments but am likely to not concentrate on this at least early this coming week so feel free to copy-paste or just take notes from my branch:

example results: https://github.com/jku/tuf/actions
commit with workflow: https://github.com/jku/tuf/commit/3ba1d0de847ff5eb7193c9c848583f12f52fa38e

Notes:

should disable workflow commands in steps that might log untrusted things https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/
strategy.fail-fast default is true -- should consider what it should be and whether maybe lint should be run first as fail-fast and then others as matrix but not fail-fast (not sure how that would happen, just thinking out loud)
I disabled anything that didn't work on first try just to get something passing

python 2.7 failed to pip install something
windows failed test_6_download_target
pylint does not seem to support python 3.9 yet?
weird bug in pip leads to nasty results with tox (maybe this was what travis spent the minutes on):  https://github.com/pypa/pip/issues/9215

Thanks for the excellent spade-work, @jku! If you don't mind I'll try to PR something tomorrow.
Regarding your notes:

I haven't fully understood how, as an actions user, I can protect myself against set-env and add-path vulnerabilities. Do I need to audit the actions I use? Will need to further investigate.
Not sure what the best solution for fail-fast is. Your thoughts seem quite reasonable. I can try to create a configuration for that, but maybe in a follow-up PR.
Tests on 2.7 worked for me, not sure why they didn't for you. Do you still have the build results somewhere?
I also fixed windows builds, they just required a small patch in test_6_download_target.
pylint indeed seems to not yet fully support python 3.9 (see e.g. https://github.com/PyCQA/pylint/issues/3882). But 3.8 should be just as fine.

Apart from that I still need to finalize coveralls and fossa configuration.

I haven't fully understood how, as an actions user, I can protect myself against set-env and add-path vulnerabilities. Do I need to audit the actions I use? Will need to further investigate.

We shouldn't really be especially vulnerable I think -- none of our steps look like they could be easily made to print commands without control of the source code -- I'd say only the "Run tox" step is suspect (in the sense that there's so much code running we can't really rule out the possibility of untrusted output).
I think the only thing we can do is something like echo "::stop-commands::echo -n ${{ github.token }} | sha256sum | head -c 64" -- we could do that already in "Find pip cache dir" immediately after the ::set-output command: that should prevent any commands from being accepted from the output in the whole build after that.

Not sure what the best solution for fail-fast is. Your thoughts seem quite reasonable. I can try to create a configuration for that, but maybe in a follow-up PR.

:+1:

Tests on 2.7 worked for me, not sure why they didn't for you. Do you still have the build results somewhere?

Uh no, I seem to have deleted some builds I didn't intend to... Maybe it was a mistake in an earlier configuration

#1242 replaced travis/appveyor with GitHub Actions. Remaining issues discussed here are ticketized in https://github.com/theupdateframework/tuf/issues/1243, https://github.com/theupdateframework/tuf/issues/1244, https://github.com/theupdateframework/tuf/issues/1246, https://github.com/theupdateframework/tuf/issues/1247 and https://github.com/theupdateframework/tuf/issues/1248. Closing...


Fixed the reference to deeplizard's YouTube channel

Now the link correctly references deeplizard's channel

Didn't check that. Thanks for the fix :)


add support child frames

Summary

When I pass child frame instance to expectPuppeteer, I get error Frame is not supported.
  const frame = page.frames().find(frame => frame.name() === 'myframe');
  const text = expectPuppeteer(frame).toClick('.selector');

Hello @Mavrin, thanks for your work, it is very good!

@neoziro Could you make a release?


chore(main): release veto 0.6.0

:robot: I have created a release beep boop
0.6.0 (2024-11-28)
Features

veto: complete refactor of error formatting + package structure (90a119e)

Bug Fixes

uniform: start fixing the validation errors (87af8b4)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

veto-v0.6.0
:sunflower:


[BugFix] YieldByTimeLimit Less than expected.

What type of PR is this：

[x] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Which issues of this PR fixes ：

Fixes #
Problem Summary(Required) ：

The YieldByTimeLimit value will be lower than expected because
If time_spent is greater than the YIELD_MAX_TIME_SPENT, he will exit on the last IF, so the place will always be false.
I think it makes more sense to change YIELD_MAX_TIME_SPENT to YIELD_PREEMPT_MAX_TIME_SPENT.
Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] I have added user document for my new feature or new function

@ZiheLiu

We could just COUNTER_UPDATE(_yield_by_time_limit_counter, 1) in the if block.
            if (time_spent >= YIELD_MAX_TIME_SPENT) {
                should_yield = true;
                COUNTER_UPDATE(_yield_by_time_limit_counter, 1);
                break;
            }
            if (_workgroup != nullptr && time_spent >= YIELD_PREEMPT_MAX_TIME_SPENT &&
                _workgroup->driver_sched_entity()->in_queue()->should_yield(this, time_spent)) {
                should_yield = true;
                COUNTER_UPDATE(_yield_by_time_limit_counter, 1);
                break;
            }

run starrocks_admit_test

run starrocks_admit_test

@Mergifyio backport branch-2.2 branch-2.3 branch-2.4


Updated reason special-types list in reason-mode

removed old rust types
added a few reason/ocaml types that were missing
changed the special types to be using builtin-face instead of type-face

Thanks!

cc @yunxing


Allow spawned daemon processes to remain running

I'm slightly perplexed as to how this used to work, but testing either way shows that the daemon processes spawned by hyp daemon start have a tendency to terminate if they are launched without disconnecting their stdio from the parent process.

What's the easiest way to test this locally? 🤔

What's the easiest way to test this locally? 🤔

Pull this fork to test the fix locally: https://github.com/specious/cli/tree/fix/daemon-start

This fix didn't work for me.

Please get this merged in. It's giving me headaches :sweat_smile.

@mafintosh, could you please take a quick look at this?

@pfrazee, no doubt you are busy, but all you need to do is merge and push to npm.

@andrewosh, maybe you could take a quick look?

@specious hi! we've been focused on making the latest hypercore and hyperdrive (see the -next repos). i suggest you take a look at those. we'll be deprecating the deamon when those land, as they allow for much easier "embedded" workflows so you don't need a daemon at all which is nice.
suggest you join the discord if you wanna know more :)

That's quite exciting, but merging this pull request would fix the version that people are currently trying to use.

@mafintosh Can we get this merged and publish a patch? I'm installing this globally with npm i @hyperspace/cli -g and manually editing this file to make it work. I realize you are working on more important things that will be coming out, but there are people relying on this to make it work on node 16.

@ralphtheninja Same. I came across this project today and I wanted to give it a try. NodeJS LTS installed, everything fine... but what... it does not work! Would really appreciate if this was merged.

For the time being, we can install it directly from this pull request:
npm i -g hypercore-protocol/cli#pull/57/head

For the time being, we can install it directly from this pull request:

I had no clue you could do this. Very nice!


Decreasing the lightening factor from 1.7 to 1 for sparkle color in the light theme

Fixes https://github.com/microsoft/vscode/issues/199748
It would look as follows for the Github Light Default Theme:

I took a gif here:
https://github.com/microsoft/vscode/assets/61460952/e9c29e65-ae88-4ad1-8e8a-09bf10e16d75


regridder multi threaded dask workers

I'm trying to interpolate a section from a curvilinear grid. I'm running an acoustic transmission loss model and need to extract sections from a model at differing bearings from a point. I've written my code as an xarray accessor.
    @dask.delayed
    def _interp(self,ds,bearing,longitude,latitude,maxrange,rangestep,method):
            qlon,qlat,ranges,b=_make_line(longitude,latitude,bearing,maxrange,rangestep)
            ngrid =xr.Dataset(coords={'lat':qlat,'lon':qlon})
            regridder = xe.Regridder( ds, ngrid,method,filename=str(uuid.uuid4()).replace('-','_')+'.nc')
            sp = regridder(ds)
            sp = sp.isel(lat=xr.DataArray(range(0,len(ranges)), dims="range", coords={"range": ranges}),
                         lon=xr.DataArray(range(0,len(ranges)), dims="range"))
            sp['soundspeed'] = _calcsoundspeed_pt(sp.salt,
                                            sp.temp,
                                            sp.zc)

            sp.zc.values =  abs(sp.zc)
            soundsl = sp.sortby(sp.zc)
            soundsl = soundsl.rename({'k':'depth'})
            soundsl = soundsl.set_index({'depth':'zc'})
            soundsl.coords['bearing'] = bearing
            soundsl.attrs['rangestep'] = rangestep
            soundsl.attrs['maxrange'] = maxrange
            soundsl.attrs['paramhead'] = self._obj.attrs['paramhead']
            soundsl.attrs['paramfile'] = self._obj.attrs['paramfile']
            soundsl.attrs['method'] = method
            soundsl = soundsl.rename({'lon':'longitude', 'lat':'latitude'})
            regridder.clean_weight_file()
            return soundsl

    def soundslice(self,longitude,latitude,bearing,maxrange,rangestep,method='bilinear'):
        ds = self._obj.rename({'longitude': 'lon', 'latitude': 'lat'})
        slices = [ self._interp(ds,bstep,longitude,latitude,maxrange,rangestep,method)for bstep in bearing]
        return xr.concat(dask.compute(*slices),dim='bearing')

If I have a dask cluster with 1 thread per worker all is good. If I have multiple threads then the code executes first time correctly then second or third time I get:
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-8-adb3f6c0b2ed> in <module>
----> 1 sslice = model_run.sel(time=slice('2018-11-01T00:00:00','2018-11-02T00:00:00'))[['temp','salt','botz']].shoc.soundslice(114.5,-31.7,[90],10000,1000)

~/roampy/roampy/shoc.py in soundslice(self, longitude, latitude, bearing, maxrange, rangestep, method)
     60         ds = self._obj.rename({'longitude': 'lon', 'latitude': 'lat'})
     61         slices = [ self._interp(ds,bstep,longitude,latitude,maxrange,rangestep,method)for bstep in bearing]
---> 62         return xr.concat(dask.compute(*slices),dim='bearing')
     63
     64

~/miniconda3/envs/dev2/lib/python3.8/site-packages/dask/base.py in compute(*args, **kwargs)
    435     keys = [x.__dask_keys__() for x in collections]
    436     postcomputes = [x.__dask_postcompute__() for x in collections]
--> 437     results = schedule(dsk, keys, **kwargs)
    438     return repack([f(r, *a) for r, (f, a) in zip(results, postcomputes)])
    439

~/miniconda3/envs/dev2/lib/python3.8/site-packages/distributed/client.py in get(self, dsk, keys, restrictions, loose_restrictions, resources, sync, asynchronous, direct, retries, priority, fifo_timeout, actors, **kwargs)
   2593                     should_rejoin = False
   2594             try:
-> 2595                 results = self.gather(packed, asynchronous=asynchronous, direct=direct)
   2596             finally:
   2597                 for f in futures.values():

~/miniconda3/envs/dev2/lib/python3.8/site-packages/distributed/client.py in gather(self, futures, errors, direct, asynchronous)
   1885             else:
   1886                 local_worker = None
-> 1887             return self.sync(
   1888                 self._gather,
   1889                 futures,

~/miniconda3/envs/dev2/lib/python3.8/site-packages/distributed/client.py in sync(self, func, asynchronous, callback_timeout, *args, **kwargs)
    777             return future
    778         else:
--> 779             return sync(
    780                 self.loop, func, *args, callback_timeout=callback_timeout, **kwargs
    781             )

~/miniconda3/envs/dev2/lib/python3.8/site-packages/distributed/utils.py in sync(loop, func, callback_timeout, *args, **kwargs)
    346     if error[0]:
    347         typ, exc, tb = error[0]
--> 348         raise exc.with_traceback(tb)
    349     else:
    350         return result[0]

~/miniconda3/envs/dev2/lib/python3.8/site-packages/distributed/utils.py in f()
    330             if callback_timeout is not None:
    331                 future = asyncio.wait_for(future, callback_timeout)
--> 332             result[0] = yield future
    333         except Exception as exc:
    334             error[0] = sys.exc_info()

~/miniconda3/envs/dev2/lib/python3.8/site-packages/tornado/gen.py in run(self)
    733
    734                     try:
--> 735                         value = future.result()
    736                     except Exception:
    737                         exc_info = sys.exc_info()

~/miniconda3/envs/dev2/lib/python3.8/site-packages/distributed/client.py in _gather(self, futures, errors, direct, local_worker)
   1750                             exc = CancelledError(key)
   1751                         else:
-> 1752                             raise exception.with_traceback(traceback)
   1753                         raise exc
   1754                     if errors == "skip":

~/roampy/roampy/shoc.py in _interp()
     35             qlon,qlat,ranges,b=_make_line(longitude,latitude,bearing,maxrange,rangestep)
     36             ngrid =xr.Dataset(coords={'lat':qlat,'lon':qlon})
---> 37             regridder = xe.Regridder( ds, ngrid,method,filename=str(uuid.uuid4()).replace('-','_')+'.nc')
     38             sp = regridder(ds)
     39             sp = sp.isel(lat=xr.DataArray(range(0,len(ranges)), dims="range", coords={"range": ranges}),

~/miniconda3/envs/dev2/lib/python3.8/site-packages/xesmf/frontend.py in __init__()
    188             self._grid_in, shape_in = ds_to_ESMFlocstream(ds_in)
    189         else:
--> 190             self._grid_in, shape_in = ds_to_ESMFgrid(ds_in,
    191                                                      need_bounds=self.need_bounds,
    192                                                      periodic=periodic

~/miniconda3/envs/dev2/lib/python3.8/site-packages/xesmf/frontend.py in ds_to_ESMFgrid()
     62
     63     # tranpose the arrays so they become Fortran-ordered
---> 64     grid = esmf_grid(lon.T, lat.T, periodic=periodic)
     65
     66     if need_bounds:

~/miniconda3/envs/dev2/lib/python3.8/site-packages/xesmf/backend.py in esmf_grid()
     99     # However, they actually need to be set explicitly,
    100     # otherwise grid._coord_sys and grid._staggerloc will still be None.
--> 101     grid = ESMF.Grid(np.array(lon.shape), staggerloc=staggerloc,
    102                      coord_sys=ESMF.CoordSys.SPH_DEG,
    103                      num_peri_dims=num_peri_dims)

~/miniconda3/envs/dev2/lib/python3.8/site-packages/ESMF/util/decorators.py in new_func()
     62
     63         esmp = esmpymanager.Manager(debug = False)
---> 64         return func(*args, **kwargs)
     65     return new_func
     66

~/miniconda3/envs/dev2/lib/python3.8/site-packages/ESMF/api/grid.py in __init__()
    383             self._struct = ESMP_GridStruct()
    384             if self.num_peri_dims == 0:
--> 385                 self._struct = ESMP_GridCreateNoPeriDim(self.max_index,
    386                                                        coordSys=coord_sys,
    387                                                        coordTypeKind=coord_typekind)

~/miniconda3/envs/dev2/lib/python3.8/site-packages/ESMF/interface/cbindings.py in ESMP_GridCreateNoPeriDim()
    558     rc = lrc.value
    559     if rc != constants._ESMP_SUCCESS:
--> 560         raise ValueError('ESMC_GridCreateNoPeriDim() failed with rc = '+str(rc)+
    561                         '.    '+constants._errmsg)
    562

ValueError: ESMC_GridCreateNoPeriDim() failed with rc = 545.    Please check the log files (named "*ESMF_LogFile").

I known this is probably not the usual use case for this package but it works nicely. Any thoughts on how to just interplate along a line would also be greatly received.

I've run into similar errors using xesmf in parallel applications, and it has usually been an issue with the regridder files being stored on disk. You might solve this by keeping the weight file and setting reuse_weights to True.
Any updates on the new API that makes use of in-memory storage for regridder weights?

I'd be interested in the in-memory storage for regridder weights too, as I'm running into the 545 error as well. My use case is regridding ~50 CMIP climate model fields that exist on all different grids to a common grid. Was trying to use dask.delayed to set up the ~50 calls to a regridding function (that creates an xesmf regridder and regrids) and dask.compute to then do all the regridding but it's a no go.
I tested with:
def my_regrid_func( xarraydataset, dst_grid )
regridder=xe.regridder( xarraydataset, dst_grid, 'bilinear' )
var_regrid=regridder( xarraydataset[ 'var' ] )
outDS=xr.Dataset( { var : var_regrid } )
outDS.to_netcdf( path )
result1=dask.delayed( my_regrid_func )( xarraydataset1, dst_grid )
dask.compute( result1 )
result2=dask.delayed( my_regrid_func )( xarraydataset2, dst_grid )
dask.compute( result2 )
If there's a solution for embarrassingly parallel xesmf/dask regridding that I haven't found yet, please advise thanks

Check out the new pangeo-data fork of this package, which has a number of updates including in-memory weights storage.

Same problem here.  I am using xarray to read very large files from model output. I created a custom generator to read one time step at a time, regrid and feed it to a NN model. First time around works fine, second time I get this error:
File "/discover/nobackup/dbarahon/bin/conda/envs/tf_keras/lib/python3.8/site-packages/ESMF/interface/cbindings.py", line 528, in ESMP_GridCreate1PeriDim
raise ValueError('ESMC_GridCreate() failed with rc = '+str(rc)+'.    '+
These are the relevant parts of the code:
def train_gen(dts_per_epoch):
st = 0
epoch = 1
while True:
if st < 1:
X, y, blcks = get_dts(print_files = True)
st += 1
b = np.random.randint(0, blcks-1, 1) # select a random block of size batch size
print ('_block', b, '')
xb = Xall.data.blocks[b]
xb1 = xb.compute()
xb2 = np.asarray(xb1)
#print (xb2.shape)
yb = yall.data.blocks[b]
yb1 = yb.compute()
yb2 = np.asarray(yb1)
# print (yb2.shape)
yield( xb2, yb2)
xb2 = []
yb2 = []
print('st',st)
if st > dts_per_epoch:
st  = 0
def get_dts():
....
lat= dat_in['lat'].values
lon = dat_in['lon'].values
grid_out = xr.Dataset({'lat': (['lat'], lat ),
'lon': (['lon'], lon),
})
regridder = xe.Regridder(Wc, grid_out , 'bilinear', filename='regrid.nc', periodic=True, reuse_weights=True)
y =  regridder(Wc)
...

I've run into similar errors using xesmf in parallel applications, and it has usually been an issue with the regridder files being stored on disk. You might solve this by keeping the weight file and setting reuse_weights to True.

Set reuse_weights = True do not solve this problem completely , it also raises same error sometimes.
Also i install pangeo-data fork  and this problem still exist.
This problem really bother me, cause both of dask.distributed cluster and xesmf are all effective tools i want use.


Quarantine flaky operator replicas test

What this PR does / why we need it:
Quarantine flaky operator replicas test:
- [Serial][sig-operator]Operator Replicas should update new single-replica CRs with a finalizer and be stable
Test is failing regularly in periodic and presubmit lanes.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
/cc @dhiller @jean-edouard
Release note:

NONE

/hold
There are obvious issues with this test, I'm working on a fix

https://github.com/kubevirt/kubevirt/pull/8095


Faulty setup appears as running, but fails to create first user

On K8s, upon a faulty setup, the components all show as up and running, but the storage may still not work.
In the particular case, DLService came up as it was able to connect to Riak. Riak did not succeed to form a cluster ring (one node still pending to join), but each riak node was responding to ping (no error, no restarts). DLService was able to connect to Riak, but probably didn't succeed in writing as the number of nodes was too low to achieve required number of replicas. Still, all components come up and show as running.
The first operation a user would do is to either create a user or login. When the DLService is degraded and can't store data, it simply results with "False" to operations. When Managementservice fails to store a new user, it returns and the GUI redirects the user to the login page with no information as to whether signing up was successful. Only by looking closely going through all component logs, it can be detected that there are problems and it requires familiarity with all the components to fix the faulty setup.

I think the prolongued Riak start-up script doesn't solve this entirely.
When we setup a single-node Riak cluster, the DatalayerService starts successfully, but can't write any data to Riak. In the logs it may show up that it can't create enough replicas. But that error doesn't get propagated to the workflows (management and user). A write only returns with false and the workflow can only guess the reason. One would need to dig down into the logs of DLService to find the cause. Should the platform retry failed writes? Should it maybe propagate back to the client that the workflow invocation failed with a proper reason?

Isn't the prolonged riak start-up essentially aiming to prevent a faulty setup to start with?
Of course, there may be other problems during runtime and they would have to handled, perhaps with additional measures.

ok, the particular case had a Riak node stuck in "joining". I think @ruichuan added a 5 second sleep in #73 to address this particular case. It'd be safer to fail the pod in the else branch ... but okay, when that ensures the Riak cluster comes up working, we might still have a setup that is degraded for other reasons but the components would be shown as up and running. E.g. when the DL looses connectivity to Riak, it still serves storage operations, but this is not shown to the user.
But agree, this particular issue is on the case that a Riak node is stuck in joining and #73 is supposed to fix this.
/close


feature/#1294 - additional offset parameters for IMapController.animateTo

New class:

SampleAnimateToOffset: demo about the new offset parameters of IMapController.animateTo - demo that can be reached at "More Samples / Events / Animate To with Offsets"

Impacted classes:

IMapController: additional version of method animateTo, with the extra int offset parameters
MapController: additional version of method animateTo, with the extra int offset parameters, with its impacts on inner class MapAnimatorListener, ReplayController and ReplayClass; gentle refactoring
SampleFactory: added the reference to the new SampleAnimateToOffset demo

It would be better to have more points to get the idea across.  I added below code but the effect is not what I want.
        final GeoPoint geoPoint = mList.get(pIndex % mList.size());
        final Double bearing = mList.get(prevIndex % mList.size()).bearingTo(geoPoint);
        final Float orientation = bearing.floatValue();

See https://youtu.be/5TyETWpzJPw?t=696 for the effect.

Closing this PR as the solution does not seem to be related to animateTo, but intrinsicly to the MapView instead: "I want that each time I use MapView.setExpectedCenter, I go to the same screen pixel and it can be something different from the screen center (which is the default behavior)".


Add support for writing of 3D Tiff images

The current version of function dip::ImageWriteTiff does not support writing 3D images. This pull request adds support for this, using TIFFWriteDirectory. It also adds some additional tests, to ensure the behavior is properly implemented.
If anything is missing, feel free to let me know.

Thank you so very much!


Serverless: Aurora 2.07.1 MySQL 5.7 and encrypted_storage parameter fix

what

existing MySQL Serverless example caught up with module code.
A newer MySQL 5.7 serverless example added.

why

Examples that work are always nice.

/rebuild-readme

/test all


[ENHANCEMENT] stop in "INFO:NLTK setup:downloading nltk data...."

when i run docker run --name marqo -it --privileged -p 8882:8882 --add-host host.docker.internal:host-gateway marqoai/marqo:latest, the progress stop in "INFO:NLTK setup:downloading nltk data...." for 2 days.
can you provide an post download method to skip this step when we excute "docker run..."?

@pandu-k @wanliAlex

Thank you for raising the issue. We will investigate on it and get back to you soon.

Hi @achao2013 , would you be able to provide the following:

The OS you are using
The marqo version
Would you be able to provide a screenshot of what the logs are producing?
If you have tried to start marqo again
If I understand it correctly, it is not getting past the download step - is that correct?

ubuntu 18.04, version 0.0.11, screenshot lost because i have downloaded it in a good network enviroment. "If I understand it correctly, it is not getting past the download step - is that correct?" -yes, i recommend to provide an post download method to skip download step


Typos in Sorting Section

https://github.com/MicrosoftDocs/WindowsCommunityToolkitDocs/issues/241

Docs Build status updates of commit a7710c5:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/controls/datagrid_guidance/group_sort_filter.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


weekly image cve patching from Sec Pipelines

weekly image cve patching from Sec Pipelines

this should be merged IF we already publish image with previous patch versions, otherwise merge https://github.com/Azure/AgentBaker/pull/2827


no LICENSE file

You have "license": "MIT" in package.json, however no corresponding LICENSE file in the repo.
Some tools (e.g. fossa.io) will complain that code is 'Unlicensed'.
Plus Github did not show what is a license for that project.

Thanks.
The LICENSE file was in the '/src' directory and not the '/' directory.


blocks/certifier: use sql database directly

related: https://github.com/spacemeshos/go-spacemesh/issues/5039
it wasn't using any methods that are caching state, so it is a simple cleanup.

bors merge

all tests got interrupted with

logger.go:130: 2024-02-06T16:09:54.874Z	WARN	TestFallback	proposals stream error	***"client": "smesher-11", "error": "rpc error: code = Unavailable desc = closing transport due to: connection error: desc = \"error reading from server: EOF\", received prior goaway: code: NO_ERROR, debug data: \"graceful_stop\"", "status": "rpc error: code = Unavailable desc = closing transport due to: connection error: desc = \"error reading from server: EOF\", received prior goaway: code: NO_ERROR, debug data: \"graceful_stop\""***

bors merge


Telemetry server randomly crashes with segmentation fault

Error message log:
$ npm start

><EMAIL_ADDRESS>start /Users/nunoguedelha/dev/yarp-openmct/iCubTelemVizServer
> . ${NVM_DIR}/nvm.sh; nvm use v4.2.2; node ${NODE_DEBUG_OPTION} iCubTelemVizServer.js

Now using node v4.2.2 (npm v2.14.7)
iCub Telemetry server launched!
[INFO] |yarp.os.Port| Port /yarpjs/inertial:i active at tcp://<IP_ADDRESS>:10117/
[INFO] |yarp.os.impl.PortCoreInputUnit| Receiving input from /icubSim/inertial to /yarpjs/inertial:i using tcp
[INFO] |yarp.os.Port| Port /yarpjs/left_leg/stateExt:o active at tcp://<IP_ADDRESS>:10118/
[INFO] |yarp.os.impl.PortCoreInputUnit| Receiving input from /icubSim/left_leg/stateExt:o to /yarpjs/left_leg/stateExt:o using tcp
[INFO] |yarp.os.Port| Port /yarpjs/camLeftEye:i active at tcp://<IP_ADDRESS>:10119/
[INFO] |yarp.os.Port| Port /yarpjs/camRightEye:i active at tcp://<IP_ADDRESS>:10120/
[INFO] |yarp.os.Port| Port /yarpjs/left_leg/cartesianEndEffectorWrench:i active at tcp://<IP_ADDRESS>:10121/
[INFO] |yarp.os.impl.PortCoreInputUnit| Receiving input from /wholeBodyDynamics/left_leg/cartesianEndEffectorWrench:o to /yarpjs/left_leg/cartesianEndEffectorWrench:i using tcp
[INFO] |yarp.os.Port| Port /yarpjs/right_leg/cartesianEndEffectorWrench:i active at tcp://<IP_ADDRESS>:10122/
[INFO] |yarp.os.impl.PortCoreInputUnit| Receiving input from /wholeBodyDynamics/right_leg/cartesianEndEffectorWrench:o to /yarpjs/right_leg/cartesianEndEffectorWrench:i using tcp
[INFO] |yarp.os.Port| Port /yarpjs/battery/data:i active at tcp://<IP_ADDRESS>:10123/
[INFO] |yarp.os.Port| Port /yarpjs/sysCmdsGenerator/rpc active at tcp://<IP_ADDRESS>:10124/
{ status: 'OK',
  message: 'Opem-MCT static server process started.' }
ICubTelemetry History hosted at http://localhost:8081/history
ICubTelemetry Realtime hosted at ws://localhost:8081/realtime
listening on http://localhost:3000
[OPEN-MCT STATIC SERVER] stdout: Now using node v14.17.0 (npm v6.14.13)

[OPEN-MCT STATIC SERVER] ipc: {"pid":53686}
[OPEN-MCT STATIC SERVER] stdout: iCub Telemetry Visualizer (Open MCT based) hosted at http://localhost:8080

sh: line 1: 53399 Segmentation fault: 11  node ${NODE_DEBUG_OPTION} iCubTelemVizServer.js

npm ERR! Darwin 19.6.0
npm ERR! argv "/Users/nunoguedelha/.nvm/versions/node/v4.2.2/bin/node" "/Users/nunoguedelha/.nvm/versions/node/v4.2.2/bin/npm" "start"
npm ERR! node v4.2.2
npm ERR! npm  v2.14.7
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>start: `. ${NVM_DIR}/nvm.sh; nvm use v4.2.2; node ${NODE_DEBUG_OPTION} iCubTelemVizServer.js`
npm ERR! Exit status 139
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>start script '. ${NVM_DIR}/nvm.sh; nvm use v4.2.2; node ${NODE_DEBUG_OPTION} iCubTelemVizServer.js'.
npm ERR! This is most likely a problem with the iCubTelemVizServer package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     . ${NVM_DIR}/nvm.sh; nvm use v4.2.2; node ${NODE_DEBUG_OPTION} iCubTelemVizServer.js
npm ERR! You can get their info via:
npm ERR!     npm owner ls iCubTelemVizServer
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/nunoguedelha/dev/yarp-openmct/iCubTelemVizServer/npm-debug.log

Today it has been difficult to reproduce the issue.
recurrent error:
Every time it occurred, the terminal error log is always the same as the one in the description.
npm ERR! Exit status 139

Node.js exited with error 139. As per the exit codes in https://nodejs.org/api/process.html#exit-codes, the error code = (128+11),

Signal Exits: If Node.js receives a fatal signal such as SIGKILL or SIGHUP, then its exit code will be 128 plus the value of the signal code.

...so the actual signal code is 11, which matches the same segmentation we see in the terminal log.
Which process died?
That segmentation fault occurred in the Node.js main process running the script iCubTelemVizServer.js. Actually, after the fatal error shuts down the process, the child process running the Open MCT Static Server openmctStaticServer/server.js is still on and we can still switch between Telemetry Domain Elements in the visualizer interface.
npm log content
The generated npm-debug.log is always the same, so the very same problem is causing this segmentation fault.
9 verbose stack Exit status 139
9 verbose stack     at EventEmitter.<anonymous> (/Users/nunoguedelha/.nvm/versions/node/v4.2.2/lib/node_modules/npm/lib/utils/lifecycle.js:214:16)
9 verbose stack     at emitTwo (events.js:87:13)
9 verbose stack     at EventEmitter.emit (events.js:172:7)
9 verbose stack     at ChildProcess.<anonymous> (/Users/nunoguedelha/.nvm/versions/node/v4.2.2/lib/node_modules/npm/lib/utils/spawn.js:24:14)
9 verbose stack     at emitTwo (events.js:87:13)
9 verbose stack     at ChildProcess.emit (events.js:172:7)
9 verbose stack     at maybeClose (internal/child_process.js:818:16)
9 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:211:5)

The stack log isn't deep enough as it starts at the callback onexit (9 verbose stack     at Process.ChildProcess._handle.onexit...), so too late. We'll try to get more insight using breakpoint.

I wasn't able to break at the segmentation fault using a breakpoint in internal/child_process.js. the breakpoint works when the intermediate child process (running runModule.sh I suppose) stops, but later on, when the segmentation fault occurs, the process just ends without stopping at the breakpoint.
Here is the breakpoint location w.r.t. the function call tree we expect when the segmentation fault occurs:
Process.ChildProcess._handle.onexit (internal/child_process.js:211:5)
    => maybeClose(subprocess) (internal/child_process.js:818:16)
        => subprocess.emit('close', subprocess.exitCode, subprocess.signalCode);
            => ChildProcess.emit (events.js:172:7)
               ...
                  => procError(er) (lifecycle.js:212)

Another way is to add a listener to the signal SIGSEGV to display stack information or other context information. Although it is not recommended to ad such a listener (https://nodejs.org/api/process.html#signal-events)...

'SIGBUS', 'SIGFPE', 'SIGSEGV' and 'SIGILL', when not raised artificially using kill(2), inherently leave the process in a state from which it is not safe to call JS listeners. Doing so might cause the process to stop responding.

...it's worth trying.
There is actually a package that kind of does the same thing: segfault-handler (https://httptoolkit.tech/blog/how-to-debug-node-segfaults/). We first install the segmentation fault handler:
npm install segfault-handler

then add the following lines to the very beginning of the main application script:
const SegfaultHandler = require('segfault-handler');
SegfaultHandler.registerHandler('crash.log');

The module listens for any SIGSEGV signal, and reports the detailed stack trace that caused it before the process shuts down.

Segfault Handler output
After the segmentation fault occurs, we get the following output log:
PID 61103 received SIGSEGV for address: 0x1ca4be280
0   segfault-handler.node               0x00000001015d40b0 _ZL16segfault_handleriP9__siginfoPv + 304
1   libsystem_platform.dylib            0x00007fff6d0685fd _sigtramp + 29
2   ???                                 0x00000001030288c8 0x0 +<PHONE_NUMBER>
3   libYARP_os.3.4.3.dylib              0x0000000153392252 _ZNK4yarp2os6Bottle8toStringEv + 18
4   YarpJS.node                         0x00000001059120f2 _ZN26YarpJS_BufferedPort_Bottle16_callback_onReadERNSt3__16vectorIN2v85LocalINS2_5ValueEEENS0_9allocatorIS5_EEEE + 50
5   YarpJS.node                         0x0000000105914a9a _ZN15YarpJS_CallbackI19YarpJS_BufferedPortIN4yarp2os6BottleEEE20_internal_worker_endEP9uv_work_si + 90
6   node                                0x0000000100768f02 uv__work_done + 175
7   node                                0x000000010076a9f4 uv__async_event + 65
8   node                                0x000000010076ab77 uv__async_io + 136
9   node                                0x0000000100778f96 uv__io_poll + 1554
10  node                                0x000000010076b02b uv_run + 321
11  node                                0x000000010064825c _ZN4node5StartEiPPc + 583
12  node                                0x0000000100001834 start + 52
13  ???                                 0x0000000000000002 0x0 + 2
sh: line 1: 61103 Segmentation fault: 11  node ${NODE_DEBUG_OPTION} iCubTelemVizServer.js

So, the issue occurs in YarpJS.node, which is the C++ Addon generated by the yarp.js module implementing the Yarp Javascript bindings and socket bridge.
More precisely, the issue occurs in:
<yarp.js repo>/YarpJS/src/YarpJS_BufferedPort_Bottle.cpp:
    --> YarpJS_BufferedPort_Bottle::_callback_onRead(...)
        --> YarpJS_Bottle::ToString()

I realised that the problem might be related to the Yarp version used during the server installation and the one used to run the server are different.
YarpJS.node was generated installation of the servers (using a conda environment "A")and depends on the library libYARP_os.3.4.3.dylib, from Yarp 3.4.3. At least in my case, I'm running the same telemetry server with a different conda environment "B").
I'm doing some further checks:

[ ] Run the setup with only one environment ("A")
[ ] Check the library dependencies in YarpJS.node

Not sure if it can be useful to try to run the server under valgrind or DrMemory to understand if there is some wrong memory access that with low probability results in a segfault.

I'm doing in parallel:

[ ] The analysis of the YarpJS_BufferedPort_Bottle::_callback_onRead and yarp::os::Bottle::toString()
[ ] Memory leak analysis using Valgrind or DrMemory

WIP: Analyse YarpJS_BufferedPort_Bottle::_callback_onRead
4   YarpJS.node                         0x00000001059120f2 _ZN26YarpJS_BufferedPort_Bottle16_callback_onReadERNSt3__16vectorIN2v85LocalINS2_5ValueEEENS0_9allocatorIS5_EEEE + 50

Disassemble YarpJS.node:
$ objdump -dS --line-numbers ./node_modules/YarpJS/build/Release/YarpJS.node

=> address 0x120c0, __ZN26YarpJS_BufferedPort_Bottle16_callback_onReadERNSt3__16vectorIN2v85LocalINS2_5ValueEEENS0_9allocatorIS5_EEEE
Demangled format...
$ objdump -dS --demangle --line-numbers ./node_modules/YarpJS/build/Release/YarpJS.node

00000000000120c0 YarpJS_BufferedPort_Bottle::_callback_onRead(std::__1::vector<v8::Local<v8::Value>, std::__1::allocator<v8::Local<v8::Value> > >&):
   120c0: 55                            pushq   %rbp
   120c1: 48 89 e5                      movq    %rsp, %rbp
   120c4: 41 57                         pushq   %r15
   120c6: 41 56                         pushq   %r14
   ...

0000000000007030 non-virtual thunk to yarp::os::Bottle::toString() const:
    7030: 55                            pushq   %rbp
    7031: 48 89 e5                      movq    %rsp, %rbp
    7034: 53                            pushq   %rbx
    7035: 50                            pushq   %rax
    7036: 48 89 fb                      movq    %rdi, %rbx
    7039: 48 8b 76 28                   movq    40(%rsi), %rsi
    703d: e8 4e b0 06 00                callq   438350 <__ZNK4yarp2os4impl10BottleImpl8toStringEv>
    7042: 48 89 d8                      movq    %rbx, %rax
    7045: 48 83 c4 08                   addq    $8, %rsp
    7049: 5b                            popq    %rbx
    704a: 5d                            popq    %rbp
    704b: c3                            retq
    704c: 0f 1f 40 00                   nopl    (%rax)

Don't know yet how to generate the source code to better understand the failure...

WIP: Memory leak analysis using Valgrind or DrMemory
It was easier to go for Valgrind.
It seems that Valgrind official release (latest is not yet supported on MacOS Catalina (10.15). But there is a modified fork fixing that problem (https://github.com/LouisBrunner/valgrind-macos), which can be installed from source by downloading the repository and building or via homebrew package.
Installation from source:

git clone https://github.com/LouisBrunner/valgrind-macos.git
cd valgrind
sudo ./autogen.sh
sudo ./configure --prefix=/where/you/want/it/installed --enable-only64bit
copy the [contents][1] to ./coregrind/m_mach/mach_basics.c
sudo make
sudo make install

Installation via homebrew:
brew tap LouisBrunner/valgrind
brew install --HEAD LouisBrunner/valgrind/valgrind

Using Valgring requires installing the target modules (YARP) with debugging symbols.

[ ] Update Homebrew on machine.
[ ] Update Conda installation and install latest packages dependencies of the superbuild.
[ ] Install the superbuild (tag 2021.08.1) with YARP project built with debug symbols.

ping @traversaro @S-Dafarra

If we are blocked on this, could it make sense to work on https://github.com/robotology/yarp.js/issues/19 and hope that the situation changes/improves with that? Not really a rational move, but sometimes working on something else leads to fixes to other issues (so-called "serendipity").

Yes, good point. I actually prepared for that as I duplicated my setups, having one for resuming the other development/fixes, and one for running the memory tests on the background.

I'm currently configuring CLion setup for debugging and memory leek analysis. This tool has the approximately the same workflow than Webstorm and integrates already Valgrind, so it's quite promising, even for future eventual issues.

I'm currently configuring CLion setup for debugging and memory leek analysis. This tool has the approximately the same workflow than Webstorm and integrates already Valgrind, so it's quite promising, even for future eventual issues.
Refer to issue https://github.com/robotology/yarp.js/issues/31 and particularly https://github.com/robotology/yarp.js/issues/31#issuecomment-995451574.

Valgrind Configuration
Preferences > Build, Execution, Deployment > Dynamic Analysis Tools > Valgrind:

Valgrind Memceck Analysis of YarpJS Target
We setup a Run/Debug configuration of type "CMake Application" with the following settings:

target library code YarpJS.node C++ adon implementing the Javascript-C++ bindings
executable (has to be the node.js process running the javascript server application): ~/.nvm/versions/node/v14.17.0/bin/node
node argument iCubTelemVizServer.js
Remove the default "before launch" operation build for not building at each run.

I think that a memory leak does not explain a segmentation fault (unless you run out of memory I suppose). What other warnings are there? Anything related to uninitialized memory for example?

Yes, the invalid read was the warning that most worried me, I just did't complete the description in the above comment yet. Anyway, the point is that the issue is occurring in that function call sequence.

Also it might be worth compiling in RelWithDebInfo. If you are running in debug it is possible that the memory is initialized with zeros, that might explain why the segfault is not happening after hours of usage.

Indeed, but I had already reproduced the segfault in the past with the debug build. I'll try anyway with RelWithDebInfo to see if it improves. It might also be related to how the memory is aligned.

I was able to reproduce the segmentation fault after loading the Yarp project under Xcode and attaching to the Node.js process. The debugger breaked on the line causing the segmentation fault occurring after the call sequence:
YarpJS_BufferedPort_Bottle::_callback_onRead() -> yarp::os::Impl::BottleImpl::toString()

Analysing...

I will open later an issue describing the procedure to setup Xcode.

I was able to reproduce the segmentation fault after loading the Yarp project under Xcode and attaching to the Node.js process. The debugger breaked on the line causing the segmentation fault occurring after the call sequence:
YarpJS_BufferedPort_Bottle::_callback_onRead() -> yarp::os::Impl::BottleImpl::toString()

Analysing...

Quick initial analysis...
In line 322 we are dereferencing an invalid address since content size is 0.
Storable& s = *content[i];

content[0] should contain a valid pointer to yarp::os::impl::Storable, but instead has a some random value.
By the way, in line 318
for (unsigned int i = 0; i < content.size(); i++)

i=0 implies that i does fulfill the for loop condition. It's been a while I don't do C++, so I have a doubt here, but I think we shouldn't go into the loop right? @S-Dafarra @traversaro

I was able to reproduce the segmentation fault after loading the Yarp project under Xcode and attaching to the Node.js process. The debugger breaked on the line causing the segmentation fault occurring after the call sequence:
YarpJS_BufferedPort_Bottle::_callback_onRead() -> yarp::os::Impl::BottleImpl::toString()

Analysing...

Quick initial analysis...
In line 322 we are dereferencing an invalid address since content size is 0.
Storable& s = *content[i];

content[0] should contain a valid pointer to yarp::os::impl::Storable, but instead has a some random value.
By the way, in line 318
for (unsigned int i = 0; i < content.size(); i++)

i=0 implies that i does fulfill the for loop condition. It's been a while I don't do C++, so I have a doubt here, but I think we shouldn't go into the loop right? @S-Dafarra @traversaro

This is correct, at least as long as content.size() is 0.

I think there is something fishy. You wrote that in https://github.com/ami-iit/yarp-openmct/issues/51#issuecomment-1008501746 the size is 0, but still you get into the for loop, and you shouldn't. Infact i=0 does not satisfy i < content.size(), hence, you should not get into the floor the loop. If you do, maybe the method size() is also returning garbage, meaning that also content is garbage. So probably, there is where it crashes, but probably the problem is a level above in the stack trace. I wonder if the BottleImpl object on which you are calling toString is valid or not.

I think there is something fishy. You wrote that in #51 (comment) the size is 0, but still you get into the for loop, and you shouldn't. Infact i=0 does not satisfy i < content.size() if content.size() == 0, hence, you should not get into the foor loop.

yes that was what stroke me most.

If you do, maybe the method size() is also returning garbage...I wonder if the BottleImpl object on which you are calling toString is valid or not.

I have the full function call sequence before the segfault in Xcode environment, so we can check all that.

Just a clarification with respect to a previous discussion we had during the last software engineering update:
the problem is not related to argv being in a local variable used in the function call tmp_arguments.push_back(cons->NewInstance(Nan::GetCurrentContext(), argc, argv).ToLocalChecked());, as the segfault occurs before that:

I was observing a bottle content always of size 0 even before the segfault, just randomly breaking on the Read callback, so I crosschecked the setup by debugging the code in CLion through the project YarpJS, while using the conda view where I built YARP alone. This time CLion gets the full trace and breaks in the BottleImpl::toString() function as expected:

We can indeed see garbage in the content vector.

Another occurrence of the issue gives:

The elements of the content vector should always be, in this case, one of the following:

yarp::os::impl::StoreList for a nested Bottle,
yarp::os::impl::StoreVocab for a VOCAB,
yarp::os::impl::StoreInt32 or yarp::os::impl::StoreFloat64 for numeric values.

...but neve yarp::os::impl::Storable whcih is the parent more generic class.
We shall analyze if the data was corrupted when the process actually reads the port.

Analyzing now what size() returns...

This became irrelevant as we can have corrupted data at the very beginning of the content vector.

Moving the issue to https://github.com/robotology/yarp.js/issues/32 since we can reproduce it without running yarp-openmct server.
@traversaro @S-Dafarra @RiccardoGrieco


API Console - Swagger UI integration

Description:
API Console tab need swagger ui integration.

Select Access token for the swagger API from different applications which that API is subscribed feature should be there.

Following two issues are reported related to this.
https://github.com/wso2/product-apim/issues/3136
https://github.com/wso2/product-apim/issues/3135


Add Accessibility Note About !important

We're very clear about not using !important (http://webguide.ucsb.edu/css/), but we don't note the accessibility implications (https://github.com/ucsb-wsg/web-accessibility/blob/master/web-accessibility-guidelines.md#guideline-user-override-of-styles).
We need to double-check that !important actually has accessibility implications and, if so, note those.

The accessibility implications aren't severe, since a user-defined !important overrides a website-defined !important, but I think the fact that a user-defined stylesheet must use !important to override !important is enough of a difficulty to note.


upgradeWebSocket helper doesn't support Deno-specific options

What version of Hono are you using?
4.4.6
What runtime/platform is your app running on?
Deno
What steps can reproduce the bug?
I am trying to upgrade my existing code to the WebSocket Helper so I can use hono-rate-limiter with it.
My code looks like this:
const { socket, response } = Deno.upgradeWebSocket(c.req.raw, { protocol: token, idleTimeout: 30 });

However, Hono's UpgradeWebSocket interface does not support the second parameter, Deno.UpgradeWebSocketOptions:
interface UpgradeWebSocketOptions {
  /** Sets the `.protocol` property on the client side web socket to the
    * value provided here, which should be one of the strings specified in the
    * `protocols` parameter when requesting the web socket. This is intended
    * for clients and servers to specify sub-protocols to use to communicate to
    * each other. */
  protocol?: string;
  /** If the client does not respond to this frame with a
    * `pong` within the timeout specified, the connection is deemed
    * unhealthy and is closed. The `close` and `error` event will be emitted.
    *
    * The unit is seconds, with a default of 30.
    * Set to `0` to disable timeouts. */
  idleTimeout?: number;
}

To work around this, I will have to create some adapters in my application code, which is not ideal.
What is the expected behavior?
No response
What do you see instead?
No response
Additional information
No response

I'll try this.

I just realized I cannot actually pass the token in when using it like written in the docs. :facepalm:
const app = new Hono()

app.get(
  '/ws',
  upgradeWebSocket((c) => {
    return {
      onMessage(event, ws) {
        console.log(`Message from client: ${event.data}`)
        ws.send('Hello from server!')
      },
      onClose: () => {
        console.log('Connection closed')
      },
    }
  })
)

Has to become:
const app = new Hono()

app.get(
  '/ws',
  (c, next) => {
    return upgradeWebSocket(() => {
      onMessage(event, ws) {
        console.log(`Message from client: ${event.data}`)
        ws.send('Hello from server!')
      },
      onClose: () => {
        console.log('Connection closed')
      },
    }, { protocol: c.req.header('sec-websocket-protocol') })(c, next)
  }
)

Hi @alexgleason .
It can be used in this way.
const app = new Hono()

app.get(
  '/ws',
  (c, next) => {
    return upgradeWebSocket(() => {
      onMessage(event, ws) {
        console.log(`Message from client: ${event.data}`)
        ws.send('Hello from server!')
      },
      onClose: () => {
        console.log('Connection closed')
      },
    }, { protocol: c.req.header('sec-websocket-protocol') })(c, next)
  }
)

Thank you @EdamAme-x ! :rocket:


fix: yaml js syntax

Summary

copilot:summary
Details

copilot:walkthrough
Related Issue

Checklist

[ ] I have added changeset via pnpm run change.
[ ] I have updated the documentation.
[ ] I have added tests to cover my changes.

!bench-framework