moving custom stuff from /usr/sbin to /usr/local/sbin

/usr/sbin on archlinux is just a symlink, writing files with docker to that location removes the symlink and any future updates of the "filesystem" package will break.
this pullrequest goes along with the corresponding pullrequest to the image-archlinux repository (https://github.com/online-labs/image-archlinux/pull/10)
please keep in mind that i wasn't really able to test these changes since you have a ton of hardcoded urls everywhere, and i'd have had to change all of those just for testing

Thanks a lot for the PR!
We weren't aware of this issue on Archlinux, ; putting stuff in /usr/local/{bin,sbin} looks like a good idea for all other images as well, so I guess we want this everywhere. We can't merge it directly because all other OS images depend on this repository, so we first have to port other images if we don't want to break anything.
cc @moul

Thanks, I can't remember where we talked about this, but we planned to move this last week
I'm merging this now and create an issue on each base images so I will fix images before rebuilding them on monday

All images are ported
Thanks again


how to use with React Player ?

I don't know React Player. Provide your current React Player code and I'll see where to place IIV

`import React, { Component } from 'react'
import ReactPlayer from 'react-player'
class App extends Component {
render () {
return
}
}`

I'm not sure. Perhaps ask in React Player's repo.
IIV needs to run soon after the  element is created and before RPlayer attaches any events to it. It depends on how they implemented it.


notifications: "Groups is gaslighting me"

@jamesacklin I followed up with the original author of this comment. They say that it has not happened to them since this original report.


Remove link in actions/run.py to Interaction

This caused an error in #818
/home/docs/checkouts/readthedocs.org/user_builds/ansible-navigator/envs/818/lib/python3.8/site-packages/ansible_navigator/actions/run.py:docstring of ansible_navigator.actions.run.Action._prepare_to_quit:: WARNING: more than one target found for cross-reference 'Interaction': ansible_navigator.ui_framework.Interaction, ansible_navigator.ui_framework.ui.Interaction

Eventually we would like to carry over the type hints in the signature, so this should be necessary.  (The link to Interaction and None does currently work, it just has to clicked above the return)

It should be noted this did not resolve the error because it was a change in the wrong place.
But, it'll stay in because the ref was not necessary as explained in the description


Support users to only input the kubeconfig path for connecting the k8s cluster

What do these changes do?

Support users to only input the kubeconfig path for connecting the k8s cluster
Get the current kubeconfig for vineyardctl.

Related issue number

Fixes #2796

Codecov Report

Merging #2799 (9b24393) into main (191949b) will decrease coverage by 31.31%.
The diff coverage is 50.00%.

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #2799       +/-   ##
===========================================
- Coverage   73.22%   41.92%   -31.31%
===========================================
  Files          99       99
  Lines       10472    10474        +2
===========================================
- Hits         7668     4391     -3277
- Misses       2804     6083     +3279

Impacted Files
Coverage Δ

python/graphscope/client/session.py
65.52% <50.00%> (-10.57%)
:arrow_down:

... and 52 files with indirect coverage changes

Continue to review full report in Codecov by Sentry.

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


fix: check payload length and consumed buf for pooled tx

This is one of the bugs found by #5125, we were previously allowing decoding of legacy transactions that were shorter than their payload length, as well as legacy transactions that were longer than their payload length. We will need to similarly check header lengths in other manual decodings.
Tests are added that contain RLP strings generated by the fuzzer.

good to merge @Rjected ?

needs rebase @Rjected


Add tests for Java nanojson

request from https://twitter.com/mmastrac/status/791292042383024130

Created #13 for this.

Thanks a lot!


Use v1 contract address from<EMAIL_ADDRESS>

To fix the error (on https://develop.aggregator.z52da5wt.xyz/):

Error: Contract with address ct_2Cvbf3NYZ5DLoaNYAU71t67DdXLHeSXhodkSNifhgd7Xsw28Xd not found on-chain or not active
at Object.x

The old address is taken from https://github.com/aeternity/superhero-ui/blob/1fd0c075441edbe2988fdfd6f70d0f8985f2984a/src/config/constants.js#L11
Shouldn't it be a hotfix?

In this pull request works tip on the feed and retip content on the feed.


Invalid emit for declaring a class that references itself inside of a loop

TypeScript Version:  Version 3.5.0-dev.20190509

Search Terms:
Class inside loop
Uncaught SyntaxError: Illegal return statement
Code
const classesByRow: Record<string, object> = {};
for (const row of ['1', '2', '3', '4', '5']) {
  class RowClass {
    row = row;
    static factory = () => new RowClass();
  }

  classesByRow[row] = RowClass;
}

console.log(classesByRow)

Expected behavior:
When downleveled to ES5 the compiled code runs and logs something like:
{1: ƒ, 2: ƒ, 3: ƒ, 4: ƒ, 5: ƒ}
  1: class RowClass
  2: class RowClass
  3: class RowClass
  4: class RowClass
  5: class RowClass

Actual behavior:
When downleveled to ES5 the compiled code does not run and throws a syntax error:
Uncaught SyntaxError: Illegal return statement

Playground Link:
https://www.typescriptlang.org/play/index.html#src=const classesByRow%3A Record<string%2C object> %3D {}%3B
for (const row of ['1'%2C '2'%2C '3'%2C '4'%2C '5']) {
  class RowClass {
    row %3D row%3B
    static factory %3D () %3D> new RowClass()%3B
  }

  classesByRow[row] %3D RowClass%3B
}

console.log(classesByRow)
Related Issues:
I could not find any.

When downleveling the ES5 in this weird situation the TS compiler produces JS with either a syntax error or incorrect runtime semantics by placing a return statement where it does not belong. This error seems to happen when a class declared inside of a loop has a property that references itself. The error does not happen when the self-referencing property is removed. To test this, remove line 5 from the above example. This issue is reproducable for every kind of loop, not just for ... of loops, it also comes up when using while loops and for loops.
The bug does not happen when targeting ES2015 or above.
I was able to reproduce this on TS 3.3 as well.

This is still reproducible on TS 3.5.1. Any updates?


JAVA_TOOL_OPTIONS environment variable now set on Ubuntu?

Describe the bug
The JAVA_TOOL_OPTIONS environment variable is set on Ubuntu, which should be the case according to this line. However, this was not the case about a week ago. We noticed this because the environment variable is picked up by an invocation of java --module-path ... --describe-module ....
Area for Triage:
Java
Question, Bug, or Feature?:
Bug
Virtual environments affected

[ ] macOS 10.15
[ ] Ubuntu 16.04 LTS
[x] Ubuntu 18.04 LTS
[ ] Ubuntu 20.04 LTS
[ ] Windows Server 2016 R2
[ ] Windows Server 2019

Expected behavior
JAVA_TOOL_OPTIONS is set, which is the case now.
Actual behavior
JAVA_TOOL_OPTIONS was not set a few days ago.
Current build:
https://github.com/hpi-swa/trufflesqueak/runs/1002639551?check_suite_focus=true
Same commit from three days ago:
https://github.com/hpi-swa/trufflesqueak/runs/990481739?check_suite_focus=true
We are fixing the build failure on our end. Nonetheless, it is unclear why JAVA_TOOL_OPTIONS is now set on Ubuntu. The two workers seem to run the identical software version. Could someone explain this please?

Hello @fniephaus,
I have checked the issue. I believe the issue is not related to the JAVA_TOOL_OPTIONS environment variable. As far as I see, in the pipeline error message:
AssertionError: ('HAMCREST', 'hamcrest', ['Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8', 'hamcrest file:///home/runner/.mx/cache/HAMCREST_42a25dc3219429f0e5d060061f71acb49bf010a0/hamcrest.jar automatic', 'requires java.base mandated', 'contains org.hamcrest', 'contains org.hamcrest.core', 'contains org.hamcrest.internal'])
This issue is Java-related and I think there is some issue in the code.
Please note that JAVA_TOOL_OPTIONS variable was not changed in the latest Ubuntu releases.
We are looking forward to your reply.

Correct, the build broke because of the AssertionError, and as I said we are fixing this. However, it is unclear why this wasn't a problem three days ago. JAVA_TOOL_OPTIONS was very likely not set, but why?

@fniephaus , it definitely was set.
Both builds (failed and successful) were run on the same image version 20200806.0 (you can check it on Set up job step). It means that both builds were run on identical VMs.
Could it be some issue with your environment that could override or block environment variables on VM?

Could it be some issue with your environment that could override or block environment variables on VM?

I don't think so, but it's not impossible. Both jobs were using an identical JDK and called out to java --module-path ... --describe-module ..., which checks JAVA_TOOL_OPTIONS  and print Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8.
But anyway, we have fixed the issue on our end. Just wanted to double check that the environment has definitely not changed. Thanks for the swift response!

@fniephaus I bumped the same issue. How have you fixed it?

If you're a Truffle language dev and you use mx, update it. The fix is already available. If you don't know what I am talking about, you could try unsetting the environment variable before your script runs.

I'm Ruby dev. One of the gems in my project uses Java which raises the error. Anyway unsetting the environment variable helps. Thank you very much @fniephaus

In that case, let me reopen this issue. What do you think, @maxim-lobanov?

Since JAVA_TOOL_OPTIONS produces extra output I think it's going to be problematic for many cases.

Unfortunately, I don't have context why this variable was set initially.
The single concern from my side about unsetting it is that it could affect customers who are expecting this variable to be set up.
We are not Java experts so if you can provide any context what JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF8 param does and how unsetting could affect existing customers, it would be helpful

JAVA_TOOL_OPTIONS "can be useful to augment a command line". In this case, it does what the flag suggests: set the file encoding to UTF8. Here is a related JEP, its status however is still "draft". Git unfortunately doesn't tell us much why this environment variable is set (https://github.com/actions/virtual-environments/commit/f396818e23ecba9f79322615a55d190765a5fab5 is the commit). If we remove it, the JVM will fall back to the default encoding (whatever that is on each platform). It appears that JAVA_TOOL_OPTIONS is a problem for other projects as well, e.g.:

https://github.com/ballerina-platform/ballerina-lang/commit/60e12e3dfbfdde60074c8864df4a2d44bd06e141
https://github.com/relaton/relaton-ietf/commit/7bea391980b4c5cbd12a81dc9e9977de052ddd28#diff-a77b4f53dac18d1e289021f245022811
https://github.com/dazuma/toys/blob/c4f2aac1f0c553ce796b64adc68d2465f9aa7bfd/.github/workflows/ci.yml#L39

cc: @brunoborges for any thoughts

JAVA_TOOL_OPTIONS "can be useful to augment a command line". In this case, it does what the flag suggests: set the file encoding to UTF8. Here is a related JEP, its status however is still "draft". Git unfortunately doesn't tell us much why this environment variable is set (f396818 is the commit). If we remove it, the JVM will fall back to the default encoding (whatever that is on each platform). It appears that JAVA_TOOL_OPTIONS is a problem for other projects as well, e.g.:

ballerina-platform/ballerina-lang@60e12e3

Yes, we also observed assertion failures due to the additional output
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8.

relaton/relaton-ietf@7bea391#diff-a77b4f53dac18d1e289021f245022811
https://github.com/dazuma/toys/blob/c4f2aac1f0c553ce796b64adc68d2465f9aa7bfd/.github/workflows/ci.yml#L39

Images without JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF8 were deployed. This issue can be closed.


Relax monotony requirement for abscissa values of Modelica.Math.Vectors.interpolate

Reported by beutlich on 20 Aug 2014 07:12 UTC
In Modelica.Math.Vectors.interpolate the description of the abscissa table vector claims that strict monotonically increasing values are required. This strong limitation can be weakend in the same sense as Modelica.Math.tempInterpol1 that only the first and second value and the second to last and last value need to be strictly increasing, i.e. the inner abscissa values are only required to be monotonically increasing. Thus I propose to adapt the description comment of the abscissa values. No change in algorithm is necessary.

Migrated-From: https://trac.modelica.org/Modelica/ticket/1555

Comment by otter on 3 Jan 2015 22:04 UTC
Fixed in 1b968bce0bc053cd0acf863d891cf2cdd62f4b2e (in trunk):

Fixed as suggested (improved the documentation that abscissa values might be monotonous).
Added some test examples in ModelicaTest.Math.Vectors.

Modified by beutlich on 28 Sep 2015 11:26 UTC

Changelog modified by beutlich on 28 Sep 2015 11:26 UTC
Fixed documentation of Modelica.Math.Vectors.interpolate


Nicer Dashboard

Feature Description
Hi.
Thanks for this amazing work. I was wondering, if you plan to make the actual dashboard more usable.
I'm looking for something, that I can run on my tablet, displaying my accessories in a nice and controlable way. Best would be, if I can sort my this dashboard per drag and drop.
In was searching for something like this, but it seems like this is not available...

I love the smell of unmaintained Software.. not


Log errors in stderr of sfdx commands during source conversion

Changes

Errors from sfdx while converting source format in the MetaDataPackageZipBuilder class are now raised in the exception message.

Suggested edit for release note (and I'd consider this an Issue closed): Improved logging of errors from sfdx while converting sfdx format metadata to deploy via the Metadata API, so that they are not lost when CumulusCI is embedded in another system like MetaCI or Metecho.


Variance is not calculated correctly in some cases + inconsistent definition

The var method acts inconsistently when used on the Series vs the numpy array returned from values:
dat = pd.DataFrame({'x': [1,2,3,4,0,0,0]})
print(dat['x'].values.var())
print(dat['x'].var())

Prints:
2.24489795918
2.61904761905

This is due to numpy using ddof=0 as its default (calculates the biased variance), whereas pandas calculates the unbiased variance by default. These two should be consistent, so either pandas should adapt or numpy should (maybe it should be numpy since we should calculate unbiased by default?).
The other problem is that pandas does not calculate the variance of this DataFrame properly.
Inconsistent definition aside, the variance should clearly not be zero when calculated from pandas.
dat = pd.DataFrame({'x': [9.0692124699,9.0692124692,9.0692124702,9.0692124686,
                          9.0692124687,9.0692124707,9.0692124679,9.0692124685,
                          9.0692124698,9.0692124719,9.0692124698,9.0692124692,
                          9.0692124689,9.0692124673,9.0692124707,9.0692124714,
                          9.0692124714,9.0692124734,9.0692124719,9.0692124710,
                          9.0692124694,9.0692124705,9.0692124713,9.0692124717
]})
print(dat['x'].values.var())
print(dat['x'].var())

Prints:
2.06817742558e-18
0.0

Here is the system information:
INSTALLED VERSIONS:
commit: None
python: 3.4.0.final.0
python-bits: 64
OS: Linux
OS-release: 3.13.0-52-generic
machine: x86_64
processor: x86_64
byteorder: little
LC_ALL: None
LANG: en_CA.UTF-8
pandas: 0.16.1
numpy: 1.9.2

Thanks for the report. The difference is caused by the default of ddof option which specify sample / unbiased variance.
# numpy
dat['x'].values.var()
# 2.2448979591836733
dat['x'].values.var(ddof=True)
# 2.6190476190476186

dat['x'].var()
# 2.6190476190476191
dat['x'].var(ddof=False)
# 2.2448979591836733

It is written in API but easy to miss it... should be listed on parameter section. PR is appreciated.

pandas: http://pandas.pydata.org/pandas-docs/dev/generated/pandas.Series.var.html
numpy: http://docs.scipy.org/doc/numpy/reference/generated/numpy.var.html

Ah I missed latter part.
It should be precise as the same as numpy. Marked as a bug also.

Yeah the latter part is the more concerning.
The first was more of a remark, but it should definitely be added to the parameters list. Might be a good idea to also make it explicit in the docs that numpy assumes a different ddof, and maybe add the example I gave as a caution to users.

I'm trying to trace this back and found the following:
dat = pd.DataFrame({'x': [9.0692124699,9.0692124692,9.0692124702,9.0692124686,
                          9.0692124687,9.0692124707,9.0692124679,9.0692124685,
                          9.0692124698,9.0692124719,9.0692124698,9.0692124692,
                          9.0692124689,9.0692124673,9.0692124707,9.0692124714,
                          9.0692124714,9.0692124734,9.0692124719,9.0692124710,
                          9.0692124694,9.0692124705,9.0692124713,9.0692124717
]})

values = dat['x'].values
# Formula used internally by pandas to calculate the variance (ignoring the final division by N-1):
print(np.sum(values)**2/len(values)-np.sum(values**2))
# Normal variance formula (once again ignoring the final div by N-1):
print(np.sum((values - np.mean(values))**2))

Returns:
0.0
4.96362582139e-17

As far as I can tell these should be exactly equivalent, but for some reason they are not.

do u have bottleneck installed?

@jreback It works fine if bottleneck installed on my environment.
# with bottleneck 1.0.0
dat['x'].var()
# 2.158098183211887e-18
dat['x'].var(ddof=False)
# 2.0681774255780584e-18

As  @NickLH pointed, issue looks to be caused by nanops._nanvar which drops small decimals during squared-sum. Should check there is no side effect though...
# numpy
dat['x'].values.var()
# 2.0681774255780584e-18
dat['x'].values.var(ddof=True)
# 2.158098183211887e-18

dat['x'].var()
# 2.158098183211887e-18
dat['x'].var(ddof=False)
# 2.0681774255780584e-18

No bottleneck... here's the full output of my system
INSTALLED VERSIONS
------------------
commit: None
python: 3.4.0.final.0
python-bits: 64
OS: Linux
OS-release: 3.13.0-52-generic
machine: x86_64
processor: x86_64
byteorder: little
LC_ALL: None
LANG: en_CA.UTF-8

pandas: 0.16.1
nose: 1.3.1
Cython: None
numpy: 1.9.2
scipy: 0.15.1
statsmodels: None
IPython: 1.2.1
sphinx: None
patsy: None
dateutil: 2.4.2
pytz: 2015.4
bottleneck: None
tables: None
numexpr: None
matplotlib: 1.3.1
openpyxl: None
xlrd: None
xlwt: None
xlsxwriter: None
lxml: None
bs4: None
html5lib: 0.999
httplib2: 0.8
apiclient: None
sqlalchemy: None
pymysql: None
psycopg2: None

I think it's a problem with the algorithm that's being used. According to this page on wiki http://en.wikipedia.org/wiki/Algorithms_for_calculating_variance
the algorithm that is being used is the naieve one, which has problems when the values are similar.
Quote:
Because SumSq and (Sum×Sum)⁄n can be very similar numbers, cancellation can lead to the precision of the result to be much less than the inherent precision of the floating-point arithmetic used to perform the computation. Thus this algorithm should not be used in practice.[1][2] This is particularly bad if the standard deviation is small relative to the mean. However, the algorithm can be improved by adopting the method of the assumed mean.
End Quote
The method I used that seems to work is the two pass algorithm mentioned on the wiki article, which is apparently numerically stable except in the case of large n. This is also the algorithm that numpy uses under the hood. See: https://github.com/numpy/numpy/blob/4cbced22a8306d7214a4e18d12e651c034143922/numpy/core/_methods.py (look up '_var').
The good formula (again according to the wiki) that is numerically stable, even for large n is:
def compensated_variance(data):
    n = 0
    sum1 = 0
    for x in data:
        n = n + 1
        sum1 = sum1 + x
    mean = sum1/n

    sum2 = 0
    sum3 = 0
    for x in data:
        sum2 = sum2 + (x - mean)**2
        sum3 = sum3 + (x - mean)
    variance = (sum2 - sum3**2/n)/(n - 1)
    return variance

print(dat['x'].values.var(ddof=1))
print(compensated_variance(dat['x']))

Returns:
Normal: 2.158098183211887e-18
Compensated: 2.1580981832106009e-18

However, the 'correct' value (calculated with Mathematica) is:
2.158098183211887e-18
So the compensated version sacrifices some numerical accuracy to get better stability with large values of n. I do not think we should implement it this way.

look at how roll_var was implemented - this uses weldord method - iirc there is s comment that var should be changed

Implementing it with Welford's method (or the modified one from Knuth that is on that wiki page) would probably slow down the computation, but it is probably worth the small performance drop since we should be trying to get rid of weird roundoff errors such as those I found.
I'm quite busy at the moment, so I cannot work on a patch, but if nobody has taken this on by the time my workload reduces, I'd be happy to contribute.
In the mean time, I suggest that people just use the numpy version:
dat['x'].values.var(ddof=1)

That's what I'll be doing at least...

this would have to be benchmarked, but this is very much an edge case (difference of small numbers). As far as the ddof is concerned, you can simply be explicit.

I took the liberty of opening a small PR to implement Welford's method in group_var_float64 (which is used to compute the variance after grouping by, and also implements the sum-of-squares algorithm). This seems to work quite well, but I wonder if the correct way to go is to fix _nanvar in a similar way, or to have these two methods share the same implementation. I haven't looked at _nanvar in detail, so I don't know if that's feasible.

@jvkersch
_nanvar could also use attention, however its implementation doesn't involve a group indexer, so can be a bit simpler (and is implemented as a vectorized method).

std has the same issue

closed by #10679


Add Signet Parsing by Default

Simple change to add signet parsing by default. You could add custom networks as in here, but there's no reason to have it not parse signet by default. This allows packages that use this library to parse signet without refactoring.

@junderw would you be merging this PR?

As mentioned here: https://github.com/bitcoinjs/bolt11/issues/39#issuecomment-870107875
I'm not going to keep re-drawing the line in the sand.
Sorry.


Fork all your PRs to me 🚨

I try to contact the owner of the repo but no luck.
Please send any PR or change to my repo, I will continue adding new features and support

https://github.com/juandl/react-native-credit-card-input-plus

-We release a feature to change horizontal scroll to vertical.


Feat/158 node angular upgrade  node18 api v9 public admin angular15 using guard

This PR focus on one API issue after migrating to NestJS V9 (as part of ticket #158):

403 always get returned on secured endpoint.
Previous NestJS custom interceptor for parsing user object not behaving correctly.

The implementation uses NestJS Guards.
Many controllers/endpoints are touched. Some endpoints auth from previous version, found to be ambiguous.
I tried my best to interpret that. So, please be careful on this review and we can discuss in details if anything would not be correct. Thanks @basilv .

Thanks for the PR!
Any successful deployments (not always required) will be available below.

api
admin
public

Once merged, code will be promoted and handed off to following workflow run.

Main Merge Workflow

Thanks for the PR!
Any successful deployments (not always required) will be available below.

api
admin
public

Once merged, code will be promoted and handed off to following workflow run.

Main Merge Workflow

As discussed, merging away this to the parent feature branch.


Add time frame as URL parameter

Adding the selected time frame as URL parameter has multiple advantages:

Time frame gets remembered when refreshing the page
One can share links for a specific time frame

This should of course happen without refreshing the page when changing the time frame, just update the URL. This should be possible technically.

i like this idea. we could have multiple parameters as there are multiple dashboards with time frames. it would work even better when we finally split the page into multiple pages / sections so each page can have its own straightforward time frame parameter.


Throws an error node\r: No such file or directory

I did npm i -g isup, restarted the terminal and it’s not working:
$ isup
env: node\r: No such file or directory

How can I fix it?

Same issue here

Search for the isup executable:
which isup
Open the file in vim and run this:
:set ff=unix
:x


delete the empty directories to keep the bundle cleaner

in case there's no runtime dependencies at all, which could happen on macos.

Thank you!


React Native <0.40> IOS import syntax change for referencing native libraries

#import "RCTUtils.h" -> #import <React/RCTUtils.h>
See reference docs here:
https://github.com/facebook/react-native/releases/tag/v0.40.0

I assume the CI build failed because it's not expecting a repository with this name

@Extrct this should be get updated, thank you :)

Ahh oops. Thanks for the catch :)


MSFT_SPDesignerSettings error getting Site Collection

Details of the scenario you try and problem that is occurring:
When calling the Get-TargetResource function of the MSFT_SPDesignerSettings Resource passing in a "SiteCollection" scope, the site is never found. The issue comes from line 124, where we try to find the site by filtering the list using a variable ($url) that doesn't exist. Instead this block of code need to be filtering using the $params.Url parameter received by the function call as follow:
Check if site collections exists
$site = Get-SPSite | Where-Object -FilterScript {
$_.Url -eq $params.Url
}
The DSC configuration that is using the resource:
N/A
Version of the Operating System and PowerShell the DSC Target Node is running:
WMF 5 / Windows Server 2012 R2
Version of the DSC module you're using:
<IP_ADDRESS>

I have some time available next week. Will pick this up together with the other bugs you reported.


[zh-cn] Translate blog 2024-06-06-10-Years-of-Kubernetes

Fixes: https://github.com/kubernetes/website/issues/46693
See the preview page.
Special notes for the reviewer：
For some old English blogs, the Chinese blogs have not been translated, so there are no corresponding links. Therefore, the links without corresponding Chinese blogs are still using the original English links.

Comments addressed.

/approve

/lgtm
thanks.


More Features

Been using this app for some time and I think more features would be beneficial:
Filter based on Country
This is important because I see a lot of users on this app are either from Europe or another country, In USA or not from USA, etc. By putting in a filter option to sort profiles based on Country this will help filter out people who don't want to travel and or move to another country and not waste time talking to someone for 15-20 minutes just to find out they don't want to come out of their comfort zone.
Online Status
Having vague time-stamps isn't enough. Users that are online should be indicated by a green button, where users off should be grey and 'busy' users should be red.
De-activate dead accounts
This is another prominent issue I see with Vsinder. A lot of users have created accounts but have either decided not to log in anymore. By having an account to have an 'active' login for atleast 30 days should be significant enough. Otherwise, the account is de-activated and it is removed from the swiping pile until the user logs back into the account again.
Filter out garbage profiles
Yet another issue with VSinder with the immaturity of a lot of users. Some put literal one words in their profiles, silly bios that amount to nothing, and over-all content that shouldn't be on an app designed for dating. By placing in a minimum word limit and filtering out garbage code/words, this will over-all help a better and genuine type of profiles available to match up with instead of the "Lulz I don't know why i'm here" or the "I don't code" or the copy-paste scripts from stack over-flow/geeksforgeeks, etc. This may require moderation.
Restrict/Remove profiles 50+ with age verification or 18+
Another issue that should be aware of is unfortunately teenagers have created accounts on this app. Whether they know this or not, this app is design for those of age 18 and older and there are plenty of young to older adults that use this app. They are usually the default 51 years old age profiles or, of course, fake their age. By requiring verification of age this helps filter out those teenagers that sign up on platforms like this. Can help avoid a lot of legal headaches and making sure minors aren't accessing and using dating apps such as this as has been the case with other forms of online communication, such as discord dating servers, websites, etc.
Add a open-kattis/hacker-rank/leet code verification
Want to make sure the person that your selecting as a possible date actually knows what their doing and not some copy-paste? By adding these technical assessments, it'll help ensure that the person your talking to isn't some super-beginner that knows 0 code or just someone copying existing code somewhere. The level of difficulty can be adjusted.
Time-Stamps per message
While it's possible to see Time-Stamps, it's usually not until the next day you actually see the time. Have it based by default of region when the last message was sent. This will help coordinate times in different zones and also as an indication of availbility.
Remove the 'It's a Joke' app reference
This app has potential but for it to be taken as a joke is seriously holding it back. Thus the reason why for all the garbage profiles, inactive accounts, immature adult users, etc. Whoever is in charge of this app now should re-brand it to be an actual dating app meant for programmers across the world. It should be on the level of Tinder, Bumble, and other dating apps but without the annoyance of those main-stream gimmicks and often times, non-IT friendly dating parts.

Some of those are active feature requests already:

Location:

#135
#190

Online/Offline:

#241

Filter out garbage profiles:

#155
#149

hacker-rank is similar to:

#164
#222

Could you split these comments out into separate issues for easier discussion?
I broadly agree with some minor comments.
Unfortunately, there doesn't seem to be any developers working on this project.
As far as I can tell, it's just me filtering though the issues when I have some time to set aside.


Should support null body

Using this simple document:
#%RAML 0.8
title: example
baseUri: http://example.com
/name:
  get:
    responses:
      200:
        body:
          text/plain: !!null

... it raises an error body property must be a map with map values: {"text/plain"=>"text/plain"}
The RAML 0.8 spec allows this https://github.com/raml-org/raml-spec/blob/master/raml-0.8.md#body

I have a similar issue. With the following spec:
#%RAML 0.8
title: example
baseUri: http://example.com
/name:
  get:
    responses:
      200:

I got this error: Raml::InvalidProperty: responses property must be a map with map values: {200=>200}.
One thing is that {200 => nil} becomes {200 => 200}, after the expand_includes method is called, just like {"text/plain"=>"text/plain"} in the description of this issue. Is it expected?
Also, {200 => nil} is valid for response when validating with raml-cop, but the hash validation does not allow nil.


chore(deps): upgrade dev dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-dev-dependencies-k8s-27-main" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 3732

Questions ?
Please refer to the Backport tool documentation


Why the Model weights File size increases as the training data Increases?

I have built a model with training data of 100 records with parallel-cnn as my encoder. Then the model-weights file size is 22MB. Now i changed my training file data to 1000 records and now my model-weights file size is 40MB.
Why there is a change in the size of weights file?

There's many reasons why this could happen.
For example, have you checked how many epochs the model trained for in both cases? If one was trained for more epochs, there would be more metadata to save.

So the model weights file size should not change. Can you be specific about which files are actually growing in size?

model_hyperparameters
model_weights.data-00000-of-00001
train_set_metadata
These 3 files are growing in size. But I want to know specifically why model_weights.data-00000-of-00001 file size changes based on training Data Size.
Number of epochs are same in both the cases. I am using parallel-cnn which is default one. No additional changes in my model-definition file

model_hyperparameters and train_set_metadata may definitely change depending on the size of your data, as some of their contents are data dependent, like the vocabulary of classes or the vocabulary of words if you working on text.
The weights should not change though, we would want to know what that's the case too, but it is difficult without a reproducible example. If you can provide such a thing to use we would be glad to take a look at it.
What you need to provide is either a script or a command with the model definition you are using and some data, together with instructions on how to reproduce the issue. if you can't share your data, you can use the dataset synthesizer in data/dataset_synthesyzer.py to create a dataset.

2 sample data sets of news is considered of which one is of 100 records and another one of 1000 records. Tested with the testing_ludwig.py file which is in the attached zip file. Then the generated model_weights file size of 100 records is 19MB and of 1000 records is 22MB.
When i convert the same data using data_synthesizer.py by considering the features as
'[
{name: Data, type: text, vocab_size: 256, max_len: 256},
{name: Target_Class, type: category, vocab_size: 5}
]'
and build the model , then the generated model_weights file size is constant that is 20MB for both the files.
Please do see the data and code and let me know why the weights file size is varying for my data.
Regarding Zip file:

new_trained_models-->folder consists of generated models.
testing_ludwig.py-->script file for training model.
news_train_100.csv , news_valid_100.csv are the training and validation files of 100 records.
news_train_1000.csv , news_valid_1000.csv are the training and validation files of 1000 records.

Testing_Github.zip

Any update on the above issue. Please do update why it is happening like that to me.

@NavyaSreeYadavalli we will look into it.

Hi, How do I use this model weights file, how can I use this to find column importance.

@surendra1472 your question is not related to this issue, please open another issue for that. Also feature importance in DL models is an open research question ( https://stats.stackexchange.com/questions/261008/deep-learning-how-do-i-know-which-variables-are-important ), there are approaches like lime and shap that approximate it.

I finally had time to look into it. The 1000 sample dataset has a bigger vocabulary, because of that the first embedding layer in the model has a different dimension, 1294 in the case of the bigger dataset, 252 as you can see from the screenshots.

Closing this as the mystery is solved :)


Implement new TypedArray api

For more speed.

Not sure if it is related as javascript has its own Typed Array and you might here refer to haxe Typed Arrays but I noticed that Matrix4 use haxe.ds.Vector for implementation.
Unfortunately for webgl it means it has to do a conversion for every call to uniformMatrix
For js it is thus better to use the js Float32Array.

Refering to Haxe's TypedArrays, yes. That maps to JavaScript's TypedArrays in JavaScript. Kha's TypedArrays will do the same thing.
Will implement your matrix optimization.


Try to add concuerror for testing concurrrency issues

http://concuerror.com/
https://github.com/parapluu/Concuerror

looks cool to try


chore: regenerates snapshots

Signed-off-by: Philipp Rudloff<EMAIL_ADDRESS>

Note that we’re currently seeing more snapshot changes on account of ongoing work in Kongponents that replaces/removes a lot of utility classes in favor of regular styles.


feat: add subnet address space to mtpnc status

Reason for Change:

Update the multitenancy CRD schemas to include subnet address space in MTPNC status.
Issue Fixed:

Requirements:

[x] uses conventional commit messages

[ ] includes documentation
[ ] adds unit tests
[x] relevant PR labels added

Notes:

/azp run Azure Container Networking PR


No 'skull' segmentation task in Slicer?

Should I use 'head'? I'm mostly interested in the bony structures and teeth, similar to this image I found when searching for 'totalsegmentator skull'.

Ah my bad, I guess this is more of a question for https://github.com/lassoan/SlicerTotalSegmentator

wrong repo, please discard


Putting state into Redis

and some refactorings/bugfixes

This was a different PR, I think we should change the name of shouldSendTxToRelay. It's a little confusing what that does because it's triggered in a function called "sendTxToRelay"
How about checkTxStatusAtRelay?

Altogether LGTM, I didn't see anything that should be a showstopper!
Would be good for us to take a step back add some issues for others to contribute to, like we discussed

This was a different PR, I think we should change the name of shouldSendTxToRelay. It's a little confusing what that does because it's triggered in a function called "sendTxToRelay"
How about checkTxStatusAtRelay?

But this function does more than checking at the relay -- it first checks the local cache if this tx has been submitted before, and if yes only then checks status at relay. For this reason I think checkTxStatusAtRelay is less descriptive than shouldSendTxToRelay. Thinking about a better name, open to changing it :)

