.NET Core 2.0 MSI

Hi,
Is there an MSI version of .NET Core 2.0 (SDK or, preferably, WindowsHosting) available?
If not -- why not? Many (legacy) distribution systems still use MSI as the primary (and sometimes only) method of distribution. I understand that we can build MSI ourselves from the provided ZIP archives, but maybe you should consider adding MSI builds to the official distribution.
Thank you.

The exe installations that are offered for .NET Core and the Windows Hosting Bundle are based on MSI's but they are chained together using a boostrapper exe. Are you looking for something with a .msi extension and you can't use the .exe's that have msi's in them? Like this one? https://aka.ms/dotnet-sdk-2.0.0-win-gs-x64

To be most specific, I need the WindowsHosting that could be installed as an MSI package. Certain tools (like Puppet or Amazon Elastic Beanstalk) that bring systems to a desired state are picky about what is considered a "package" and often use the MSI product ID to check if it should be installed or on on the next state update phase. There of course are clumsy ways to fix this, but providing MSIs along with other methods seems like the most "right" way to do this.

@onyxmaster https://github.com/dotnet/core/blob/master/release-notes/download-archives/2.0.0-download.md#windows-server-hosting

@nil4 I do not understand what do you mean. You copied the same link I provided. It does not contain the WindowsHosting package in MSI form.

@onyxmaster apologies, I did not notice that the download link points to an exe file and not an MSI.  I see now what you mean.

You can use the exe and it will install a set of msi's. They have product codes that could be used to detect and maintain successful installation.

Unfortunately, they can't be installed with "msiexec /i " or via WindowsInstaller.Installer COM object. Well, I have a workaround mentioned above, so if you do not feel like this should be changed, go ahead and close the issue. Thank you for considering the options.

I've thought about this a bit more. There is a hacky option and a good option. The hacky option is that there is a tool that can be run to extract the msi's out of the exe. Those could then be chained together in puppet or anything else.
The better option would be to make this first class and generate everything as part of the builds where we build the exe's to also give other types of definitions for how to install the msi's directly in the right order.

I'm still all up for first-class option, workarounds tend to break in the long run.

What is your primary focus? Do you need the SDK or really just the runtime that includes .NET Core and the ASP.NET Runtime Store?
Would you be interested in helping on the first-class solution?

The cheapest first step I think would be to add links somewhere to just the msi's with instructions on how to chain them together. All those msi's I believe are available on public url's.

I've got a bunch of Windows 2012/2012R2/2016 Servers that I would like to continue to be managed by our puppet installation when we move to .NET Core. Currently they are provisioned semi-automatically and then are never logged into unless a production-level PerfView recording is needed. With MSIs we (and probably other shops with similar setups) can do this easily and without fear of breaking something.
We only need hosting package (runtime + store).

If I can be of any help -- sure, by my MSI knowledge is mostly limited to building service deployments with WIX.

@joeloff do you know of a link to the runtime store msi's that a doc could point to? I can try to get the links for the runtime msi's.
@onyxmaster I don't think msi knowledge would be needed. I was more thinking someone like you could contribute anything that would take the msi's and wrap them in puppet so other folks could also use puppet to install the msi's.

The best part with puppet on Windows is its native MSI support. It's basically one line, where you specify the package source and, optionally the product id (to verify if the specific version is installed).

We have a separate bundle for just the runtime stores or for the hosting bundle (which contains the runtime, runtime package store and ANCM). We don't ship the MSI individually because of reference counting.
There are links on https://www.microsoft.com/net/download/core#/runtime for the hosting bundle and on https://github.com/dotnet/core/blob/master/release-notes/download-archives/2.0.0-download.md#aspnet-core-package-store for the individual package store bundles.

@joeloff doesn't reference counting happen with CA's in the installers or is it all at the bundle level?

Also, Ansible (we're considering moving to, also considered more modern among the configuration management systems) has the same level of MSI support, along with Chef. Excluding containers, these three are, as far as I know, the most widely used CM systems.

@richlander as well as FYI

@Petermarcu the reference count is done through a CA in the MSI, but it's done at the bundle level. We currently ship the MSIs for the stores in three bundles: SDK, Server Hosting and a standalone store only bundle. When you install the MSIs directly in environment where these bundles are present.

We rebuild machines when we repurpose them, with Windows machines it happens rarely, because the only software we install after provisioning is updates to the Windows itself and updates to our monitoring agents.

We're not looking to integrate .NET core into installer WIMs though, we prefer base installer to be as unchanged as possible.

@onyxmaster Would another option here be for us to provide puppet classes that do the right things for the exe's we already provide?

It looks like if there was a chocolatey module, then it would be easy to include our exe's in puppet. https://forge.puppet.com/puppetlabs/chocolatey
Do you use chocolatey for anything else?

Looks like there are community packages for .NET Core 2.0 runtime and ASP.NET Core 2.0 Runtime store available in chocolatey.
https://chocolatey.org/packages/dotnetcore-runtime.install
https://chocolatey.org/packages/aspnetcore-runtimepackagestore/2.0.0

Seems like we should just help make those packages work well :) https://github.com/jberezanski/dotnetcore-chocolateypackages
@jberezanski :)

I took a quick peek. The current package checks for IISExpress, which is not supported by the hosting bundle. We only redist ANCM for IIS in the hosting bundle. IISExpress ANCM is supported in VS for development.
Having IIS is also not a requirement, only if you want to use ANCM. If IIS is absent, the bundle will just skip the ANCM package and install the rest: the runtime and package store

@joeloff do you want to try to make a PR to their repo to fix that?

Hi all,
The dotnetcore-windowshosting Chocolatey package is designed to install the ANCM (and only the ANCM).

If the user requests Chocolatey to install the dotnetcore-windowshosting package, the expected result after the installation is that the ANCM gets installed on the machine. That is the reason for the IIS/IIS Express precondition check in the package installation script: because the installation bundle skips installing the ANCM if neither of them is installed, it would not make sense for the dotnetcore-windowshosting package to report successful installation if nothing is actually installed on the system.

The runtime and the package store have their own packages (dotnetcore-runtime.install and aspnetcore-runtimepackagestore). Required dependencies are modelled using package dependency (the dotnetcore-windowshosting package depends upon aspnetcore-runtimepackagestore) and they are resolved by the package manager. Installation of optional dependencies (the runtime) is left to the discretion of the user*.

*At least, this is how things worked in 1.0 and 1.1. I can see that the 2.0 hosting bundle does not respect the OPT_INSTALL_LTS_REDIST and OPT_INSTALL_FTS_REDIST flags anymore and installs the 2.0 runtime anyway. Is this a bug or intentional? (If the latter, then https://github.com/aspnet/AspNetCoreModule/blob/dev/README.md should probably be updated.)
From packaging standpoint, it would be most convenient if you distributed an installer containing the ANCM only.

The check for IIS is definitely good to have since ANCM will fail if IIS isn't present. However, the bundle doesn't carry ANCM for IISExpress so that check is not necessary. We only carry ANCM for IISExpress as part of Visual Studio.
As for the commandline flags, there is a bug tracking to update them for 2.1.0. In 2.0, we don't currently have an LTS/FTS stream, there's only a single runtime.

Indeed, the bundle does not install the ANCM for IISExpress. Honestly, I have no idea what made me believe otherwise back when I made the package for 1.0.0. I will remove all IISExpress related code.
Would it be possible for you to publish ANCM MSIs for packaging purposes? This would save people some bandwith - they would not have to download the entire hosting bundle (containing components which would not be used anyway, because they would already have been installed by other packages).

I'll raise this with the ANCM owners. In the past we refrained from doing that because it breaks the reference counting for ANCM when installing the hosting bundle. But if ANCM were to create a separate bundle we could use that. FYI @shirhatti

@joeloff is there a repo where the issue of tracking a standalone ANCM installer should be. I don't think anyone is tracking issues here.

We had an internal email thread. @shirhatti might know if we have any other issues tracking it

I opened this issue to make sure there is one to track the ANCM standalone installer. I'm going to close this one now and that work can be tracked here: https://github.com/aspnet/Home/issues/2236


Extended folder as input still using one output file.

Alter plugin logic such that if an input directory is specified AND an output file, then the output file will be created in the sub-directory associated with the original file.
This fixes a bug with same setup:  All input files are processed into the same, single output file, so last input file processed, wins.

Coverage decreased (-5.4%) to 77.586% when pulling 6dab1f95a5fa5a8d1f5dec8a7f705475a4302867 on muddysteel:development into 0c34919210416c7da78060494689e257004cf758 on Swagger2Markup:master.

Could you please extract this and write a unit test.

I will - haven't because one hand is in a cast.. /-:

You last commit added to many company specific changes

Yep.  Thought i was on a "new" repo/branch.. Just undid it; will add unit test to extend coverage and re-commit.

Need to implement a logger and "enable" to cover missed logging code branches... ;)

It's fine now. Code coverage check is green :) Thx.

Is there a repo i can pick up SNAPSHOTs from?  Or, will you be promoting to a new (minor) release shortly?

Please see http://swagger2markup.github.io/swagger2markup/1.3.1/#_snapshot_2

LOL  -- tks!  (RTFM)

You are welcome