Deployed to staging


Use GitHub webhooks

Set up a webhook to receive events (i.e. new commit, new PR etc.) from organization's repositories.

Please refer this

It'll trigger the notification on the homepage as soon as payload for a particular event is received.
PS - It might need changes in code structure, please feel free to make changes in the codebase. This is just a POC which makes an API call to GitHub periodically and checks the last commit, which is displayed as notification on the homepage.

I'd like to work on this :)

@liaob That's great! Please go ahead 👍

@vinitshahdeo It looks like in order to add in a webhook, there needs to be some server running the website. It can't be done with just html and javascript.

@liaob Can't we have one NodeJS server running locally as of now, later we can host it in free server hosting provider?

I can include Node in the project and set up a local webhook, sure.

Awesome:)

Sorry, I don't think I can figure it out. If you'd like to give someone else a shot, that's fine with me.

@liaob No problem. Let's see if someone asks for this.

I'll take on the task :)

@hotdang-ca Yes, please go ahead.

PR incoming in a couple hours.

@hotdang-ca Wow!!

Can u assign this one to me?

Is this repo still active


fix: 'IStableDiffusionService' does not contain a definition for 'Models' and no accessible extension method 'Mode ls' accepting a first argument of type 'IStableDiffusionService' could be found

Workaround to fix run unit test fail.
StableDiffusionTests.cs(43,38): error CS1061: 'IStableDiffusionService' does not contain a definition for 'Models' and no accessible extension method 'Mode
ls' accepting a first argument of type 'IStableDiffusionService' could be found (are you missing a using directive or an assembly reference?) [C:\Users\kimi0\Desktop\ONNX\OnnxStack\OnnxStack.IntegrationTests\OnnxStack.In
tegrationTests.csproj]