One last - and might be i'm looking at SNAPSHOTs wrong: The maven plugin SNAPSHOT shows last snapshot is at 1.1.1-SNAPSHOT.
Is there somethng you need to trigger?
(URL: http://oss.jfrog.org/artifactory/oss-snapshot-local/io/github/swagger2markup/swagger2markup-maven-plugin/)

Indeed. Publish failed in TravisCI. I have to look at it next week.


Add the ability to use withCredentials for CORS and cookies in the Settings

+1 This is needed

Unfortunately this causes my app to crash with 'setting is not defined' when I patch it in place of the official http library... I'll do some poking around and see if I can fix it.

Unfortunately this causes my app to crash with 'setting is not defined'.  I think you meant 'settings?'

I've now tested this change and it works fine with setting changed to settings in Http.js.  Would be nice to have this merged into master as I'm relying on it for a small production app.

@jazmit Thanks!

@evancz Any chance of merging this before the next release?

@evancz Any thoughts on this? Is there anything I can do to help move this along?

I can confirm that withCredentials works great, but this PR will not work until if (setting.withCredentials) { is changed to if (settings.withCredentials) {. @yogsototh can you make that change. Then can we get this merged in @evancz? I will gladly grab @yogsototh's changes and fix that one typo if need be.

I am out of m'y computer reach this week. @codedmart do mind to make the fix for me? Thanks!

I'll bring this in for the next release. 0.16 requires that everything gets bumped, so I'll be able to get to it in the next week or so. Sorry for the long delay here!

@evancz If @yogsototh has not been able to make the update before you bring this in I can do a new PR or I can do a new PR now if that would be better. I can't edit this PR.
@evancz Thanks for all your hard work.

Thanks for the PR and for checking to make sure it works!


InteractGrab: Remember kinematic state

I noticed objects that were set to kinematic were not properly supported. I added a 'wasKinematic' variable that is set when an object is grabbed and then used to restore the state when the object is released.
Also, both types of grabs (SetControllerAsParent and CreateJoint) now explicitly set the kinematic state so they work properly when the object was originally set to kinematic.

 Closing this and making a new pull request with those commit messages cleaned up.


Command language

Command language proposal
In mimtproxy, users interact with addons (and by extension with mitmproxy itself) ONLY through commands and options. Commands have globally unique names, a set of typed arguments, and a single typed return value. The command language is the textual language users use to invoke and combine these typed addon commands.

Command invocation is in the style of Python function invocation, but without commas to separate arguments. In the top scope, brackets can optionally be omitted. In inner scopes brackets are mandatory. Invoked commands are executed once immediately when a command string is run.
Deferred commands are command invocations preceded by a &. Deferred commands are executed every time they are used as a value.
Command pointers are command invocations preceded by a *. Command pointers are used as a value, with the command and all arguments passed to a receiving command. They are not invoked by the command language itself - whether and how to evaluate a command pointer is up to the receiving command. In our type notation we write a command pointer type as *cmd.
A source<T> yields a possibly infinite stream of items of type T. Sources are the return value from a source command. The Python representation is as yet undefined, but these might be represented as asynchronous iterators or queues.
A sink<T> accepts a stream of items of type T. Concretely, a sink<T> accepts values of type T, [T] and source<T>, and can be considered to be a union of these types. Sinks are the first argument of a sink command. The Python representation is as yet undefined, but might be iterators over asynchronous iterator objects or consumers of asynchronous queues.
Two-sided pipe commands. A command can be both a sink and a source, by accepting a sink as its first argument, and returning a source.
Pipes are denoted with the | operator, and link sinks and sources by passing the LHS as the first argument to the RHS. A command string can compose multiple pipe components into a pipe chain by using two-sided pipe commands. If a pipe chain ends with a source, the final source's emitted values are consumed and discarded. Using the | symbol with a non-sink command on the RHS is a type error. Sources can only be used with the pipe operator.
Pipe variables. Within a pipe component, the variable $this can be used for the current pipe item. We can define this precisely by imagining a command each sink<T> *cmd -> source<U>. This command inspects the arguments to *cmd to find all occurances of $this. It then reads values from the sink, executes *cmd with occurances of $this replaced by the current value. If the command returns a value, that value is written to the output source. Otherwise, the input value (which may have been modified in-place) is written to the output source.
Arrays are enclosed in [].
Strings are the primary value type in the language. Strings can be quoted if they contain special characters, or unquoted if they don't.
Type shorthands Each type can define a string format that is dynamically expanded into the underlying type. This can be a complex expansion. For example, for flows the string is resolved by selecting flows from the current view. So wherever a flow, [flow] or sink<flow> occurs, a simple flow selection shorthand x is equivalent to view.select(x). The implementation of the resolving function might be different for different tools.

Commands
The following commands are used in the examples below. These are for illustrative purposes and might not be precisely what we have in the core.
client.replay sink<flow>
console.choose str [str] -> str
console.command [str]
each sink<T> *cmd -> source<U>
export.file sink<flow> format path
export.formats -> [str]
filter sink<flow> str -> source<flow>
random [str] -> str
setheader flow str str
tap event -> source<flow>
time -> str
view.select str -> [flow]

In the above, T and U are generic types.
Examples
1
client.replay "~h google.com"

2
"~h google.com" | client.replay

Since client.replay accepts a sink<flow> argument, the filter specificaiton string is resolved using view.select. It is equivalent to:
view.select "~h google.com" | client.replay

Or
client.replay(view.select("~h google.com"))

3
tap request | filter "~h google.com" | export.file json ~/foo.json

4
@marked | setheader $this foo bar

This command has an implicit each, and is equivalent to:
@marked | each *setheader($this foo bar)

5
@marked |
setheader $this foo bar |
client.replay

This command has an implicit each, and is equivalent to:
@marked |
each *setheader($this foo bar) |
client.replay

6
tap request |
filter "~h google.com" |
setheader $this foo bar |
export.file json ~/foo.json

7
console.command [
    @focus "|" export.file
    console.choose(Format export.formats())
]

8
tap request |
setheader(
    $this
    "Host"
    console.choose(
        Host
        ["google.com" "yahoo.com"]
    )
)

The console.choose function is invoked once whent he command first run. The header is set to the same value for each flow.
9
tap request | setheader($this "Date" &time())

The time function is invoked anew every time it's used as a value, so the header is always set to the current time, and might have a different value for each flow.
Error examples
10
Type error. Notionally infinite sources may only be used with the pipe operator.
client.replay(tap(request))

11
Syntax error. Pipes are only valid in the outermost scope.
client.replay(
    @marked | setheader $this foo bar
)

12
Type error. Pipes can only used with a sink on the RHS:
export.formats | random

The correct invocation would be:
random export.formats()

We're converging, but there are a few remaining doubts and disagreements:

Both @resam and @mhils feel that example 10 and possibly 11 should not be errors. I'm afraid of surprising users with commands that hang infinitely, and would prefer to clearly signal those with pipes. I also fear that nested pipes will be confusing and can't be defined rigorously (for instance, what's the behaviour if we have two separate pipe chains in a compound command?). I could be convinced on 10 IF we have an execution model that doesn't unexpectedly block interaction for the user on infinite commands.
I've included command pointers in the proposal, despite previous discussion. On more reflection, I think it's the only rigorous way to define what the $this pipe variable does, and will be useful in other contexts. I'm now pretty strongly in favour of including this in the core language. I'm open to two simplifications: 1) using the concept in defining pipe variables, but not actually implementing pointers in the language, OR 2) omitting pipe variables entirely in favour of an explicit each.

After we have consensus on these, we can commit this initial description to the repo as part of the documentation, where we can expand it over time.

Overall language spec draft here. Anyone can add anything -> https://docs.google.com/document/d/1PLytUD2KJuEHr4n0JS7ckJ0KBnnWJvJ_q8eqmhSGE5Y/edit?usp=sharing
I would be very glad to get any recommendation from you or see your additions/corrections!
Talking about a few remaining doubts and disagreements.
Personally I like that we divide commands into finite and infinite commands explicitly. Ordinary commands (chained with parentheses) are alway finite. Pipe commands may be infinite.
But I also don't feel that some of examples 10-12 must raise an error or mustn't. I think we should start implement the language, use it for a while and only then develop logical, well-grounded restrictions relying on the specific situations.
I feel that using the concept of defining pipe variable is better, than using explicit each:

user won't need to remember one more language concept(pointers);
$this variable is pretty readable and looks like allowable magic in my opinion;

@kajojify This looks good to me! A few comments:

Agreed on keeping infinite commands explicit with the pipe operator.
Agreed on the aesthetics of $this. I think we should, however, also have an explicit each command, which is used to define and illustrate the exact behaviour of $this.

I can't wait to get to the point where we have something to play with here. I think a lot of issues will become clear once we have something concrete to work with.

EBNF draft for our commands language
command_line = ( noncommand_beginning , pipe, {pipe} ) | ( command_call_no_parentheses, { pipe } ) ;

noncommand_beginning = flow_selector | filter_expression | array ;
pipe = whitespaces, "|", whitespaces, command_call_no_parentheses ;

command_call_with_parentheses = command, { ws }, "(", arguments_list, ")", { ws } ;
command_call_no_parentheses = command, whitespaces, arguments_list ;

arguments_list = { ws }, [ argument, { whitespaces, argument }, { ws } ] ;
array = "[", arguments_list, "]" ;
argument = plain_str | quoted_str | array | command_call_with_parentheses ;

command = [ "&" ], command_part, { ".", command_part } ;
command_part = flow_selector_part ;

flow_selector = "@", flow_selector_part ;
flow_selector_part = char, { char } ;

filter_expression = quoted_str ;

quoted_str = '"', { full_char | ws }, '"' ;
plain_str = full_char, { full_char } ;

full_char = char | special_symbol ;
char = ( "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" ) | "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i"| "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" | "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "_";
special_symbol = "!" | "@" | "#" | "$" | "%" | "^" | "&" | "*" | "(" | ")" | "+" | "{" | "}" | ":" | "<" | ">" | "?" | "/" | "." | "," | "\'" | ";" | "/" | "]" | "[" | "=" | "-" | "~" ;
whitespaces = ws, { ws } ;
ws =  " " | "\n" | "\r" | "\t" | "\v" | "\f" ; (* All white space symbols should be here *)

As you can see we have some one-word commands like `setheader`, `each`, `tap` etc in our examples. The problem is it is inconvenient to distinguish such commands and plain strings on the lexing stage. So after splitting our command line into tokens, we will have to provide another check in order to define whether plain string is command or not.
I think, that all command (without exceptions) **must** look like `myaddon.command`. So if mitmproxy faces something like `a.b.c.d` in the command line, it tries to invoke such command. If such command exists - ok, if doesn't - error.
Coming back to `setheader`, `each` and similar one-word command, we need them to fit our command notation. But since such top level commands will likely be used very often, we need simple and short names for them.
After the conversation with @cortesi I am proposing to use `.toplevel_command` notation for such commands. We can also use `toplevel_commands.toplevel_commands`. The examples will look like:

.tap request |
.filter "~h google.com" |
.setheader $this foo bar |
export.file json ~/foo.json

or
tap.tap request |
filter.filter "~h google.com" |
setheader.setheader $this foo bar |
export.file json ~/foo.json

@mhils @Kriechi, what do you think?

I'm not sure I like this... it adds a lot of characters to type.
Why is it "inconvenient" during/after lexing?

Why do we need to handle this in the lexer? Why not check it in the next stage (the parser)?

The thing is I don't think the idea to check each plain string is rational. Why do we need to check anything, if we can't avoid any checks, stating that if plain string has dot, then it is command?

This proposal is compelling to me. It makes what is and isn't a command clear both visually and syntactically. At the moment, we can have a phrasing like this:
 foo | my.command

It's not clear here whether foo is a command or the string "foo".  A fallback here is to say that IF there's a command called "foo" a naked string is considered to be a command invocation, else it's a string. This is not clear visually, though, and behaviour can differ based on what addons are loaded. It can also result in confusing behaviour for the user, if their intent is to invoke a function but they really get a string expanded behind the scenes. It's much clearer to say that naked strings in command-form ("."-delimited, or with a leading ".") are always commands. If you want them to be a string you have to quote them. Now this is a command invocation, which will give an error if the foo command doesn't exist:
 .foo | my.command

And these are strings:
foo | my.command
".foo" | my.command

There's a bigger picture here too. I want to start enforcing name prefixing for addons, so that all commands will be of the form addonname.command and options will be addonname_command. However, we clearly want our own addons to be able to put commands in the "top scope" without prefixes, and I'd argue we should give user addons this ability as well. If we define .foo to be an alias for foo.foo that gives us a very elegant way to handle the situation. Each addon can introduce one global command, commands stay confined within the addon module so there's no encapsulation issue, and it's pretty easy to explain to users what's going on. So, for instance, we currently have a top-level cut command. That would become cut.cut (the addon name prefix would be added automatically), and the user would be able to invoke this as cut.cut or just as .cut.

@kajojify @Kriechi Just so that we don't block on this, let's go with the unambiguous period-delimited commands for the moment. Unambiguous commands in the lexer is the simplest thing at this point, and we can relax that constraint later. These are fine points about the "hand feel" of the language, and I think we need working examples to try it out before another round of bikesheddingdesign discussions.

I've just updated the language proposal to include unambiguous delimited command names. I've also added another concept that cropped up while playing with concrete use cases - semicolons to indicate multiple independent commands to be executed in sequence.
Let's now give @kajojify room to implement. After we have something to play with, we can do another round of design tweaks.


Fail to Installation

Hi,
I tried to install earth2grid following the instructions. But it fails as follows:

Do you have any idea what's going on?

Hi. It's hard to tell. What version of python/pip are you using?

I try to install it with the following environment:
python=3.10.4
pip=22.1.2
And I updated the pip to the latest version (pip-24.2), but it failed again.
Do you have any comments about the required environment?
Thanks.

huh. I've run on python=3.10 (and probably lower).
Looking at your error, I think it is not interpreting the string earth2grid as a file path but as a package name instead. It fails to find anything named earth2grid in the public repositories.
To fix, please run
pip install --no-build-isolation ./earth2grid

The "./" will force pip to interpret the argument as a path.
I'll fix the typo in the docs.

Resolved by c493e48e2dffdde4162e6af0ad67f84527616795


Momentum space offdiagonal allocations

Offdiagonals for the momentum space models were allocating. This PR fixes that.
The problem only appears on the master branch of Julia, which is why the benchmarks don't show any improvement. There, allocations go from tens GiB to tens of MiB per run.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

70 of 70 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.03%) to 80.966%

Totals

Change from base Build 999217383:
0.03%

Covered Lines:
2463

Relevant Lines:
3042

💛  - Coveralls

I was hoping this could fix #81 but so far no avail.

Can we test for allocations? I.e. write test that fails if fciqmc_col!() allocates (testing it for different Hamiltonians and and addresses)? Because it shouldn't allocate.

Happy to see allocations gone.
This seems weird, though, as I'm sure that we already eliminated allocations in this code twice. Why are they coming back? Changes in Julia or the packages (StaticArrays)? Or were you testing with longer bitstrings?

I think something changed in the compiler, probably does slightly fewer optimizations to decrease latency.

Can we test for allocations? I.e. write test that fails if fciqmc_col!() allocates (testing it for different Hamiltonians and and > addresses)? Because it shouldn't allocate.

Good idea! I'll add a test like that in the next PR.


Add new options to info addon

Issue: #1152
What I did
Add new options:

maxPropsIntoLine (default is 3)
maxPropObjectKeys (default is 3)
maxPropArrayLength (default is 3)
maxPropStringLength (default is 50)

How to test
Run npm run storybook to see new stories and test it!

@ndelangen I'm trying to avoid pass identical and never changed props to a lot of places. Why context is  not good idea for it?

@ndelangen Hi, of course)