I dont think we should be changing code to fix tests
I have no intention of keeping this test updated, deleting it would be my preference


Fix spec templates containing spaces in version

Coverage remained the same when pulling c7a2424dae5e14775404b2fd8a82ff4031363523 on plusky:master into 7c5c1e3c99f4732f0c580e94f306dbe557f73315 on openSUSE:master.

Coverage remained the same when pulling c7a2424dae5e14775404b2fd8a82ff4031363523 on plusky:master into 7c5c1e3c99f4732f0c580e94f306dbe557f73315 on openSUSE:master.

Thanks for the update


[giflib] update to 5.2.1

Library name:
giflib
New version number:
5.2.1
Other information that may be useful (release notes, etc...)

giflib is at 5.2.1.

@quaesitor-scientiam, giflib has been upgrade to 5.2.1 in master, you can get latest source via executing 'git pull' and 'bootstrap-vcpkg.bat' and try again.

Thanks


refactor: validation for writing auth models

Description

References

Review Checklist

[ ] I have added documentation for new/changed functionality in this PR or in a PR to openfga.dev [Provide a link to any relevant PRs in the references section above]
[ ] The correct base branch is being used, if not main
[ ] I have added tests to validate that the change in functionality is working as expected

Codecov Report

Merging #211 (f2404d2) into main (6aceea4) will increase coverage by 0.19%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #211      +/-   ##
==========================================
+ Coverage   75.82%   76.02%   +0.19%
==========================================
  Files          78       78
  Lines        8849     8826      -23