Not Skipping Event Sound

I am playing with your VLC Things.  It's awesome, for starters.  Noticing an issue though.  I set it to play a custom track found in my VLC library... no problems going in and selecting that track.  When I set it to play piano, and then alternatively say OR play my track... it still plays the piano and doesn't play my track:

SmartThings is shutting down its Groovy-based platform at the end of 2022. This project is no longer maintained.


[POC - DO NOT REVIEW] Create two column layout for Templates

Hey, I just made a Pull Request!

:page_with_curl: Summary

POC Option 2 for Two Column Layout - Contributing to Backstage
Template Layout Customization Options Wiki
:page_with_curl: Changes

Adding in option to customize Template Workflow UI

:heavy_check_mark: Checklist

[ ] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[ ] All your commits have a Signed-off-by line in the message. (more info)

PR created in error


TypeError: init() got an unexpected keyword argument 'jwks_uri'

Hello!
I am trying to set up authentication using google in my project. Registered my app with google. I found an example in the documentation:
OAUTH_PROVIDERS = [
    {
        "name": "google",
        "icon": "fa-google",
        "token_key": "access_token",
        "remote_app": {
            "consumer_key": CONSUMER_KEY,
            "consumer_secret": CONSUMER_SECRET,
            "base_url": "https://www.googleapis.com/oauth2/v2/",
            "request_token_params": {"scope": "email profile"},
            "request_token_url": None,
            "access_token_url": "https://accounts.google.com/o/oauth2/token",
            "authorize_url": "https://accounts.google.com/o/oauth2/auth",
            "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
        },
    },
]

But when I go to the authorization page, I get an error message:
Traceback (most recent call last):
File "/opt/project/superset/__init__.py", line 260, in <module>
     update_perms=utils.get_update_perms_flag(),
File "/usr/local/lib/python3.6/site-packages/flask_appbuilder/base.py", line 135, in __init__
     self.init_app(app, session)
File "/usr/local/lib/python3.6/site-packages/flask_appbuilder/base.py", line 156, in init_app
     self.sm = self.security_manager_class(self)
File "/usr/local/lib/python3.6/site-packages/flask_appbuilder/security/sqla/manager.py", line 39, in __init__
     super(SecurityManager, self).__init__(appbuilder)
File "/usr/local/lib/python3.6/site-packages/flask_appbuilder/security/manager.py", line 201, in __init__
     obj_provider = self.oauth.remote_app(provider_name, **_provider['remote_app'])
File "/usr/local/lib/python3.6/site-packages/flask_oauthlib/client.py", line 78, in remote_app
     remote = OAuthRemoteApp(self, name, **kwargs)
TypeError: __init__() got an unexpected keyword argument 'jwks_uri'

I can't understand what's the matter, because the example is from the documentation. Please help me solve this problem.

Hi, this package is authlib not Flask-OAuthlib.


Add support for access and volume mode in storage mapping

When a storage mapping is created, the only information we have is the destination storage class name. However, this is not sufficient, because some access modes and volume modes are not support by Kubevirt, e.g. Ceph + Filesystem or Cinder + RWX. So, we shouldn't allow unsupported access and volume modes.
The idea is to implement a storage support matrix that would be used to validate access and volume modes for the destination storage classes, as well as provide intelligent default values for each provisioner type. The support matrix would be stored in a Config Map managed by the operator and mounted in the controller and UI pods.
The access modes are documented in Kubernetes > Persistent Volumes > Access Modes.
The volumes modes are documented in Kubernetes > Persistent Volumes > Volume Modes.
The list of provisioners that support block mode is available in Kubernetes > Persistent Volumes > Raw Block Volume Support.
A possible format for the support matrix is:
---
- kubevirt_version: v2.5.0
  supported_storages:
  - provisioner_name: kubernetes.io/aws-ebs
    access_modes:
    - ReadWriteOnce
    volume_modes:
    - Block
    - Filesystem
  - provisioner_name: kubernetes.io/rbd
    access_modes:
    - ReadWriteOnce
    - ReadOnlyMany
    volume_modes:
    - Block
    - Filesystem
  - provisioner_name: kubernetes.io/glusterfs
    access_modes:
    - ReadWriteMany
    - ReadWriteOnce
    - ReadOnlyMany
    volume_modes:
    - Filesystem

Recommend:
---
- kubevirtVersion: v2.5.0
  provisioners:
  - name: kubernetes.io/aws-ebs
    accessModes:
    - ReadWriteOnce
    volumeModes:
    - Block
    - Filesystem

VMIO currently supports setting the volume mode on the Storage and Disk mappings, and I'm working on support for setting the access mode.
// StorageResourceMappingItem defines the storage mapping of a single resource from the provider to kubevirt
// +k8s:openapi-gen=true
type StorageResourceMappingItem struct {
	Source Source           `json:"source"`
	Target ObjectIdentifier `json:"target"`

	// +optional
	VolumeMode *corev1.PersistentVolumeMode `json:"volumeMode,omitempty"`
	// +optional
	AccessMode *corev1.PersistentVolumeAccessMode `json:"accessMode,omitempty"`
}

https://github.com/kubevirt/vm-import-operator/pull/438

@jortel, proposing the following format:
---
- kubevirtVersion: v2.5.0
  provisioners:
  - name: kubernetes.io/rbd
    modes:
    - volumeMode: Block
      accessModes:
      - ReadWriteOnce
    - volumeMode: Filesystem
      accessModes:
      - ReadWriteMany
      - ReadWriteOnce

You can see that Ceph-RBD doesn't support ReadWriteMany when volume mode is Block, while it supports it when volume mode is Filesystem. I named the fields modes, but if you have something better, I'll follow.

Rather than a yaml matrix file, I think separate (new) CRs for each provisioner may be more idiomatic for k8s.  I discussed with @shawn-hurley and he agreed.  The operator would install these CRs for the appropriate version of k8s.  The user would e free to add/update/delete.
Perhaps something like:
---
apiVersion: forklift.konveyor.io/v1alpha1
kind: Provisioner
metadata:
  name: rbd
  namespace: openshift-migration
spec:
  - name: kubernetes.io/rbd
    features:
    - SmartCloning
    - Snapshots
    volumeModes:
    - name: Block
      features: []
      accessModes:
      - name: ReadWriteOnce
        features: []
    - name: Filesystem
      features: []
      accessModes:
      - name: ReadWriteMany
        features:
        - LiveMigration
      - name: ReadWriteOnce
        features: []

@fdupont-redhat Thoughts?

@jortel, I'm fine with whatever you prefer. Will there also be a controller for this new CRD?


Checking if SLIC is initialized from another library erroneously returns false

There seems to be a bug in the static initialization of SLIC. When axom is linked to a standalone library, libfoo.a  and subsequently, axom and libfoo.a are linked to a driver that initializes slic. Checking if slic is initialized inside libfoo.a erroneously returns false.

This sounds like what I described in #29 w.r.t. linking against a Fortran application.

Thanks @kennyweiss -- I am seeing this in just C++ code. I'll investigate further.

Can we re-engineer to avoid "static" initialization?

Can we re-engineer to avoid "static" initialization? @kennyweiss do you recall any details about this issue?

@rhornung67 -- I think that would be a good idea!
Here's what I found:

https://github.com/LLNL/axom/blob/3fb7909d36255a3cf19325221561f2a6501f70b8/src/axom/slic/interface/slic.cpp#L24
https://github.com/LLNL/axom/blob/3fb7909d36255a3cf19325221561f2a6501f70b8/src/axom/slic/core/Logger.cpp#L354
https://github.com/LLNL/axom/blob/3fb7909d36255a3cf19325221561f2a6501f70b8/src/axom/slic/core/Logger.cpp#L19
https://github.com/LLNL/axom/blob/3fb7909d36255a3cf19325221561f2a6501f70b8/src/axom/slic/core/Logger.hpp#L338

Looks like the the latter should be marked as extern instead of static.
See: https://stackoverflow.com/questions/14349877/static-global-variables-in-c
Alternatively, the problem might go away if we make s_logger a static variable in getActiveLogger() instead of having it be a global variable in slic.

I think what is happening, due to static linking, is that there are actually multiple instances of s_Logger : the one linked to by the main executable gets initialized, but the instance that exists for the static library is uninitialized.  As long as codes use static linking, I suspect this kind of problem is unavoidable.  PR #799 partially mitigates this problem: at least the libfoo.a and all other libraries will get a minimally-configured slic, but every time a code links statically to a library that doesn't do its own slic, the code will get the warning banner added in the PR.
I'm in the process of confirming this.

It seemed like there may have been more than one Axom Slic getting initialized.  But I compiled a test executable with static linking all around and was not able to reproduce the problem using C++ only.  I have yet to throw Fortran into the mix.
Specifically, on Linux, C++ test application App linked statically to Axom and to static library libtest.  Libtest also linked statically to Axom.  Initializing Slic in App resulted in an initialized Slic in libtest (echoing your experiences, @white238 ).  Retrieving the active logger (the underlying object) from both App and libtest showed it has the same address (what you had previously pointed out, @kennyweiss ).
I have a feeling that even if this bug was a problem in C++ codes at one time (note @gzagaris ' comments from two years ago), it is a much smaller problem now.  I don't know that this should hold up the release.

PR #870 moved the logger map and logger pointer into singletons.  However, CDash testing seems to report that there is a problem with Fortran usage of SLIC loggers.

We think this is fixed. So closing. Can re-open if needed.


Attempt to execute su

attempt to execute su and check return code

This could potentially be detrimental for anyone that uses the library. According to this StackOverflow answe, executing su using Runtime.getRuntime().exec actually creates a new process each time it is executed.

@andrewjli The comments on that stackoverflow post indicate that this bug can be worked around if you use ProcessBuilder instead of exec. Suggest anyone attempting to implement  it using something like the following
new ProcessBuilder().command("su").start()


Allow user to be able to select and download forest extent datasets for any given year or all years

offering the entire tile (if it is forest extent) or entire dataset if it is vector data.

We don't currently support tile-based downloads, so we'll have to see if that's the actual data format being used. Vector download is straightforward.

displaying approximate file size and expected time to download

Browsers do this once the file starts downloading. To provide this information before the download starts would be harder.

Issue moved to TerriaJS/CarbonFarming #6 via ZenHub.io


Some questions about the paper

Hi, thanks for your great work!
I have some little questions about the paper:

It seems like anchor points $A$  are attached to initial 3D Gaussians?
How long does spring-gaus is trained on the real-world samples? It looks like the paper only present details on synthetic data.
what is registration network? As is shown in the paper, three viewpoints are insufficient for 3D Gaussians, it is related to sparse-view reconstruction and I think it also can be a interesting and difficult problem. How can you train the dynamic 3DGS/4DGS on the sparse-view input, can you provide more details?

Yours sincerely,
Guanjun

Hi Guanjun, thank you for your issue.

Anchor points are independent from 3D Gaussians, we just compute anchor points' initial position from Gaussian kernels' centers.
Almost same to synthetic data.
We first use 50-100 images to train a static 3DGS, which has different position/rotation and shape with the initial state of 4DGS. So, we use a registration network to align static 3DGS and initial 4DGS.

Best wishes,
Licheng

That sounds interesting!
Does it seem like if we have a well-trained 3D scene, 4D Gaussians can be trained with only 3 camera(sparse view) supervision?


Will not work on Synology

Hi - I am using a docker-compose file on a Synology NAS running Portainer.  When I run the image, it starts up fine, but I can not get to the 8181 portal.  I have set my USER_ID and GROUP_ID the same as every other container and do not have this problem.  I forwarded my router port 80 to this machine 8080, same for 443 to 4443.  Is it conflicting with the internal Synology Nginx?
Here is my docker-compose:
version: "3"
services:
nginx-proxy-manager:
container_name: Nginx-proxy-manager
image: jlesage/nginx-proxy-manager:latest
ports:
- 8181:8181
- 8080:8080
- 4443:4443
environment:
- USER_ID:1026
- GROUP_ID:101
- TZ:America/NewYork
#- DISABLE_IPV6=1
volumes:
- /volume3/DockerConfig/Connect/Nginxpm:/config:rw
But here is the error I get when I look at the log:

I have this container working on my DS920 and it works fine, but I use the native Synology Docker container manager. Looking at the log, I would check your volume is correctly formatted and the USER_ID and GROUP_ID are correct.


make factscore use chatgpt for atomic fact generation

@martiansideofthemoon here's the code i used to make atomic fact generation use the chat api rather than the legacy completion api

To make the changes work, you need to use the openai version 0.28. You might want to update the requirement.txt file accordingly.


Add wrapped function to str/repr of custom_jvp

Can we add a custom repr/str to custom_jvp that includes the original function? We use jax.nn.relu as a default value for some params and these are now rendering a bit weirdly (example: https://dm-haiku.readthedocs.io/en/latest/api.html#mlp).
>>> import jax
>>> repr(jax.nn.relu)
'<jax.custom_derivatives.custom_jvp object at 0x7f1216ce4ef0>'

Great idea.

By the way, my original hope was that functools.update_wrapper would do this kind of thing, but it doesn't for class instances. (In fact, I'm not sure if that line does anything useful right now...)

@mattjj It sets __name__ and __doc__ on self, which you can use in __repr__.  It is also useful if someone applies a decorator to a custom_jvp instance, e.g., functools.partial.


FavoriteFilters in FavoriteScreen differ between Figma and actual display.

Overview
The following two points are likely to be different

FavoriteFilterChip padding is narrower than Figma
In Figma, the background color is always the same as that of TopAppBar, but the actual display is different.

Figma
actual

Might be helpful for you

As for padding, we don't set padding in FavoriteFilterChip, and I think we can fix it only by setting Modifier.

I want to work on this issue!🙋♂

Thanks! Assigned 👍


Fix bug causing reconciliation to fail

Changes proposed in this PR

Fix bug with processed-tasks in reconcile-tasks

Why are we making these changes?
Reconciliation is currently not working

Awaiting green build.


Build shaded jars as the current maven build does.

Add config to build shaded jars and include then in tests as maven build does

Codecov Report

Merging #927 into master will increase coverage by 0.06%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##             master    #927      +/-   ##
===========================================
+ Coverage     99.34%   99.4%   +0.06%
  Complexity     2168    2168
===========================================
  Files           327     327
  Lines          6064    6060       -4
  Branches        334     329       -5
===========================================
  Hits           6024    6024
  Misses            5       5
+ Partials         35      31       -4

Impacted Files
Coverage Δ
Complexity Δ

.../tessera/admin/cli/subcommands/AddPeerCommand.java
100% <0%> (+2.63%)
11% <0%> (ø)
:arrow_down:

.../quorum/tessera/sync/SyncResponseMessageCodec.java
100% <0%> (+3.22%)
5% <0%> (ø)
:arrow_down:

...ain/java/com/quorum/tessera/p2p/RestP2pClient.java
100% <0%> (+6.89%)
9% <0%> (ø)
:arrow_down:

Continue to review full report at Codecov.

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


fix: lint errors

Fixed prettier plugin tailwindcss
Ran eslint --fix inside the ui-components directory

I recommend merging this PR last and performing and pushing one last 'npx eslint --fix' before merging.


Feature Request: helm repo credentials from env vars

For authenticated repositories, the credentials are stored in plaintext in ~/.helm/repository/repositories.yaml. To further improve security, the user should have the option to use environment variables to store credentials, so they could script together their OS's keychain access (example) to populate those variables and avoid storing any password in plaintext on their filesystem altogether.
Given a helm repo that requires authentication, when the user runs helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username env.FANTASTIC_CHARTS_USERNAME --password env.FANTASTIC_CHARTS_PASSWORD, then the following entry is added to ~/.helm/repository/repositories.yaml:
  name: fantastic-charts
  url: https://fantastic-charts.storage.googleapis.com
  username: env.FANTASTIC_CHARTS_USERNAME
  password: env.FANTASTIC_CHARTS_PASSWORD

Given the above configuration, when helm needs to make a request to the fantastic-charts repo, then helm resolves the username and password from the environment variables FANTASTIC_CHARTS_USERNAME and FANTASTIC_CHARTS_PASSWORD respectively.

For reference, #3206 was the original PR that added authentication for private repositories, and @ankushchadha you might be interested in this one given your comment on https://github.com/helm/helm/issues/3092#issuecomment-378773562.

While usage of environment variables avoid exposing the password in the plaintext file and even on the terminal (using cmds like history, etc), the printenv cmd can still expose sensitive information. One of the ways to avoid this problem can be to use expirable access tokens instead of using actual password value.

@eyalbe4, @rimusz  - WDYT?

While usage of environment variables avoid exposing the password in the plaintext file and even on the terminal (using cmds like history, etc), the printenv cmd can still expose sensitive information. One of the ways to avoid this problem can be to use expirable access tokens instead of using actual password value.

In my humble opinion, if you want to get token from somewhere, you will use (user, pass, key, secret etc.) again. And again you will have to store them in somewhere? @ankushchadha
If someone could execute history or printenv on your OS. That mean you gave access grant permissions to user?

Has any movement on the problem of repo passwords being stored in the clear in repositories.yaml happened since Oct 2018?

I have not seen any movement from the community on this feature. I'd be happy to see a PR from the community implementing this functionality so that passwords can be fetched from your operating system's keyring.

@bacongobbler Do you think this would be a good beginner project?  I haven't contributed to Helm before, so don't want to bite off more than I can chew, but thinking through this it shouldn't be that difficult (famous last words) to implement some sort of integration with the OS X keychain

depends on how comfortable you are with Go, I suppose. Docker has a library to interact with the OS keyring. Perhaps that may be worth investigating to see how that can be used within Helm.

I would prefer a more generic approach to this request. Instead if integrating every possible keychain and encryption method I really like the simple solution of restic by reading a password from an external command. https://github.com/restic/restic/pull/2094
I'm aware that restic only requires a password and helm needs username:password combination or a token. The credentials command/store could be referenced/stored in the repositories.yaml like docker is doing this with credential helpers: https://docs.docker.com/engine/reference/commandline/login/#credential-helpers
The corresponding command will be searched in the PATH folders. A default read credentials from env vars named XY helper script could even be provided by the helm project and installed along site to fulfill the most common case reading from environment variables.

Here is a shell based solution to this issue on MacOS using the security app to save and pull passwords from the keychain.  History does not contain the password.
Example is uploading a helm chart to a harbor registry)
# security add-generic-password -a ${USER} -s harbor -w "$(jq -r '.token' ~/Downloads/robot-test-helm.json)"
# helm push test-chart-1.5.2.tgz https://harbor.aws-dev.irondev.io/chartrepo/testrepo --username  'robot$test-helm' --password  "$(security find-generic-password  -s harbor -w)"
Pushing harbor-1.5.2.tgz to https://harbor.aws-dev.irondev.io/chartrepo/ironnet...
Done.