==========================================
  Hits         6710     6710
+ Misses       1751     1735      -16
+ Partials      388      381       -7

Impacted Files
Coverage Δ

server/commands/write_authzmodel.go
94.11% <100.00%> (+0.36%)
:arrow_up:

server/errors/errors.go
80.55% <100.00%> (+1.38%)
:arrow_up:

server/test/write_authzmodel.go
100.00% <100.00%> (+2.53%)
:arrow_up:

server/commands/check.go
87.39% <0.00%> (+0.56%)
:arrow_up:

storage/postgres/postgres.go
65.90% <0.00%> (+0.62%)
:arrow_up:

storage/postgres/utils.go
89.36% <0.00%> (+0.70%)
:arrow_up:

server/commands/check_utils.go
94.53% <0.00%> (+1.26%)
:arrow_up:

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


[fix] call of super method for newer gcc version

Fixes issue #262
thanks to @vmatare for pointing in the right direction

Can one of the admins verify this patch?

Can one of the admins verify this patch?

ok to test

Should this patch be applied here too? Or since the variable has no const qualifier it's not a problem?

I'd recommend to use either

a more explicit way to access a templated method with a dependent name (which could be considered the underlaying problem here):

this->template get<int>(...)

or explicit scoping for the non-static member resolution:

this->Parametrizable::get<int>(...)

and do that for all calls ('agree with @MathLabu ; btw. constness is irrelevant here).
Explanation of 1.

this-> is the "official" way to mark the name (get) as a dependent name (=>the compiler has to wait for instantiation before rejecting the name, which it won't because then it will consider all effective super classes)
template is used to disambiguate the dependent name get such that the compiler knows it is a template.

Explanation of 2.
This is basically the more verbose version of
Parametrizable::get<int>(...)

stating that the compiler should look for non static members for the this-pointer. Through explicitly specifying the class from which to take the member name, get, is non-dependent (in this case) and therefore the disambiguation (with template) is not required.
I don't know why the new gcc does not seem to accept the short version (current master) anymore but I'm pretty confident that it'll accept 2..
(Does somebody know about an updated language specification here?).
Why prefer 2. over this PR's suggestion:
((Parametrizable*)this)->get<int>(...)

is technically a cast (a c-style btw., a static_cast would be more c++). However, casting is not what this is about. Instead it is about scoping, which IMO it is cleaner to use the scope resolution operator, ::.
1. vs. 2.
Solution 1. is quite different from explicit scoping, 2., (also current solution): With explicitly specifying the class from which to take the member (its name might no longer be dependent - as it is here) and therefore the disambiguation (template) is not required, which is quite nice of course.
However, 2.

somehow obfuscates the underlying problem (dependent name of a template function) since explicit parent scoping typically indicates ambiguities between multiple base classes, for which it is the only solution.
blocks the (static) inheritance (in contras to 1.), i.e. if the current class (of this) started to shadow the get-template with its own implementation, then this call would remain unaffected which would probably be unintended.
is effectively a duplication of a parent class specification, i.e. once the parent class gets changed this call must be adapted.

Conclusion
The decision should be based on what is intended here: explicitly take the get from Parametrizable or somehow from the class hierarchy. I'm not sure here. But if an explicit delegation to the specific class is intended then making it a base class in the first place is confusing (might still be justified, since c++ is a bit nasty here).
@pomerlef, maybe it should be a maintainer decision?  I would suggest 1.  (but it is a tough decision :) )

Thanks @HannesSommer for the deeper analysis. It seems that there is a preference for solution 2 over here.
@tobiasneumann would it possible to review the PR?

Thank you for the good feedback.
@MathLabu this seems not to be a problem, but I would also change it for consistency reasons.
@HannesSommer and @pomerlef solution 2 dos not compile with the same error as the current master
‘get<uint8_t>’ is not a member of ‘CovarianceSamplingDataPointsFilter<T>’
Solution 1 does compile and I agree that this is nicer code than my original PR, I've updated the PR.

@tobiasneumann , thanks for trying out. I'm astonished that 2. doesn't work. Just to be sure: you've tried
this->Parametrizable::get<int>(...)

and then the compiler is complaining that CovarianceSamplingDataPointsFilter<T> is missing get?
Is this a compiler bug? Amazing :).
Or was it a misunderstanding and you tried in fact
this->CovarianceSamplingDataPointsFilter<T>::get<int>(...)

In that case the error message would make sense to me.

@HannesSommer, yes that is what I did. I committed this which is the applied change that isn't working (just to make sure we speak about the same).
With this applied, the compilation error is (copied in greater extent)
libpointmatcher/pointmatcher/DataPointsFilters/MaxPointCount.cpp: In constructor ‘MaxPointCountDataPointsFilter<T>::MaxPointCountDataPointsFilter(const Parameters&)’:
libpointmatcher/pointmatcher/DataPointsFilters/MaxPointCount.cpp:47:32: error: ‘get<size_t>’ is not a member of ‘MaxPointCountDataPointsFilter<T>’
   seed = this->Parametrizable::get<size_t>("seed");

Thanks again. Fascinating! This seems to me like a compiler bug: I could not find any explanation from the standard and clang 6 compiles it just fine.
Probably, we should stop investigating and go for the alternative 1., i.e. your current code in this PR.

@pomerlef I'm sorry, I'm not quite sure what you're asking, could you please elaborate your question?
I tried to make sure that the code and commit msgs are consistent with this project.