Here is a shell based solution to this issue on MacOS using the security app to save and pull passwords from the keychain.  History does not contain the password.
Example is uploading a helm chart to a harbor registry)
# security add-generic-password -a ${USER} -s harbor -w "$(jq -r '.token' ~/Downloads/robot-test-helm.json)"
# helm push test-chart-1.5.2.tgz https://harbor.aws-dev.irondev.io/chartrepo/testrepo --username  'robot$test-helm' --password  "$(security find-generic-password  -s harbor -w)"
Pushing harbor-1.5.2.tgz to https://harbor.aws-dev.irondev.io/chartrepo/ironnet...
Done.

How about we just stop the “in the clear” part as a no brainer to start off
with while we all debate the best solution until the end of time huh guys?
On Sat, 23 Jan 2021 at 06:23, Todd Wells<EMAIL_ADDRESS>wrote:

Here is a shell based solution to this issue on MacOS using the security
app to save and pull passwords from the keychain. History does not contain
the password.
Example is uploading a helm chart to a harbor https://goharbor.io/
registry
security add-generic-password -a ${USER} -s harbor -w "$(jq -r '.token' ~/Downloads/robot-test-helm.json)"
helm push test-chart-1.5.2.tgz https://harbor.aws-dev.irondev.io/chartrepo/testrepo --username  'robot$test-helm' --password  "$(security find-generic-password  -s harbor -w)"
Pushing harbor-1.5.2.tgz to https://harbor.aws-dev.irondev.io/chartrepo/ironnet...
Done.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/helm/helm/issues/4723#issuecomment-765633108, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJ3QO6DINNR4PTZ6QDQ2ELS3HGDFANCNFSM4FYJOYTA
.

How about we just stop the “in the clear” part as a no brainer to start off
with while we all debate the best solution until the end of time huh guys?
On Sat, 23 Jan 2021 at 06:23, Todd Wells<EMAIL_ADDRESS>wrote:

Here is a shell based solution to this issue on MacOS using the security
app to save and pull passwords from the keychain. History does not contain
the password.
Example is uploading a helm chart to a harbor https://goharbor.io/
registry
security add-generic-password -a ${USER} -s harbor -w "$(jq -r '.token' ~/Downloads/robot-test-helm.json)"
helm push test-chart-1.5.2.tgz https://harbor.aws-dev.irondev.io/chartrepo/testrepo --username  'robot$test-helm' --password  "$(security find-generic-password  -s harbor -w)"
Pushing harbor-1.5.2.tgz to https://harbor.aws-dev.irondev.io/chartrepo/ironnet...
Done.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/helm/helm/issues/4723#issuecomment-765633108, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJ3QO6DINNR4PTZ6QDQ2ELS3HGDFANCNFSM4FYJOYTA
.

In case you'd like to adopt a similar approach, JFrog CLI implemented a simple master key mechanism,, which is used for encrypting the passwords. See the details here. The code is open sourced, so it should be easy to adopt it.

In case you'd like to adopt a similar approach, JFrog CLI implemented a simple master key mechanism,, which is used for encrypting the passwords. See the details here. The code is open sourced, so it should be easy to adopt it.

👍🔥
On Tue, 26 Jan 2021 at 18:31, Eyal Ben Moshe<EMAIL_ADDRESS>wrote:

In case you'd like to adopt a similar approach, JFrog CLI implemented a
simple master key mechanism,, which is used for encrypting the passwords.
See the details here
https://www.jfrog.com/confluence/display/CLI/JFrog+CLI#JFrogCLI-SensitiveDataEncryption.
The code is open sourced, so it should be easy to adopt it.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/helm/helm/issues/4723#issuecomment-767359166, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJ3QO5GZX3ADQUTNFQPY2TS3ZVV7ANCNFSM4FYJOYTA
.

👍🔥
On Tue, 26 Jan 2021 at 18:31, Eyal Ben Moshe<EMAIL_ADDRESS>wrote:

In case you'd like to adopt a similar approach, JFrog CLI implemented a
simple master key mechanism,, which is used for encrypting the passwords.
See the details here
https://www.jfrog.com/confluence/display/CLI/JFrog+CLI#JFrogCLI-SensitiveDataEncryption.
The code is open sourced, so it should be easy to adopt it.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/helm/helm/issues/4723#issuecomment-767359166, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJ3QO5GZX3ADQUTNFQPY2TS3ZVV7ANCNFSM4FYJOYTA
.


Github commit build statuses are not updated when a job is cancelled.