Yes, it was not clear.
I was referring to the comment of @MathLabu about other call to super template  (ex.:
https://github.com/ethz-asl/libpointmatcher/blob/master/pointmatcher/DataPointsFilters/MaxPointCount.cpp#L47)

Yes I included this when I updated the PR according to @HannesSommer suggestions. Even so gcc did not complain about it before. And I've just checked, this seems to be the only occurrence of Parametrizable::get in method bodies.
I did not change the calls of Parametrizable::get when used in the initializer lists, because this does not cause problems with gcc. If you would like that to be changed as well I can add this to the PR, its only a simple search+replace, but it would increase the PR diff from 3 lines to 150.
@pomerlef which would you prefer?

That's good for me then!


Firebase Analytics begin_checkout event item price is different on Firebase console compared to what was sent

Description
There appears to be a discrepancy between the value of "price" from an event item that is logged via the firebase-ios-sdk and what appears on the Firebase console.
This is what is logged in Xcode console. Note the value of price in the items array is 1100000:
10.18.0 - [FirebaseAnalytics][I-ACS023105] Event is not subject to real-time event count daily limit. Marking an event as real-time. Event name, parameters: begin_checkout, {
    bool = true;
    currency = IDR;
    double = 42;
    ga_debug (_dbg) = 1;
    ga_event_origin (_o) = app;
    ga_realtime (_r) = 1;
    ga_screen (_sn) = /;
    ga_screen_class (_sc) = Flutter;
    ga_screen_id (_si) = -8487019527403922116;
    int = 42;
    items = [
    {
        currency = IDR;
        item_category = air;
        item_name = import/singapore/air;
        price = 1100000;
    }
    ];
    long =<PHONE_NUMBER>0;
    string = string;
    value = 1100000;
}

If you look at what appears in the Firebase console:

I thought it might be a conversion issue, but if you look at the other property value which has the value of 1100000, this is correctly displayed as shown here:

Reproducing the issue
To reproduce:

Set -FIRDebugEnabled in arguments passed on launch for your scheme in Xcode.
Run the following code and check the debug view in the Firebase console:

NSDictionary *item = @{
        @"item_name": @"import/singapore/air",
        @"item_category": @"air",
        @"currency": @"IDR",
        @"price": @1100000
    };

    NSDictionary *parameters = @{
        @"currency": @"IDR",
        @"value": @1100000,
        @"items": @[item]
    };

    [FIRAnalytics logEventWithName:@"begin_checkout" parameters:parameters];

Firebase SDK Version
10.18
Xcode Version
15.1
Installation Method
CocoaPods
Firebase Product(s)
Analytics
Targeted Platforms
iOS
Relevant Log Output
10.18.0 - [FirebaseAnalytics][I-ACS023105] Event is not subject to real-time event count daily limit. Marking an event as real-time. Event name, parameters: begin_checkout, {
    bool = true;
    currency = IDR;
    double = 42;
    ga_debug (_dbg) = 1;
    ga_event_origin (_o) = app;
    ga_realtime (_r) = 1;
    ga_screen (_sn) = /;
    ga_screen_class (_sc) = Flutter;
    ga_screen_id (_si) = -8487019527403922116;
    int = 42;
    items = [
    {
        currency = IDR;
        item_category = air;
        item_name = import/singapore/air;
        price = 1100000;
    }
    ];
    long =<PHONE_NUMBER>0;
    string = string;
    value = 1100000;
}

If using Swift Package Manager, the project's Package.resolved

Expand Package.resolved snippet

Replace this line with the contents of your Package.resolved.

If using CocoaPods, the project's Podfile.lock

Expand Podfile.lock snippet

PODS:
  - Firebase/Analytics (10.18.0):
    - Firebase/Core
  - Firebase/Core (10.18.0):
    - Firebase/CoreOnly
    - FirebaseAnalytics (~> 10.18.0)
  - Firebase/CoreOnly (10.18.0):
    - FirebaseCore (= 10.18.0)
  - firebase_analytics (10.7.4):
    - Firebase/Analytics (= 10.18.0)
    - firebase_core
    - Flutter
  - firebase_core (2.24.2):
    - Firebase/CoreOnly (= 10.18.0)
    - Flutter
  - FirebaseAnalytics (10.18.0):
    - FirebaseAnalytics/AdIdSupport (= 10.18.0)
    - FirebaseCore (~> 10.0)
    - FirebaseInstallations (~> 10.0)
    - GoogleUtilities/AppDelegateSwizzler (~> 7.11)
    - GoogleUtilities/MethodSwizzler (~> 7.11)
    - GoogleUtilities/Network (~> 7.11)
    - "GoogleUtilities/NSData+zlib (~> 7.11)"
    - nanopb (< 2.30910.0, >= 2.30908.0)
  - FirebaseAnalytics/AdIdSupport (10.18.0):
    - FirebaseCore (~> 10.0)
    - FirebaseInstallations (~> 10.0)
    - GoogleAppMeasurement (= 10.18.0)
    - GoogleUtilities/AppDelegateSwizzler (~> 7.11)
    - GoogleUtilities/MethodSwizzler (~> 7.11)
    - GoogleUtilities/Network (~> 7.11)
    - "GoogleUtilities/NSData+zlib (~> 7.11)"
    - nanopb (< 2.30910.0, >= 2.30908.0)
  - FirebaseCore (10.18.0):
    - FirebaseCoreInternal (~> 10.0)
    - GoogleUtilities/Environment (~> 7.12)
    - GoogleUtilities/Logger (~> 7.12)
  - FirebaseCoreInternal (10.19.0):
    - "GoogleUtilities/NSData+zlib (~> 7.8)"
  - FirebaseInstallations (10.19.0):
    - FirebaseCore (~> 10.0)
    - GoogleUtilities/Environment (~> 7.8)
    - GoogleUtilities/UserDefaults (~> 7.8)
    - PromisesObjC (~> 2.1)
  - Flutter (1.0.0)
  - GoogleAppMeasurement (10.18.0):
    - GoogleAppMeasurement/AdIdSupport (= 10.18.0)
    - GoogleUtilities/AppDelegateSwizzler (~> 7.11)
    - GoogleUtilities/MethodSwizzler (~> 7.11)
    - GoogleUtilities/Network (~> 7.11)
    - "GoogleUtilities/NSData+zlib (~> 7.11)"
    - nanopb (< 2.30910.0, >= 2.30908.0)
  - GoogleAppMeasurement/AdIdSupport (10.18.0):
    - GoogleAppMeasurement/WithoutAdIdSupport (= 10.18.0)
    - GoogleUtilities/AppDelegateSwizzler (~> 7.11)
    - GoogleUtilities/MethodSwizzler (~> 7.11)
    - GoogleUtilities/Network (~> 7.11)
    - "GoogleUtilities/NSData+zlib (~> 7.11)"
    - nanopb (< 2.30910.0, >= 2.30908.0)
  - GoogleAppMeasurement/WithoutAdIdSupport (10.18.0):
    - GoogleUtilities/AppDelegateSwizzler (~> 7.11)
    - GoogleUtilities/MethodSwizzler (~> 7.11)
    - GoogleUtilities/Network (~> 7.11)
    - "GoogleUtilities/NSData+zlib (~> 7.11)"
    - nanopb (< 2.30910.0, >= 2.30908.0)
  - GoogleUtilities/AppDelegateSwizzler (7.12.0):
    - GoogleUtilities/Environment
    - GoogleUtilities/Logger
    - GoogleUtilities/Network
  - GoogleUtilities/Environment (7.12.0):
    - PromisesObjC (< 3.0, >= 1.2)
  - GoogleUtilities/Logger (7.12.0):
    - GoogleUtilities/Environment
  - GoogleUtilities/MethodSwizzler (7.12.0):
    - GoogleUtilities/Logger
  - GoogleUtilities/Network (7.12.0):
    - GoogleUtilities/Logger
    - "GoogleUtilities/NSData+zlib"
    - GoogleUtilities/Reachability
  - "GoogleUtilities/NSData+zlib (7.12.0)"
  - GoogleUtilities/Reachability (7.12.0):
    - GoogleUtilities/Logger
  - GoogleUtilities/UserDefaults (7.12.0):
    - GoogleUtilities/Logger
  - nanopb (2.30909.1):
    - nanopb/decode (= 2.30909.1)
    - nanopb/encode (= 2.30909.1)
  - nanopb/decode (2.30909.1)
  - nanopb/encode (2.30909.1)
  - PromisesObjC (2.3.1)

DEPENDENCIES:
  - firebase_analytics (from `.symlinks/plugins/firebase_analytics/ios`)
  - firebase_core (from `.symlinks/plugins/firebase_core/ios`)
  - Flutter (from `Flutter`)

SPEC REPOS:
  trunk:
    - Firebase
    - FirebaseAnalytics
    - FirebaseCore
    - FirebaseCoreInternal
    - FirebaseInstallations
    - GoogleAppMeasurement
    - GoogleUtilities
    - nanopb
    - PromisesObjC

EXTERNAL SOURCES:
  firebase_analytics:
    :path: ".symlinks/plugins/firebase_analytics/ios"
  firebase_core:
    :path: ".symlinks/plugins/firebase_core/ios"
  Flutter:
    :path: Flutter

SPEC CHECKSUMS:
  Firebase: 414ad272f8d02dfbf12662a9d43f4bba9bec2a06
  firebase_analytics: 88c111412070acc2b05c1734151f58824f3db657
  firebase_core: 0af4a2b24f62071f9bf283691c0ee41556dcb3f5
  FirebaseAnalytics: 4d310b35c48eaa4a058ddc04bdca6bdb5dc0fe80
  FirebaseCore:<PHONE_NUMBER>d92f946219c8791674d2f3345b598f
  FirebaseCoreInternal: b444828ea7cfd594fca83046b95db98a2be4f290
  FirebaseInstallations: 033d199474164db20c8350736842a94fe717b960
  Flutter: f04841e97a9d0b0a8025694d0796dd46242b2854
  GoogleAppMeasurement: 70ce9aa438cff1cfb31ea3e660bcc67734cb716e
  GoogleUtilities: 0759d1a57ebb953965c2dfe0ba4c82e95ccc2e34
  nanopb: d4d75c12cd1316f4a64e3c6963f879ecd4b5e0d5
  PromisesObjC: c50d2056b5253dadbd6c2bea79b0674bd5a52fa4

PODFILE CHECKSUM: d5950626612d11c88514c1c16d7560e14806f7a8

COCOAPODS: 1.14.3

Hi @russellwheatley, I see that there are 0s added in your actual price in the Firebase console. Upon checking, it seems that there's an internal bug (b/172064570) similar to your issue, which appears to be a bug in the backend. That being said, you may file a ticket to our Firebase support to follow up the progress of the investigation or if you have questions regarding this issue. Thanks.

@rizafran is this a bug on the debug console, or an actual bug in the client?  By bug in console, i mean, maybe it's displaying an internal value that is correct and just rendered incorrectly?  That fix should be tiny, but super important since this is what people are using to validate correctness of payloads. It's also a first class citizen in documentation https://firebase.google.com/docs/analytics/debugview
See:
https://groups.google.com/g/firebase-talk/c/WGwCKEkdEOo/m/2hsnAhc9AQAJ
See:
https://github.com/invertase/react-native-firebase/pull/5232/files#diff-f2aa40411bfb84c4832f3fb58d660ca98c44fc5108f49b536dc474072a87ecaeR108

I know you have it tracked internally, but I actually remember this same bug 5 years ago, and it's creating a TON of confusion across all related platforms. If it's just a rendering error from not being normalized back to the consumer, can you mention that somewhere?
A lot of wasted hours, i think it would be helpful to keep one of these tickets open.
https://github.com/firebase/firebase-ios-sdk/issues/8280
https://github.com/firebase/flutterfire/issues/9844
https://github.com/firebase/firebase-ios-sdk/issues/8280
https://github.com/invertase/react-native-firebase/issues/4578
https://www.google.com/search?q=ios+firebase+analytics+item+price+incorrect
https://github.com/invertase/react-native-firebase/issues/2567


InconsistentVersionWarning because LabelEncoder from version 0.24.2 of scikit-learn

Hello,
Just want to point out the fact that predicting with yasa.SleepStaging() with recent sklearn versions seems to print an InconsistentVersionWarning:
\site-packages\sklearn\base.py:348: InconsistentVersionWarning: Trying to unpickle estimator LabelEncoder from version 0.24.2 when using version 1.3.2. This might lead to breaking code or invalid results.
Use at your own risk. For more info please refer to: https://scikit-learn.org/stable/model_persistence.html#security-maintainability-limitations

I am not sure about this warning origin and how it can be fixed. I put it here in case something can be solved on the yasa side and if some people also have this warning using SleepStaging().

Thanks, this warning is shown because models were trained on an old version of scikit-learn. I don't think it impacts the accuracy of the model however. I will try to updated classifiers sometimes in the next months, using the latest scikit-learn and lightgbm versions available.

Alright perfect, thanks


Unknown system register when analyzing Aarch64 golang binary

Occurs with:
Version 2.2.2596-dev (Build ID 764ea3f9)
Log message:
Unknown system register 0 @ 0x73bd0: S3_3_c0_c0_7, using catch-all system register instead

Screen snip:

Here is the binary (remove the .txt extension):
animalselect.txt

Right now the arm64 arch only lifts system registers defined by the armv8 ISA spec. This does not include a bunch of common system registers that seem to be (?) de facto standardized which are defined by the microarchitecture. I have a tiny little architecture hook I intend to fill out to add the cortex a53 system registers here. Right now it only lifts a single system register, but should be pretty easy to fill out by adding msr's to the map in msr.h.
If you want to add things, the numeric key is defined in the StatusReg function, so for your example it would be 3 << 14 | 3 << 11 | 0 << 7 | 0 << 3 | 7 or 0xd807. So to add that register, you'd insert {0xd807, DCZID_EL0} into msr.h, recompile and load it.
That should fix the warning and display the register properly in all the IL views -- the dasm will remain unchanged however.

Right now the arm64 arch only lifts system registers defined by the armv8 ISA spec. This does not include a bunch of common system registers that seem to be (?) de facto standardized which are defined by the microarchitecture. I have a tiny little architecture hook I intend to fill out to add the cortex a53 system registers here. Right now it only lifts a single system register, but should be pretty easy to fill out by adding msr's to the map in msr.h.
If you want to add things, the numeric key is defined in the StatusReg function, so for your example it would be 3 << 14 | 3 << 11 | 0 << 7 | 0 << 3 | 7 or 0xd807. So to add that register, you'd insert {0xd807, DCZID_EL0} into msr.h, recompile and load it.
That should fix the warning and display the register properly in all the IL views -- the dasm will remain unchanged however.


Fix changing tabs after executing commands

Codecov Report
Base: 57.45% // Head: 57.45% // No change to project coverage :thumbsup:

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

Additional details and impacted files
@@            Coverage Diff            @@
##             master     #212   +/-   ##
=========================================
  Coverage     57.45%   57.45%
  Complexity      767      767
=========================================
  Files           159      159
  Lines          3206     3206
  Branches        394      394
=========================================
  Hits           1842     1842
  Misses         1206     1206
  Partials        158      158

Impacted Files
Coverage Δ

...ava/seedu/address/logic/commands/ClearCommand.java
85.00% <100.00%> (ø)

...java/seedu/address/logic/commands/ListCommand.java
100.00% <100.00%> (ø)

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

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


The index out of range exception has been thrown when I try to build the whole US router db.

Hi,
I'm working on building the whole US router db. I try to get the router db file with two approaches but it works fail:

Use the whole US data with one North America  .pbf (7.8G).
I have download the North America data from https://download.geofabrik.de/ . I try to build the router db with following statements:
`var usPbfFile = @"C:\Test\north-america-latest.osm.pbf";
using (var stream = File.OpenRead(usPbfFile))
{
var osmStream = new OsmSharp.Streams.PBFOsmStreamSource(stream);
var routerDb = new RouterDb();
routerDb.LoadOsmData(osmStream);
if (!routerDb.HasContractedFor(vehicle.Fastest()))
{
Itinero.Logging.Logger.Log("RouterDbBuilder", Itinero.Logging.TraceEventType.Information, "No contracted graph found for the 'car' profile, building now...");
routerDb.AddContracted(vehicle.Fastest(), true);
}
using (var writeStream = File.Open(routerDbFileName, FileMode.Create))
{
routerDb.Serialize(writeStream);
}
}
`
It works failed and throws an index out of range exception when the router db calculating progress is 97% as the attached

Use the divided state .pbf files.
I have downloaded all of .pbf files in America, and build them into one router db file as following statements:
`
public static RouterDb Build(string sourceDbFolder, string targetDbFilename, Vehicle vehicle)
{
RouterDb routerDb = null;
var routerDbFileName = targetDbFilename;
if (File.Exists(routerDbFileName))
{
try
{
using (var stream = File.OpenRead(routerDbFileName))
{
routerDb = RouterDb.Deserialize(stream);
}
}
catch
{
routerDb = null;
}
}
     if (routerDb == null)
     {
         // check if OSM pbf file is there.
         var files = Directory.GetFiles(sourceDbFolder);
         if (files == null || files.Length <= 0)
         { // check if OSM file is there, otherwise attempt to download from overpass.
             throw new Exception("The .pbf file is not exist.");
         }

         // build routerdb.
         Itinero.Logging.Logger.Log("RouterDbBuilder", Itinero.Logging.TraceEventType.Information, "No existing RouterDb file found, creating now.");

         var osmFiles = new List<OsmStreamSource>();
         var fileStreams = new List<Stream>();

         foreach (var file in files)
         {
             OsmStreamSource osmStream = null;
             var stream = File.OpenRead(file);
             fileStreams.Add(stream);
             if (file.EndsWith(".osm.pbf"))
             {
                 osmStream = new OsmSharp.Streams.PBFOsmStreamSource(stream);
             }
             else
             {
                 osmStream = new OsmSharp.Streams.XmlOsmStreamSource(stream);
             }

             osmFiles.Add(osmStream);
         }

         routerDb = new RouterDb();
         routerDb.LoadOsmData(osmFiles.ToArray(), vehicle);

         foreach (var stream in fileStreams)
         {
             stream.Close();
             stream.Dispose();
         }
         Itinero.Logging.Logger.Log("RouterDbBuilder", Itinero.Logging.TraceEventType.Information, "RouterDb file created.");

         if (!routerDb.HasContractedFor(vehicle.Fastest()))
         {
             Itinero.Logging.Logger.Log("RouterDbBuilder", Itinero.Logging.TraceEventType.Information, "No contracted graph found for the 'car' profile, building now...");
             routerDb.AddContracted(vehicle.Fastest(), true);
         }

         using (var stream = File.Open(routerDbFileName, FileMode.Create))
         {
             routerDb.Serialize(stream);
         }
     }
     return routerDb;
 }

`
It works failed and throws an index out of range exception when the router db is being written with a result data as the attached file:

I don't know how to fix this issue. I'm very appreciate for your any help.
My computer configuration:
RAM: 32G,
CPU: Core i7 4790
OS: Win10 X64
Application: 64 bit.

Did you try this using the latest prerelease? We're focusing on getting that released.
I tested building the north-america routerdb and that worked, now testing the contraction...

Hi xivk,
Thanks for your help, I'm working on the version v1.4.0-pre67. As the above statements, a "Car fastest" contraction has been added to  RouterDb:
routerDb.AddContracted(vehicle.Fastest(), true);
This exception has been thrown when the router db is written to file with the "Car fastest" contraction. The thrown point is located on the "Compress" method in "DirectedGraph.cs".
If you have any updates, please tell me know. I'm very appreciate for your help.

Hi xivk,
I'm testing routing contraction with the latest development branch source code. As above issue, I have tried to build the whole US routing data with all of states .pbf data. It seems the out of range exception was thrown by Router db serialize progress. You can see the exception is thrown when the percent of the progress is 99%, the router db is being written to the disk.


Update to ANTLR 4.7.1

ANTLR 4.7.1 have to be integrated.
Release notes: https://github.com/antlr/antlr4/releases/tag/4.7.1
We have to check if it makes sense to replace the usage of -o (output) parameter with the new -Xexact-output-dir parameter.

To stay downward compatible also setuptools_antlr 0.0.9 will use per default only the -o options without passing additionally the -Xextact-output-dir flag. Nevertheless this new option is now part of setuptools_antlr. The user has the choice to pass this parameter on the command line or in a setup script.


Inadvertantly reopening a file can hang LFS.

The following code:
#include <assert.h>
#include <stdlib.h>
#include "lfs.h"
#include "emubd/lfs_emubd.h"

#define REQUIRE(x) do {if(!(x)) {assert(false); exit(1);}} while(0);

lfs_t lfs;
lfs_emubd_t bd;

const lfs_config cfg = {
    .context          = &bd,
    .read             = &lfs_emubd_read,
    .prog             = &lfs_emubd_prog,
    .erase            = &lfs_emubd_erase,
    .sync             = &lfs_emubd_sync,

    .read_size        = 128,
    .prog_size        = 128,
    .block_size       = 1024,
    .block_count      = 1024,
    .block_cycles     = 4096,
    .cache_size       = 128,
    .lookahead_size   = 512*1024,
    .read_buffer      = NULL,
    .prog_buffer      = NULL,
    .lookahead_buffer = NULL,
    .name_max         = 255,
    .file_max         = 16384,
    .attr_max         = 16,
};

int main(void) {
    lfs_emubd_create(&cfg, "blocks");

    REQUIRE(lfs_format(&lfs, &cfg) == 0);
    REQUIRE(lfs_mount(&lfs, &cfg) == 0);

    {
        lfs_file_t fileA;
        REQUIRE(lfs_file_open(&lfs, &fileA, "A", LFS_O_CREAT | LFS_O_RDONLY) == 0);
    }
    {
        lfs_file_t fileB;
        REQUIRE(lfs_file_open(&lfs, &fileB, "B", LFS_O_CREAT | LFS_O_RDONLY) == 0);
    }
};

Hangs forever in lfs_dir_commit in the second open.
Note: you need optimizations on for this hang to occur.
The proximal cause here is this:
static int lfs_dir_commit(lfs_t *lfs, lfs_mdir_t *dir,
        const struct lfs_mattr *attrs, int attrcount) {
    // check for any inline files that aren't RAM backed and
    // forcefully evict them, needed for filesystem consistency
    for (lfs_file_t *f = (lfs_file_t*)lfs->mlist; f; f = f->next) {
        if (...) {
            ...
        }
    }

If f == f->next when we hit here (and the if statement doesn't do something to kick us out of it)... we hang forever.
In the original example, the compiler is realizing that fileA and fileB are never in scope at the same time, so it's using the same stack address for both. As we didn't close the file, lfs still has a dangling reference in the form of lfs->mlist. Then when we add the second file to the list of files we point file->next to itself... which causes issues.
Hence why you need sufficient optimizations on: FileA and fileB must end up getting allocated to the same stack address.
(Alternatively, have them both use fileA, although that way's cheating :-) as it gives a big hint as to what's going on.)
I could easily see this occurring if e.g. someone forgets to close a file, it goes out of scope, and then something causes lfs to flush the directory. Hangs are never particularly fun to debug.
Found on commit c810747eb417ec263303b733e9cce4af2e37df89.

Personally I suggest that lfs_file_open should take a zeroed struct, although note that this is a backwards-incompatible change.
That way you can e.g. fairly easily add an is_valid flag for debug.

It's an unfortunate and sharp corner, but in the end this really isn't a bug in littlefs per say, and there isn't really anything you can do in littlefs to reliability detect this kind of bug.
Adding an assert in the loop to make sure file->next != file would certainly make this specific error easier to spot, but it still doesn't do anything for the case where you open a file on the stack and then simply forget to close it before returning.
You will end up with a pointer in the middle of a linked list to invalid stack memory, which is just a time bomb waiting to detonate.
The most foolproof way to avoid this issue is to compile your code as c++ and wrap this part of the lfs API with some simple raii file handle types that enforce file closing in their destructor.
If that isn't an option for you, the best you can really do if you must allocate file structures on the stack is to add the assert to lfs and cross your fingers. The assert is definitely more effective if you do not allocate file structures on the stack - at the very least in that case you can reasonably assert that any clobbering would be done in lfs itself (ie, opening into a structure that is already "open"), not at some random time in the future when your stack location gets reused.

there isn't really anything you can do in littlefs to reliability detect this kind of bug.

Some suggestions:

Document that the lfs_file_t should be zeroed when passed to lfs_file_open.
Have lfs_file_open assert !is_valid (or something similar). (And set is_valid, and lfs_file_close assert is_valid and set is_valid false.).
Have operations that iterate over files assert is_valid on said files.
Have a counter num_open_files. Assert if it goes negative.
Have operations that iterate over files assert if they've looped "too many times" (num_open_files? Max number of files that theoretically can fit into the currently-open filesystem? Something like that.).

Is this perfect? No. Is this much better at catching this sort of thing that the current approach? Yes.
As-is, I am hesitant to recommend a filesystem that states it's a "A little fail-safe filesystem" and yet doesn't do basic sanity checks like the above.

Sorry for the late reply - life gets in the way.

Document that the lfs_file_t should be zeroed when passed to lfs_file_open.
Have lfs_file_open assert !is_valid (or something similar). (And set is_valid, and lfs_file_close assert is_valid and set is_valid false.).

As you mentioned, this would be a breaking change.
Maybe this check could be gated behind a preprocessor define to retain backwards compatibility.
In any case, this would not help identify the issue you reported.
{
    lfs_file_t fileA = { 0 };
    REQUIRE(lfs_file_open(&lfs, &fileA, "A", LFS_O_CREAT | LFS_O_RDONLY) == 0);
}
{
    lfs_file_t fileB = { 0 };
    REQUIRE(lfs_file_open(&lfs, &fileB, "B", LFS_O_CREAT | LFS_O_RDONLY) == 0);
}

If the compiled with optimizations and fileA/fileB are collapsed into the same stack location we would still pass the theoretical check for is_valid, but the second open would still result in a corrupted lfs->mlist, as you can see below.
file->next = (lfs_file_t*)lfs->mlist;
lfs->mlist = (struct lfs_mlist*)file;

lfs->mlist will point to fileA
file will point to fileB
fileB->next will point to fileA
lfs->mlist will be updated to point to fileB

If fileA and fileB are the same location in memory, you can clearly see the list is circular and will result in an infinite recursion.

Have operations that iterate over files assert is_valid on said files.

This doesn't really help identify the cause, and by the time you fail this assertion things have already gone pear shaped.  I would say it is only marginally more helpful than ending up stuck in an infinite loop and/or dereferencing invalid memory (which is the more likely real-world failure mode for this bug).
Also, it is entirely feasible in a case where you forget to close a file declared on the stack that the is_valid flag is not clobbered, but the next pointer is (or that the is_valid value is clobbered with a non-zero value and still passes the check).

Have a counter num_open_files. Assert if it goes negative.

This would not help in the case of forgetting to close a file. (assuming you increment the counter on open and decrement on close).  It would catch the case of a double close, but I doubt that is a common bug.  As it stands, a double close in lfs would be well behaved except for a double free (which could be trivially fixed in any case) if you don't use lfs_file_opencfg and pass your own buffer.

Have operations that iterate over files assert if they've looped "too many times" (num_open_files? Max number of files that theoretically can fit into the currently-open filesystem? Something like that.).

Just my opinion, but this introduces more problems than I believe it attempts to solve.
Suddenly we have put a cap on the number of files you can open.  This is one more thing the user needs to configure that previously was not even a concern (beyond the obvious performance problems if you decide to open thousands of files).
And honestly, beyond this very specific test case you have provided, I don't believe the most common failure mode for forgetting to close a file will be an infinite loop.  Chances are really good if you put the file handle on the stack and forget to close it, the failure mode is a hard fault caused by dereferencing invalid memory when chasing the ->next pointer.

Is this much better at catching this sort of thing that the current approach? Yes.

I respectfully disagree.
Having said that, there are definitely things that can be done in lfs to make this particular corner hurt less.  Unfortunately none of them come without some disadvantage.
require memory allocation when opening files

lfs_file_t basically becomes a handle to memory allocated by lfs internally
lfs_file_open already uses malloc to allocate a cache buffer, so this could be implemented without any real overhead
lfs_file_opencfg allows you to provide your own cache buffer and avoid allocation.  retaining this functionality would require some thought.

In this case, forgetting to close a file is simply a memory leak.  The system would continue to operate without issue, until you run out of memory.  The upshot is that if you only infrequently do file operations and your device resets semi regularly, you may never run into issues.  The downside is that it masks the problem too well.  If you have a bug, you may never find it.  Or even worse, it bites your users in the field.
make mlist a doubly linked list
If each node points forward and backwards, you can pretty reliably detect memory corruption issues caused by forgetting to close a file allocated on the stack.
for (lfs_file_t *f = (lfs_file_t*)lfs->mlist; f; f = f->next) {
}

lfs->mlist should always point to a valid entry, so dereferencing it should always be safe.  The contents of f may be garbage, but at least reading the memory is safe.  Dereferencing f->next is not safe if the address of f has been clobbered.
for (lfs_file_t *f = (lfs_file_t*)lfs->mlist, lfs_file_t *lf = null; f; lf = f, f = f->next) {
    assert(f->previous == lf, "mlist corruption");

    // rest of loop
}

This is similar to your 3rd suggestion, although may be more robust in some cases.  It will still not reliably detect this issue.

As-is, I am hesitant to recommend a filesystem that states it's a "A little fail-safe filesystem" and yet doesn't do basic sanity checks like the above.

I suspect you were just being cheeky, but in case not.  I believe you are misconstruing what "fail-safe" means in this context.  It implies the filesystem will fail gracefully when your hardware fails. (power loss, bad flash blocks, write errors, etc).  It does not mean your application will be safe when you violate the lfs API contract (although chances are good even if you do, your filesystem on disk will remain safe).
As a thought experiment, go write a small c program for your pc that opens file handles in a loop but never closes them.

Would you expect this program to be "safe"?
If not, why should the (conceptually) same program be "safe" for lfs?

Admittedly the failure modes are different between lfs and your pc, but in both cases you have violated the API contract, and eventually your program will fail.
As I mentioned before, the most reliable way to avoid this kind of bug entirely is to use a c++ wrapper to the raw API (or just be very careful when using the existing api.
The below code is not complete, but its a rough outline of what I am talking about.  If you use a wrapper like this it is impossible to leak a file handle, as a call to lfs_file_close is inserted by the compiler automatically when the file handle goes out of scope.
class file
{
public:
	file(lfs_t* fs, std::unique_ptr<lfs_file_t>& file) :
		fs_(fs),
		file_(std::move(file))
	{}

	~file() { close(); }

	int close() { return lfs_file_close(fs_, file_.get()); }

	// rest of file methods

private:
	lfs_t* fs_;
	std::unique_ptr<lfs_file_t> file_;
};

class filesystem
{
public:
	filesystem(lfs_t* fs) :
		fs_(fs)
	{}

	expected<file, int> open(const char* path, int flags)
	{
		auto f = std::make_unique<lfs_file_t>();
		auto err = lfs_file_open(fs_, f.get(), path, flags);
		if (err != LFS_ERR_OK)
			return make_unexpected(err);

		return file(fs_, f);
	}

	// rest of relevant methods

private:
	lfs_t* fs_;
};

example usage
void test(filesystem& fs)
{
    auto f = fs.open("/test.txt", 0);
    if (!f) {
        printf("open failed, %i", f.error());
        return;
    }

    // do stuff
    f->read(...);
}  // f is automatically closed here

As I mentioned before, the most reliable way to avoid this kind of bug entirely is to use a c++ wrapper to the raw API (or just be very careful when using the existing api.

+1 here. Some things are not possible to solve reliably and completely in C, but in other languages it is much much easier. I've done it in similar way in my project, however I think I'll change it to be more "contract based" and use assertions instead of handling that automatically.
BTW - the proposed wrapper does double close when used properly (;

BTW - the proposed wrapper does double close when used properly (;

balls...
For the record, my actual wrapper doesn't suffer this problem - I just broke it when dumbing it down to fit on the slide :/
My implementation uses std::exchange in the close routine on the unique_ptr, and all methods null check the unique_ptr before forwarding to lfs api's

Personally I'm fine with improving the documentation regarding this as the only fix, the technical drawbacks of trying to fix a breach of contract when it's the programmer misusing the library are way too big, and while "make everything explode" seems like a drastic failure mode everything would be broken anyway because the API contract has been breached.


Supress ButterKnife.inject() needs to be called

How can I suppress this lint?

This library has no lint rules so it's coming from somewhere else.


urgent--npm run build error

Found an issue or bug with electron-vue? Tell me all about it!
Questions regarding how to use electron or vue are likely to be closed as they are not direct issues with this boilerplate. Please seek solutions from official documentation or their respective communities.
Describe the issue / bug.
#To ensure your native dependencies are always matched electron version, simply add script "postinstall": "electron-builder install-app-deps" to your package.json`
• writing effective config file=build\builder-effective-config.yaml
• rebuilding native production dependencies platform=win32 arch=x64
• packaging       platform=win32 arch=x64 electron=2.0.18 appOutDir=build\win-unpacked
⨯ remove D:\ync-merchant\build\win-unpacked\resources\app.asar: The process cannot access the file because it is being used by another process.
github.com/develar/go-fs-util.EnsureEmptyDir
/Volumes/data/go/pkg/mod/github.com/develar/go-fs-util@v2.0.1-0.20181113101504-f6630ccc0e93+incompatible/fs.go:101
github.com/develar/app-builder/pkg/electron.unpackElectron.func1.1
/Volumes/data/Documents/app-builder/pkg/electron/electronUnpack.go:39
github.com/develar/app-builder/pkg/util.MapAsyncConcurrency.func2
/Volumes/data/Documents/app-builder/pkg/util/async.go:67
runtime.goexit
/usr/local/Cellar/go/1.12/libexec/src/runtime/asm_amd64.s:1337
Error: D:\ync-merchant\node_modules\app-builder-bin\win\x64\app-builder.exe exited with code 1
at ChildProcess.childProcess.once.code (D:\ync-merchant\node_modules\builder-util\src\util.ts:244:14)
at Object.onceWrapper (events.js:277:13)
at ChildProcess.emit (events.js:189:13)
at maybeClose (internal/child_process.js:970:16)
at Process.ChildProcess._handle.onexit (internal/child_process.js:259:5)
How can I reproduce this problem?
#When I run NPM run build, but, When I restart the computer, NPM run build again and succeeded.
If visual, provide a screenshot.
Tell me about your development environment.

Node version: 10.15.3
NPM version: 6.9.0
vue-cli version: (if necessary)
Operating System:win32

If you are looking to suggest an enhancement or feature, then feel free to remove everything above.

@DamnTime
i got the same problem.  did you solved it?

主要是因为打包需要的依赖包没有下载下来导致打包失败，可以参考下面网友的踩坑教程：
https://segmentfault.com/a/1190000018533945?utm_source=tag-newest


Update security auth policies/damienbod/rick anderson

Internal review URL
Fixes #15113
@damienbod  I brought your commits from #15103 here. We need to retain previous version. The easiest way to maintain versions is with monikers:
::: moniker range=">= aspnetcore-3.0"
// Copy exiting MDF file here, and update to 3.0
::: moniker-end

::: moniker range="< aspnetcore-3.0"
// Original file here
::: moniker-end

@blowdart  see #15103 for the changes. Because we need to duplicate the files with our current versioning system, the diffs in this PR won't help.
This PR brings over the changes from #15103 and keeps the old version.  Nothing has changed but the boilerplate code the templates generate.

@Rick-Anderson  @blowdart
Is this PR ok, or can I do anything?
Greetings Damien

LGTM


lockups: use expectedErr with error types

Closes partially: #2959
What is the purpose of the change:
Update tests that are using expectPass or expectErr as the bool variable to the error type in the lockup module
all tests pass

Going to close this for now and we can potentially reopen after further discussions


add caret as alternate keybinding for bol

for those who have ^ ingrained in their muscle memory.
see https://github.com/ronisbr/TerminalPager.jl/issues/27

Thanks!!


Split workflows

Using if condition branches is a bit messy work flow.
Splitting linux workflow into apt and yum should be simple.

I'll merge this PR after Amazon Linux 2 package is built.

Amazon Linux 2 rpm package is built successfully:
https://github.com/fluent-plugins-nursery/td-agent-builder/actions/runs/136689355


Custom Emojis + Hashtags in post annotations

Custom Emojis or Hashtags in post annotations do not work.

Speaking about this, custom emojis are not supported in nicknames too this works on mastodon appearantly.
Same with the notification panels.
In nicknames mastodon resizes them to a smaller size too so that it fits the text.

For reference:

Related to https://github.com/syuilo/misskey/issues/1826

Also custom emojis are not working in Talk with a popped out window.

done


cmake: Fix build error when clang is not installed in path

I was getting:
CMake Error at CMakeLists.txt:32 (find_program):
  Could not find CLANG_PATH using the following names: clang

Fix this by using the clang target from the earlier call to:
find_package(Clang CONFIG)

hmm scratch that, I've messed it up


Compose byobu configuration

I like it! Improve my configuration! https://github.com/b3rserker/byobu-config

I like it! Improve my configuration! https://github.com/b3rserker/byobu-config

I tried it, I like it. Create and work with a byobu configuration now.

This is also incorrect. Byobu works /over/ tmux, and should be used as such: https://superuser.com/questions/423310/byobu-vs-gnu-screen-vs-tmux-usefulness-and-transferability-of-skills#423397. Set up a good TUI desktop environment!

do this by need
ive been fine so far, wait till i have to work on a server again so i can properly assess needs


Fix scoverage: inherit repositories from outer project

ScoverageModule submodule inherits ivyDeps from the outer project, not inheriting repositories, which creates problems with resolving when package is in custom repository (#620).

Thank you. I'll merge when tests pass. But please notice, this is not the only issue with the scoverage module right now. See discussion of #640 if you are interested.

@lefou I don't think I have good enough knowledge on mill internals to provide a good solution on that - I just started using it two weeks ago.
I believe generally the problem is that you need to compile all the sources with additional compiler options you don't want in the final build - and it seems that mill doesn't support tasks parametrized by some context, which is why scoverage attempts to clone the original build, but there are many edge cases where it doesn't work. In case of your issue I might try adding def generatedSources = outer.generatedSources as well, but I'm not sure if that's going to work.

@krcz Thanks for this fix! And you're right about the generatedSources I believe.

@lefou Thank you for quick response and merge!


styling hover

Description of the Issue and Steps to Reproduce:
Please include the values of all variables used.
Environment:
Examples: Chrome 49 on OSX, Internet Explorer 10 on Windows 7, Node.JS 4.4.4 on Ubuntu 16.0.4
Both the browser and the OS are important to us, particularly if you have an unsual environment like an IOT application.
Other information that may be helpful:

The time zone setting of the machine the code is running on
The time and date at which the code was run
Other libraries in use (TypeScript, Immutable.js, etc)

If you are reporting an issue, please run the following code in the environment you are using and include the output:
console.log( (new Date()).toString())
console.log((new Date()).toLocaleString())
console.log( (new Date()).getTimezoneOffset())
console.log( navigator.userAgent)
console.log(moment.version)

Ensure your issue is isolated to moment. Issues involving third party tools will be closed unless submitted by the tool's author/maintainer.

Doesn't seem to be an issue reported in there, and I'm not sure what "styling hover" means, so I'm closing this


Not compatible with 1.38.0

After returning to the main menu, there is no main menu.
Logs:
[CRITICAL @ 00:56:22 | UnityEngine] TypeLoadException: Could not resolve type with token 0100005c from typeref (expected class 'HMUI.Screen' in assembly 'HMUI, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null')
[CRITICAL @ 00:56:22 | UnityEngine] BeatmapScanner.HarmonyPatches.UIPatch.Postfix () (at <ac1fb6a17ff44c3eb16c29c115dba72a>:0)
[CRITICAL @ 00:56:22 | UnityEngine] _DidActivate_Postfix_3c289e28_4215_48fc_bc83_9f5a3e55e89a.Patch () (at <68875117d9ab44f7836a1ae2e4adcdbd>:0)
[CRITICAL @ 00:56:22 | UnityEngine] (wrapper dynamic-method) MainMenuViewController.DMD<MainMenuViewController::DidActivate>(MainMenuViewController,bool,bool,bool)
[CRITICAL @ 00:56:22 | UnityEngine] HMUI.ViewController.__Activate (System.Boolean addedToHierarchy, System.Boolean screenSystemEnabling) (at <91cd888f641a4b50811d7c30977309f8>:0)
[CRITICAL @ 00:56:22 | UnityEngine] HMUI.ViewController+<DismissViewControllerCoroutine>d__54.MoveNext () (at <91cd888f641a4b50811d7c30977309f8>:0)
[CRITICAL @ 00:56:22 | UnityEngine] UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) (at <6ef01846f2094996aa9c77a64b17827d>:0)
[CRITICAL @ 00:56:22 | UnityEngine] UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator)
[CRITICAL @ 00:56:22 | UnityEngine] HMUI.ViewController:DMD<HMUI.ViewController::__DismissViewController>(ViewController, Action, AnimationDirection, Boolean)
[CRITICAL @ 00:56:22 | UnityEngine] HMUI.FlowCoordinator:DMD<HMUI.FlowCoordinator::DismissFlowCoordinator>(FlowCoordinator, FlowCoordinator, AnimationDirection, Action, Boolean)
[CRITICAL @ 00:56:22 | UnityEngine] MainFlowCoordinator:HandleSoloFreePlayFlowCoordinatorDidFinish(LevelSelectionFlowCoordinator)
[CRITICAL @ 00:56:22 | UnityEngine] SinglePlayerLevelSelectionFlowCoordinator:DMD<SinglePlayerLevelSelectionFlowCoordinator::BackButtonWasPressed>(SinglePlayerLevelSelectionFlowCoordinator, ViewController)
[CRITICAL @ 00:56:22 | UnityEngine] HMUI.FlowCoordinator:HandleScreenSystemBackButtonWasPressed()
[CRITICAL @ 00:56:22 | UnityEngine] HMUI.ScreenSystem:<Awake>b__24_0()
[CRITICAL @ 00:56:22 | UnityEngine] UnityEngine.EventSystems.ExecuteEvents:Execute(GameObject, BaseEventData, EventFunction`1)
[CRITICAL @ 00:56:22 | UnityEngine] VRUIControls.VRInputModule:ProcessMousePress(MouseButtonEventData)
[CRITICAL @ 00:56:22 | UnityEngine] VRUIControls.VRInputModule:Process()
[CRITICAL @ 00:56:22 | UnityEngine] UnityEngine.EventSystems.EventSystem:Update()

Loloppe is aware through Discord. I'm posting here for tracking and visibility.

Fixed, check the latest release.
https://github.com/Loloppe/BeatSaber_BeatmapScanner/releases/tag/1.5.10


support reading AV1 tracks with WebRTC

Codecov Report

Merging #1768 (019e4b0) into main (225220d) will decrease coverage by 1.25%.
The diff coverage is 50.57%.

: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    #1768      +/-   ##
==========================================
- Coverage   63.11%   61.86%   -1.25%
==========================================
  Files          91      101      +10
  Lines       10087    10413     +326
==========================================
+ Hits         6366     6442      +76
- Misses       3270     3515     +245
- Partials      451      456       +5

Impacted Files
Coverage Δ

internal/formatprocessor/av1.go
0.00% <0.00%> (ø)

internal/formatprocessor/h264.go
77.67% <0.00%> (ø)

internal/formatprocessor/h265.go
76.29% <0.00%> (ø)

internal/formatprocessor/processor.go
40.00% <0.00%> (-4.45%)
:arrow_down:

internal/rtmp/message/extended_metadata.go
0.00% <0.00%> (ø)

...al/rtmp/message/extended_mpeg2ts_sequence_start.go
0.00% <0.00%> (ø)

internal/rtmp/message/extended_sequence_end.go
0.00% <0.00%> (ø)

internal/rtmp/message/extended_sequence_start.go
0.00% <0.00%> (ø)

internal/rtmp/message/set_peer_bandwidth.go
0.00% <0.00%> (ø)

internal/rtmp/message/set_window_ack_size.go
0.00% <0.00%> (ø)

... and 29 more

... and 4 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more