If it is cancelled (by human or 'bot) stop reminding the user to do things

Reviewed post-merge: Approved


skip tombstone when iter rangelist

fixes #629
I add the check and skip logic between raw range => range, all tests passed, but dwarfdump tool is broken, because it expects one to one relationship between raw range and range.
Any idea on how to fix this?

@philipc I fired a pr here, pls take a look?
There are different ways to solve the problem, my considerations:

add a flag on Range struct to indicate it is tombstone. But it will increase range size, which is over kill because tombstone is a rare case.
skip RawRange, which is wrong, RawRange is something raw I think?
keep RawRange, skips Range, which we have both the low level raw info and correct user facing behavior.
So I implemented 3.

I've noted a couple of things that needed fixing. However, I'm not sure yet that this is the approach we want to take. Another option would be to add a method to Range that checks if it is a tombstone.
For dwarfdump, there already isn't a one to one correspondence between RawRange and Range, so this would become an additional check. Having it as a method on Range might make that easier to implement.

I think check against address is better compare to provide a method on Range, Range maybe created by Address calculation, if we didn't check against the Address, then tombstone + offset/length may produce valid address?
Or we do both, check against address, if it is tombstone, then create a Tombstone Range?

I would also like to match LLVM's handling for DWARF v5 at the same time, since this will eventually become the DWARF v6 support. Trying to implement that might give a better feel for what the best approach is.

Do you mean how llvm handling tombstone address or something else? llvm skipped the tombstone range while parsing, I think it is same as what I did in this pr. ref: https://github.com/llvm/llvm-project/blob/2bdfececef4330b3a6489cdb67c57eb771d5f9e4/llvm/lib/DebugInfo/DWARF/DWARFDebugRangeList.cpp#L87

Range maybe created by Address calculation, if we didn't check against the Address, then tombstone + offset/length may produce valid address?

This should be handled in add_base_address.

Do you mean how llvm handling tombstone address or something else?

I mean the DWARF v5 handling: https://github.com/llvm/llvm-project/blob/2bdfececef4330b3a6489cdb67c57eb771d5f9e4/llvm/lib/DebugInfo/DWARF/DWARFDebugRnglists.cpp#L95

Range maybe created by Address calculation, if we didn't check against the Address, then tombstone + offset/length may produce valid address?

This should be handled in add_base_address.

Do you mean how llvm handling tombstone address or something else?

I mean the DWARF v5 handling: https://github.com/llvm/llvm-project/blob/2bdfececef4330b3a6489cdb67c57eb771d5f9e4/llvm/lib/DebugInfo/DWARF/DWARFDebugRnglists.cpp#L95

Thanks, I didn't aware of this 🤣 .. So what I implemented is actually the dwarfv4 logic, and the link you provided is the v5 one? Is it a good idea to implement both? I think v4 is quite common.

Is it a good idea to implement both? I think v4 is quite common.

Yes, this crate aims to support both.

@philipc I've updated the logic to handle both v4 and v5.
Per dwarfdump. I think it is better to untie the RawRange and Range, maybe add a flag to control which set to show. I understand if add we add a method is_tombstone will make dwarfdump's logic easier, but that will leak the tombstone to end user. Also llvm's implementation just ignored the tombstone.

I made a simple change to print ranges first, then raw ranges second, seems not bad.
                    DW_AT_ranges                <rnglist at .debug_ranges+0x00000078 with 2 entries>
                        ranges:
                        [ 0] [00000004, 0000013b)
                        [ 1] [0000013c, 00000194)
                        raw ranges:
                        [ 0] <address pair low-off: 0x00000004 high-off: 0x0000013b>
                        [ 1] <address pair low-off: 0x0000013c high-off: 0x00000194>

Thanks for working on this. I'm going to fix some things and experiment with alternatives. I'll open a new PR and add you as coauthor.


remove broken / obsolete badges

Our pipeline job badge for 1.4 is not working; removing, at least for
now.
We no longer use waffle. Remove it, also.

🙇


Add easy global proxy support

Let electron to support proxy via setting file, the file will auto create in the APPDATA, anyone can edit the file to add/change proxy setting.
After change the setting, user must restart the APP.
Add easy electron menu to show the proxy state.
Test and pass in macbook m1 chips

Thank you @msaong . Proxy is an important feature for ChatALL. Appreciate you work.
I tested your code and meet some problems:

You mentioned the .json file will be auto created. But I can't find any code about creating and get the following error when launching:

Read proxy file failed: Error: ENOENT: no such file or directory, open '/Users/xxxxxxx/Library/Application Support/chatall/proxySetting.json'
App threw an error during load
TypeError: Cannot read properties of undefined (reading 'proxyServer')
    at eval (webpack://chatall/./src/background.js?:35:18)

From you code, I learned that the command line params can change proxy. After reading https://www.electronjs.org/docs/latest/api/command-line-switches , I found --proxy-pac-url maybe is a better choice than --proxy-server if it supports local file. A PAC file can route different site to different proxy (http or socks) or direct connection. What do you think?

If you love the PAC method too, we can make a template and tell users how to edit it as they like.
Thank you agian.

@sunner fix the proxy file auto created now. Please check again.
PAC function is good, i need some time to finish and do some test, just show the new proxy setting menu as below:

Thank you for keeping improving.
PAC mode also supports proxy all requests. So, do we need a proxy mode named All?

pac support is finish.

PAC file example for test, it works, but pac file need to improve:
`function FindProxyForURL(url, host) {
if (shExpMatch(host, ".aliyun.com") ||
shExpMatch(host, ".tiangong.cn") ||
shExpMatch(host, ".xfyun.cn") ||
shExpMatch(host, ".baidu.com") ||
shExpMatch(host, "*.baidubce.com")) {
return "DIRECT";
}
// No proxy for localhost
if (isInNet(dnsResolve(host), "<IP_ADDRESS>", "<IP_ADDRESS>")) {
return "DIRECT";
}
return "PROXY <IP_ADDRESS>:7890; DIRECT";
}`

pac support is finish.

Do you want to implement modifying PAC content in the menus? Perhaps it is hard and lost flexibility. User may use different flavor of PAC.

PAC file example for test, it works, but pac file need to improve samplepac.txt

As I know, the most popular template of PAC is adblockplus. Its document: https://help.adblockplus.org/hc/en-us/articles/360062733293
The attachment is used by me.
proxy.js.txt

pac support is finish.

Do you want to implement modifying PAC content in the menus? Perhaps it is hard and lost flexibility. User may use different flavor of PAC.

It's impossible to modifying PAC content in the electron menus, but add vue files for this purpose is ok.
I use Electron Menu to implement simple proxy management just simply feel that the main code of the current program and this proxy function are independent of each other and easy to maintain

@sunner I make some improve, it's much better

Added proxy configuration feature in the program settings menu"
Removed Electron proxy menu
Added automatic detection of proxy configuration file at program startup"

https://github.com/sunner/ChatALL/assets/25732857/13275873-7feb-463f-97ca-fdbfd62b6a1c

@sunner Commit Again!

Optimized code and UI based on provided suggestions.
Implemented a convenient way to quickly set proxies based on models.
Added confirmation interactions for 'Restart Program', 'Reload Configuration', and 'Reset to Default' functions for better operation assurance.
Cleaned up the previous menu.js file.

You mentioned "The assertion that the proxy can only use the HTTP protocol“ is incorrect. Electron does not limit the use to HTTP proxy only; I can use a SOCKS proxy just as effectively. Therefore, I will retain the original description in the corresponding text.

You mentioned "The assertion that the proxy can only use the HTTP protocol“ is incorrect. Electron does not limit the use to HTTP proxy only; I can use a SOCKS proxy just as effectively. Therefore, I will retain the original description in the corresponding text.

Great! I must misunderstand Electron docs. So how to setup a SOCKS proxy? socks://<IP_ADDRESS>:1080 ? If so, give an example is helpful.

You mentioned "The assertion that the proxy can only use the HTTP protocol“ is incorrect. Electron does not limit the use to HTTP proxy only; I can use a SOCKS proxy just as effectively. Therefore, I will retain the original description in the corresponding text.

Great! I must misunderstand Electron docs. So how to setup a SOCKS proxy? socks://<IP_ADDRESS>:1080 ? If so, give an example is helpful.

The Hint already add the socks' sample

Thank you very much.
Could you resolve the conflicts? A rebasing with the main branch is better.
Now, the files changed includes many diffs which are distraction.

Conflicts resolve.

Optimized finish

Still can't rebase.......Can you resolve this? Or leave it to me.

Still can't rebase.......Can you resolve this? Or leave it to me.

I dont't know what happened. I compare two branch, it seems anything is ok. Any error message ?

git rebase origin/main will get many conflicts.

git rebase origin/main will get many conflicts.

I reviewed the code and found that the conflicts stem from several files that were updated in the main branch today. These files are unrelated to my code. However, I'm not very familiar with Git commands, so resolving this issue would take me a significant amount of time. I think it would be faster if you handled the merge conflict problem.

Thank you very much. The PR will be included in next release.

@msaong I noticed that you are not listed in the contributors. Your code were commit with email<EMAIL_ADDRESS>Is it your GitHub register email or bind email. If not, bind it at https://github.com/settings/emails, then the commit will be counted on you.

@msaong I noticed that you are not listed in the contributors. Your code were commit with email<EMAIL_ADDRESS>Is it your GitHub register email or bind email. If not, bind it at https://github.com/settings/emails, then the commit will be counted on you.

Add the QQ mail now.

Looks like it takes time to take effect


SystemJS/CommonJS interop

Hello, I have an issue involving SystemJS/CommonJS interop and definition files. I can't find any acceptable solution for now.
My app consists of

a server part that compiles to CommonJS
a client part that compiles to SystemJS (flag allowSyntheticDefaultImports on)
a shared part that is imported (copied) into both client and server parts.
I cannot figure out how to import some libs like bluebird or lodash without having either the compiler complaining about something or an exception at execution level. I used definitions files provided by DefinitivelyTyped for bluebird/lodash.

I tried all import syntaxes I could find, but without success
import Promise from 'bluebird'; do not compile on CommonJS,

Module '"bluebird"' has no exported member '_'.

import {Promise} from 'bluebird'; still do not compile on CommonJS,

Module '"bluebird"' has no exported member '_'.

import * as Promise from 'bluebird'; compile on both CommonJS and SystemJS, but crashes during execution, on some functions that directly use Promise as constructor
import Promise = require ('bluebird') old syntax compiles on both CommonJS and SystemJS. But crashes at execution on SystemJS, because Promise cannot be used directly as constructor/function.

Error: TypeError: Promise is not a constructor(…)

Do you have any solutions for this problem ? What is the right way to do in this case ?

I think you are one of the first who experience the issue I described:
https://github.com/Microsoft/TypeScript/issues/7398

The only thing that works for me is modifying .d.ts files and replacing export=Promise by var Promise :
declare module 'bluebird' {     var Promise: PromiseConstructor; }
But I don't think it's a very good solution having to modify definition files..

Right now we need to get a better understanding of what the interop behavior will be. This is contingent on what the NodeJS Core Technical Committee (CTC) decides on.

@DanielRosenwasser yeah, the addition of allowSyntheticDefaultImports made a lot of sense because System were supporting the semantics, and the flag allowed type script to model this behavior. Without the node ecosystem creating

@DanielRosenwasser sorry comma I hit enter prematurely: what I meant to say was that I don't see how TypeScript can solve this problem without runtime semantics provided by node to accommodate easy consumption of default exports. If the semantics are introduced then TypeScript can model them.

@DanielRosenwasser Should (CTC) decides on this or should it be ECMAScript spec group (or if they are closely related / one of the same. :smile:)?
We need to have a full spec of CommonJS -> ES2015 and ES2015 -> CommonJS interop.

I don't necessarily know if the interop problem is one that TC39 itself needs to specify explicitly, though I think there are decisions that could be made there so that the importing a CommonJS module from an ES module, and an ES module from another ES module, are more balanced experiences.
Unfortunately, that doesn't seem to be the case according to the interop draft right now.

Yeah, https://github.com/nodejs/node-eps/blob/master/002-es6-modules.md#5411-examples will still break https://github.com/Microsoft/TypeScript/issues/8840
:sob:

From the wording of the proposal, or at least the disclaimer, it seems that the node community is still thinking about whether they will even adopt support ES6 modules at all. That saddens me quite a bit. It fragments the community.

It is not just node, right?  Browsers also. So it really should be part of language spec.

@unional well the browsers have committed to implementing the standard I suppose at some point. Certainly the module syntax, as it is part of ES2015. But since the browsers themselves don't currently have a competing implementation, projects like SystemJS polyfill it in a forwards compatible way, in the meantime providing de facto standard modules in the browser. The problem is that node has a competing implementation of modules. Considering how much time and energy TC39 spent trying to specify modules in a manner compatible with existing module formats, including CommonJS, it would be a real shame if node never adopted it.

Ah, you are right. Browsers doesn't support commonjs natively..... Dumb me.... :grin:

NodeJS has changed direction? https://github.com/nodejs/CTC/pull/60/files#diff-2b572743d67d8a47685ae4bcb9bec651R217
Most important node:

Therefore cannot import named variables from CommonJS (CJS) modules, e.g.
import {readfile} from “fs”.

So CommonJS modules will provide only a namespace export with default and all
properties will be accessed through that. For example:

import * as express from “express”
var app = express.default()

import express from “express”
var app = express()

Breaking change to TS (to all existing TS code!) if we need to align.

This issue really should be a P1 and fixed asap.
We have people start compiling TS to es6 and any reference to CommonJS will break.
This is now not just systemjs commonjs interop.
It is Babel/NodeJS/SystemJS vs TypeScript interop on CommonJS.
http://stackoverflow.com/questions/42477112/uncaught-typeerror-i18next-init-is-not-a-function/42497453#42497453
@DanielRosenwasser @aluanhaddad @mhegazy

I have creates a repro for this issue: https://github.com/unional/domture/tree/interop-issue
The situation is slightly different than the OP.
In the repro, it simply demonstrate the difference between:
// inside `@unional/logging`
export * from 'aurelia-logging'
import { getLogger as getLog } from 'aurelia-logging'
export { getLog }

When you run the test, you will see that getLog is undefined while getLogger is not.
The situation will be the same if you import using import...require syntax. i.e.:
import L = require('aurelia-logging')
console.log(L.getLogger)  // [function]

import { getLogger } from 'aurelia-logging'
console.log(getLogger) // undefined

cc @blakeembrey
Just notice you are not in this thread 🌷

@unional I've been thinking about this quite a lot...
I think there's a disconnect here that must be directly addressed.
I think there has been a serious problem created by transpiling ES Module syntax to CommonJS semantics.
What this comes down to, to some extent, is that many think that they're using ES Modules when they are not.
There are many different factors in play here... but I think this problem is simply not going to go away and that it is absolutely critical that something is done to address it. I don't know what that should be exactly...

Should be covered by https://github.com/Microsoft/TypeScript/pull/19675

Closing in favor of https://github.com/Microsoft/TypeScript/issues/16093


Typescript support

Would it be hard or at all possible to add the support for Typescript?

Right now I believe yes. Since the webpack config isn't exposed to the user.
We might change this in the future.

We are planning a configuration option for this in the next mayor release. Please check out https://github.com/HaNdTriX/webextension-toolbox/pull/18 for the progress on that.

Good news! I just released the<EMAIL_ADDRESS>Version.
If you want to play around with it install it via:
npm i webextension-toolbox@next

https://github.com/HaNdTriX/webextension-toolbox/tree/next#customizing-webpack-config

We just published Version 1.0.0. You can now add typescript manually:
https://github.com/HaNdTriX/webextension-toolbox#customizing-webpack-config
This is how it could look like:
npm i ts-loader --only=dev

webextension-toolbox.js
module.exports = {
  webpack: (config, { dev, vendor }) => {

    // Add typescript loader
    config.module.rules.push({
      test: /\.tsx?$/,
      loader: 'ts-loader'
    })

    return config
  }
}


feat: change make container-image to work with arm64 architectures

This is a Feature Request
What would you like to be added
Right now, building container images for local use of this repository via make container-image does not work with Apple Silicon chips. This is because the Dockerfile downloads the Hugo binary for amd64 architecture.
I have been able to workaround this issue by explicitly asking for --platform linux/amd64, however, containers built in this way have very poor performance.
Instead, I would like to contribute a Dockerfile that works for arm64 architecture, in a way that contributors can build container images that work in architectures that are not amd64.
Why is this needed
Provide a better contributor experience while creating new documentation pages and testing them locally using containers.

I created pull request https://github.com/kubernetes/website/pull/32100 with a Dockerfile and Makefile target that I have tested to address this issue.

/retitle Docs build container image only supports AMD64 architecture


Observerlocator cannot observe @bindable properties unless they are 'resolved' first

It's not possible to get an observerlocator on an @bindable property:
@inject(ObserverLocator)
export class Welcome{
  heading = 'Welcome to the Aurelia Navigation App!';
  @bindable firstName = 'John';
  lastName = 'Doe';

  constructor(observerLocator)
  {
    //var me = this['firstName'];
    var a = observerLocator.getObserver(this, 'firstName');
    var d = a.subscribe(()=>{});
    debugger;
  }

This throws
heckProperty.getValue (http://localhost:9000/jspm_packages/github/aurelia/binding@0.6.1/dirty-checking.js:77:26) {innerError: RangeError: Maximum call stack size exceeded, stack: (...), message: "Error instantiating Welcome.↵---------------------…ub/aurelia/binding@0.6.1/dirty-checking.js:77:26)"}innerError: RangeError: Maximum call stack size exceededmessage: "Error instantiating Welcome.↵------------------------------------------------↵inner error: RangeError: Maximum call stack size exceeded↵    at Welcome.execute.BindableProperty.configureDescriptor.descriptor.get [as firstName] (http://localhost:9000/jspm_packages/github/aurelia/templating@0.11.2/bindable-property.js:74:37)↵    at DirtyCheckProperty.getValue (http://localhost:9000/jspm_packages/github/aurelia/binding@0.6.1/dirty-checking.js:77:26)↵    at Welcome.execute.BindableProperty.configureDescriptor.descriptor.get [as firstName] (http://localhost:9000/jspm_packages/github/aurelia/templating@0.11.2/bindable-property.js:75:54)↵    at DirtyCheckProperty.getValue (http://localhost:9000/jspm_packages/github/aurelia/binding@0.6.1/dirty-checking.js:77:26)↵   ...
If I 'resolve' the property before gettting the observer, by uncommenting the line
var me = this['firstName'];

Then everything works as expected.

I think aurelia rewrites @bindable props to use getter/setter functions.  Observing these with the ObserverLocator would require dirty-checking.  Would you be able to add a firstNameChanged method to the class instead?

We should be able to fix this. It requires a bit of coordination between the binding system and the templating engine. I'll take a look and see what is needed.

Do you mean: add a firstNameChanged method to be notified of changes instead of using an ObserverLocator to monitor changes?
In that case I'm not 100% sure, the observerlocator is instantiated and used from within the validation plugin, so people would have to add firstNameChanged methods and manually tell the validation plugin that the value has changed for any @bindable property. Feels like a lot of work to set it up.  Also the thing is, in the validation library I was able to patch this by first doing subject.[bindingpath] before calling observerLocator.getObserver(subject, bindingPath). Just doing that, 'resolves' the property, and then I can add an observerlocator without getting the stackoverflow :S Not sure if this causes performance issues or not.
Anyways, the problem seems to be that observerLocator.getObserver has a stackoverflow when accessing the generated getter/setter methods. Probably, those are only generated first time you actually access the object?
Whoops @EisenbergEffect  just commented too :) So here's some additional information :)

It's probably not new information but resolving it doesn't appear to solve the problem as the next time the property is access, in my case I have
user {
    username: null
}
``

To validate username it attaches the validator ok but I guess the binding is kicking in and destroying the validator.

@jdanyow I'll be adding a fix for this tomorrow. The plan is to enable the observer locator to look for a getObserver function attached to the getter function of a descriptor. If that is present it will call that, passing the instance to get the function for. This would allow any custom getter a mechanism to provide its own observer. The templating engine will then take advantage of this hook by configuring its bindable property getters with this function. Let me know if that sounds good to you.

Nice!  This will enable some interesting scenarios and really fine-grained control over the process.

This is fexed by f09451cefb79a85f14b47c89bf6e2c1fa0ac008e and the corresponding templating fix. It will go out in the next release, this week.

:+1:

I couldn't find information about observing arrays. In https://www.danyow.net/aurelia-property-observation/ I only found 'Note: the following doesn't cover Aurelia's strategies for observing Arrays. That's a subject for another post' :)
In my scenario i have a form with validation-errors binded to 'feedback' array:
  <form validation-errors.bind="feedback"...

Then feedback is binded to my custom element:
 <feedback data.bind="feedback" ...

In the custom element I need to watch for changes in feedback array:
@autoinject()
export class Feedback {
    @bindable() data;

    constructor(private observer:ObserverLocator, private bindingEngine:BindingEngine) {
        let subscription = this.observer
            .getObserver(this, 'data')
            .subscribe(this.onChange);

        let subscription2 = bindingEngine.expressionObserver(this, 'data.length')
            .subscribe(this.onChange);
    }

    public attached() {
        let subscription3 = this.bindingEngine.collectionObserver(this.data)
            .subscribe((splices) => alert('changed'));
    }

    dataChanged(newValue, oldValue) {
       alert('dataChanged')
    }

    onChange(newValue, oldValue) {
        alert(`bar changed from ${oldValue} to ${newValue}`);
    }

In that use case, subscription2 is working most properly. subscription and dataChanged are invoked on reference change, not length. subscription3 is invoked too many times, even when length doesn't change. Maybe it helps somebody or maybe I'm doing it wrong:)

@krostkowski
@autoinject
export class Feedback {
  @bindable data: { target: Element, error: ValidationError }[];

  constructor(private bindingEngine: BindingEngine) {
  }

  unsubscribe() {
    if (this.subscription) {
      this.subscription.dispose();
      this.subscription = null;
    }
  }

  dataMutated(splices) {
    console.log('the contents of the array instance changed.');
  }

  dataChanged(newValue, oldValue) {
    console.log(`the array instance changed.  unsubscribing from the old array's mutation events and subscribing to the new array's mutation events.`);
    this.unsubscribe();
    if (this.data) {
      this.subscription = this.bindingEngine.collectionObserver(this.data)
        .subscribe(splices => this.dataMutated(splices));
    }
  }

  unbind() {
    this.unsubscribe();
  }
}

Thank you @jdanyow . I think it should be added to the docs or at least your blog :)


GGShadowService subscription support

Is there any way to configure subscriptions to / from the Local Shadow Service as in Module 5? The lambda I'm working on in #170 will need to interface with the local shadow service, but I'm not sure if there is support for this.

There is support for this but I should have more examples. Converting module 5 to GGP style might be the best way if that’s possible.
This is usually covered by the GGD features. Your deployment can list Greengrass Devices. Those devices are Python scripts and live in the GGDs directory.
See https://github.com/aws-samples/aws-greengrass-lambda-functions/blob/f6ac742bae7170fa8b87f54d72cd87b4550ae555/ggds/discovery-with-shadow/ggd.conf

Awsome! I'll look into this now.


CircleCI can't connect to Postgres

When running tests:
node -e 'const { withDatabase, migrate } = require("./lib/model/database"); withDatabase(migrate);'
Unhandled rejection Error: connect ECONNREFUSED <IP_ADDRESS>:5432
    at Object._errnoException (util.js:1026:11)
    at _exceptionWithHostPort (util.js:1049:20)
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1174:14)

I think postgres just isn't started.

Circle CI is particular about how postgres is run; you can't just spin it up at will. I'm not going to bother with CI until the integration tests are in.


HDDS-4851. More compatibility problem with DatanodeDetails.Port.Name.REPLICATION

What changes were proposed in this pull request?
HDDS-4731 missed some places related to file status where client version needs to be considered for protobuf conversion.  These can be reproduced by ozone fs operations:
$ ozone fs -mkdir o3fs://bucket1.vol1/dir/
$ ozone fs -ls o3fs://bucket1.vol1/dir/
$ ozone fs -put /etc/passwd o3fs://bucket1.vol1/dir/
-put: No enum constant org.apache.hadoop.hdds.protocol.DatanodeDetails.Port.Name.REPLICATION
$ ozone fs -ls o3fs://bucket1.vol1/dir/
-ls: No enum constant org.apache.hadoop.hdds.protocol.DatanodeDetails.Port.Name.REPLICATION

https://issues.apache.org/jira/browse/HDDS-4851
How was this patch tested?
Added acceptance test cases.  0.5.0 client had to be removed from the test due to another incompatibility:
Message missing required fields: getFileStatusResponse.status.status, ...

Thanks for the review @avijayanhwx committing this change.

Thanks @avijayanhwx and @swagle for the review.


README add 3 spaces

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

No thanks

Hi @paulvi, I've pulled request this issue in English and Chinese README before, seems like CLAassistant is a robot.


Chore/upgrade to pact ffi 0.4.22

Update to libpact_ffi 0.4.22
Includes windows plugin shutdown fix
Introduces failures in windows matt plugin tests with tcp connections (solved by calling socket.end/destroy)

thank you 👏


Figure out batching support for trigger

Please add more details to the issue. Is this regarding BatchNumber property or about receiving and writing messages in batches?


The view state does not reset when you drag a file on the view and remove it

Ref: https://github.com/bigbinary/neeto-planner-web/issues/6432

@deepakjosp _a, bug _t.
I am pulling this into M16.


IDE / ETH

Describe the bug
Hello,
The amount on metamask is in IDE on the other hand the same amount on swap.test.taiko.xyz is in ETH (the upper right corner)
Kind regards;
Avitron
Steps to reproduce
Steps to reproduce here.
Additional context
Additional context here.

Bridge UI v1 has been deprecated.


Can't install nativebase on my react native app

Hello, I'm trying to install native base on my react app by it's showing me this error every time I tried running 'npm install native-base --save'
`npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! Found<EMAIL_ADDRESS>npm ERR! node_modules/react
npm ERR!   peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!   node_modules/@gregfrench/react-native-wheel-picker
npm ERR!   peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!   node_modules/@koale/useworker
npm ERR<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!     node_modules/expo-camera
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!   7 more (@react-native-mapbox-gl/maps, ...)
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR! node_modules/native-base/node_modules/react-native-windows
npm ERR!   peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!   node_modules/native-base/node_modules/@react-native-community/datetimepicker
npm ERR<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR!     node_modules/native-base
npm ERR!       native-base@"*" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR! See /Users/jim/.npm/eresolve-report.txt for a full report.
npm ERR! A complete log of this run can be found in:`
I hope someone know a fix :/

Native Base appears to be having significant issues across the board with new react native apps.

Any workarounds? Completely new project and I can't even get past the getting started part for native-base.


Output divergence between DebugIA32 and ReleaseIA32

Isolate (/b/s/w/itD1KudK/dart_fuzzGZOAVO) FP NO-FFI NO-FLAT : KBC-INT-DebugIA32 - JIT-NOINTRINSIFY-ReleaseIA32: !DIVERGENCE! 1.72:1467958387 (output)

-- BEGIN REPRODUCE  --

dartfuzz.dart --fp --no-ffi --no-flat --seed<PHONE_NUMBER> /b/s/w/itD1KudK/dart_fuzzGZOAVO/fuzz.dart

-- RUN 1 --

/b/s/w/ir/pkg/vm/tool/gen_kernel --gen-bytecode --platform=/b/s/w/ir/out/DebugIA32/vm_platform_strong.dill -o /b/s/w/itD1KudK/dart_fuzzGZOAVO/out.dill /b/s/w/itD1KudK/dart_fuzzGZOAVO/fuzz.dart
/b/s/w/ir/out/DebugIA32/dart --enable-interpreter --compilation-counter-threshold=-1 --old_gen_heap_size=128 /b/s/w/itD1KudK/dart_fuzzGZOAVO/out.dill

-- RUN 2 --

/b/s/w/ir/out/ReleaseIA32/dart --intrinsify=false --old_gen_heap_size=128 /b/s/w/itD1KudK/dart_fuzzGZOAVO/fuzz.dart

-- END REPRODUCE  --

cc @bkonyi
Was unable to reproduce this locally.

For dartfuzz reproduction logs, could we get the commit on which the reproduction happened? When the failure is a Dart error (like an assert failure), the error message from Dart will include the commit hash, but in cases like this where it's an output divergence and not a Dart error, we don't have that info available. Given that dartfuzz generation changes over time (I noticed running dartfuzz on both commits mentioned in my comment on dart-lang/sdk#39734 had different outputs), knowing which commit the reproduction happened on is very important.
(If I'm just totally overlooking the commit information in the log pasted above somehow, please do point it out.)

For dartfuzz reproduction logs, could we get the commit on which the reproduction happened? When the failure is a Dart error (like an assert failure), the error message from Dart will include the commit hash, but in cases like this where it's an output divergence and not a Dart error, we don't have that info available. Given that dartfuzz generation changes over time (I noticed running dartfuzz on both commits mentioned in my comment on #39734 had different outputs), knowing which commit the reproduction happened on is very important.
(If I'm just totally overlooking the commit information in the log pasted above somehow, please do point it out.)

I don't think we print the current commit anywhere. Let me see if I can add that for future runs. Thanks for the suggestion!

FYI @sstrickl, I've added the Dart SDK revision to the log output here: https://dart-review.googlesource.com/c/sdk/+/128374

Bytecode mode is removed from Dart VM. Please file another issue if this divergence could be reproduced without bytecode/interpreter.


dead link in http://api.freme-project.eu/doc/0.4/knowledge-base/starting-freme.html

The tutorial says
"You can download the distribution from http://api.freme-project.eu/freme-distributions"
but the link is not working.

The link should point to api-dev.freme-project.eu/freme-distributions from both live and dev version of the homepage.
@josauder please update this.

the link at
http://api.freme-project.eu/doc/0.4/knowledge-base/starting-freme.html
is not updated yet, it still points to http://api.freme-project.eu/freme-distributions

When I installed the new version of the API documentation during the release the link was fixed. But it is only plaintext and not a link. @josauder please make it a link that you can click.

This is now updated in the current Version of the project (api-dev).

thank you


[FLINK-13699][table-api] Fix TableFactory doesn't work with DDL when containing TIMESTAMP/DATE/TIME types

The solution is encode DataTypes.TIMESTAMP() as "TIMESTAMP" when translating to properties.
And will be converted back to the old TypeInformation: Types.SQL_TIMESTAMP.
This would fix all factories at once.

What is the purpose of the change
Currently, in blink planner, we will convert DDL to TableSchema with new type system, i.e. DataTypes.TIMESTAMP()/DATE()/TIME() whose underlying TypeInformation are Types.LOCAL_DATETIME/LOCAL_DATE/LOCAL_TIME.
However, this makes the existing connector implementations (Kafka, ES, CSV, etc..) don't work because they only accept the old TypeInformations (Types.SQL_TIMESTAMP/SQL_DATE/SQL_TIME).
A simple solution is encode DataTypes.TIMESTAMP() as "TIMESTAMP" when translating to properties. And will be converted back to the old TypeInformation: Types.SQL_TIMESTAMP. This would fix all factories at once.
Brief change log

Convert Types.LOCAL_DATETIME/LOCAL_DATE/LOCAL_TIME to "TIMESTAMP"/"DATE"/"TIME" as well.

Verifying this change

Add unit test in TypeStringUtilsTest to verify the conversion from LocalDataTime/LocalDate/LocalTime.

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
The serializers: (yes / no / don't know)
The runtime per-record code paths (performance sensitive): (yes / no / don't know)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (yes / no / don't know)
The S3 file system connector: (yes / no / don't know)

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

cc @JingsongLi  @twalthr , I would appreciate if you could have a look.

Such a change would cause TypeStringUtils to cease to be one that allows back-and-forth conversion.
Another choice is to only modify DescriptorProperties.putTableSchema. What do you think?
But consider TypeStringUtils is deprecated and it is only used in connector schema with logical presentation, I am OK too.

Hi @JingsongLi , IMO, the encoding of TypeStringUtils can not support compatible upgrade, no matter we add LocalDateTime or not.
However, we have the property-version which can be used to backward compatible.
What's your suggestion about modifying DescriptorProperties.putTableSchema?

What's your suggestion about modifying DescriptorProperties.putTableSchema?

Maybe should visit logical type and convert DATE/TIME/TIMESTAMP to SqlTimeTypeInfo instead of LocalTimeTypeInfo.

Sure @twalthr . Will update the PR soon.

Hi @twalthr , I added an HBase IT case to verify DDL with timestamp types. The case include DDL to create both source and sink. It passed in my local machine.

@wuchong feel free to merge it once the built gives green light.

Travis passed in my own repo: https://travis-ci.org/wuchong/flink/builds/573858501
Merged with commits:
b837a589f1bda5d8352e9760af39937f9194c670 d20175ee62cd9b3ce8912745240b57c88c5af51c


[WIP] [HUDI-430] Adding InlineFileSystem to support embedding any file format as an InlineFile

Tips

Thank you very much for contributing to Apache Hudi.
Please review https://hudi.apache.org/contributing.html before opening a pull request.

What is the purpose of the pull request

This PR adds a new FileSystem called InlineFileSystem to support embedding any file format as an InlineFile within a regular file.  InlineFS will be used only in read path.
Have added InMemoryFileSystem as part of the PR for write path.

Verify this pull request
This change added tests and can be verified as follows:

Added tests for InLineFileSystem and InLineFileSystem
Added tests for testing InlineFS for Parquet and HFile format

Committer checklist

[ ] Has a corresponding JIRA in PR title & commit

[ ] Commit message is descriptive of the change

[ ] CI is green

[ ] Necessary doc changes done or have another open PR

[ ] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

Some tests seem to be failing?
Failed tests:
10649  TestInMemoryFileSystem.testCreateWriteGetFileAsBytes:55 array lengths differed, expected.length=80 actual.length=17967
10650Tests in error:
10651  TestParquetReadWriteFlow.testSimpleInlineFileSystem:96->readParquetGenericRecords:125 » IO

@nsivabalan quick update on this? this is ready for review?

@nsivabalan are you still blocked by the test failures for this one?

@vinothchandar : Have fixed the build failures. Patch is good to review.

@nsivabalan awesome. will do..

@vinothchandar : a reminder to review this patch. Or should I ask someone to pitch in?

@nsivabalan its on my queue.. while you wait, can you please move the classes to the final locations..

@vinothchandar : have addressed your comments for the most part. I will wait for 2 days for you to have a final look. If not, will merge it myself as per your suggestion.

@nsivabalan Only one issue I see
I would advise against use of special string in parsing.. if someone for e,g has inline_file in the <path_to_outer_file>, then we are prone to errors? Can you fix it with along these lines?
then once CI parses, please go ahead merge


fix(pattern): fixed circular dependency on card pattern

Related Ticket(s)
#2179
Description
In order to fix a circular dependency issue between CTA and Card, I've replaced the usage of CTA for LinkWithIcon in the Card pattern.

@RaphaelAmadeu can you update your snapshot file?


repository password via keychain mac os

What is the purpose of this change? What does it change?
Add an option to specify the repository password via a MacOS Keychain item.
Was the change discussed in an issue or in the forum before?
I did check the PRs, the issues and the discourse but I didn't find any mention of this.
Checklist

[x] I have read the Contribution Guidelines
[x] I have enabled maintainer edits for this PR
[ ] I have added tests for all changes in this PR
[x] I have added documentation for the changes (in the manual)
[ ] There's a new file in changelog/unreleased/ that describes the changes for our users (template here)
[x] I have run gofmt on the code in all commits
[x] All commit messages are formatted in the same style as the other commits in the repo
[ ] I'm done, this Pull Request is ready for review

I'm not marking this PR as done because I did not add test to the changes.
I also want to wait for insight on how to handle this addition for Linux and Windows.

I can successfully compile restic via go build ./cmd/restic but when I run make the tests fails.
I added the library go-keychain simply by adding "github.com/keybase/go-keychain" to the import list, and VS Code did all the fetching by itself.
I'm assuming there is a specific way to add a library to restic which I did not find in the documentation. Any idea ?

The Go package has been added fine. The build on Travis fails, though.
Also, I honestly don't think this should be integrated in restic, given how much C code it contains. Since restic already supports getting a password from a command, it would suggest writing a CLI wrapper for go-keychain in a separate repo and maybe advertising it in the restic docs.


Version 3

Hi there,
First of all, is this package still alive?
I found out there's a v3.01 available through this link , but it's not listed here on Github.
When using the v3 package, I get the following error:
[webpack-cli] TypeError: Cannot redefine property: tap

I'm using laravel-mix v6.
What can I do to fix this?

I have not updated the package in 2 years, I am not sure if it is compatible with laravel-mix 6. If I have time I can look into this but that is not very likely. Feel free to check it out yourself and submit a pull request or fork your own version. Thanks for using this tool.