How subscribe to events to receive recognition results for SpeechRecognizer.startContinuousRecognitionAsync Method

Android platform please.
There is less documents. And i have not find any code to do that.

Thanks for question,
You can do for example as below to register to recognizing or recognized events in your Android project
public class MainActivity extends AppCompatActivity implements View.OnClickListener {

    private void RecognizingHandler(SpeechRecognitionEventArgs e) {
        final String s = e.getResult().getText();
        Log.i(logTag, "Intermediate result received: " + s);
    }

    private void RecognizedHandler(SpeechRecognitionEventArgs e) {
        final String s = e.getResult().getText();
        Log.i(logTag, "Final result received: " + s);
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        ActivityCompat.requestPermissions(MainActivity.this, new String[]{RECORD_AUDIO, INTERNET}, requestCode);

        try {
            speechRecognizerConfig = SpeechConfig.fromSubscription("your key", "your region");
            recognizer = new SpeechRecognizer(speechRecognizerConfig);
            recognizer.recognizing.addEventListener((o,speechRecognitionResultEventArgs) -> {
                RecognizingHandler(speechRecognitionResultEventArgs);
            });
            recognizer.recognized.addEventListener((o, speechRecognitionResultEventArgs) -> {
                RecognizedHandler(speechRecognitionResultEventArgs);
            });
        }
        catch (Exception ex) {
            System.out.println(ex.getMessage());
            displayException(ex);
            return;
        }
    }
}


Upgrade Fabric and gunicorn to avoid final current security bugs

Patches two remaining security bugs that Snyk is complaining about. No change to the APIs for those two libraries; I did a quick check to make sure some of the fab commands were still working well on my local machine.

I merged and then realized that gunicorn is throwing errors for me with the update:
fab app
[localhost] local: gunicorn -b <IP_ADDRESS>:8000 --timeout 3600 --debug --reload app:wsgi_app
usage: gunicorn [OPTIONS] [APP_MODULE]
gunicorn: error: unrecognized arguments: --debug

Fatal error: local() encountered an error (return code 2) while executing 'gunicorn -b <IP_ADDRESS>:8000 --timeout 3600 --debug --reload app:wsgi_app'

Aborting.


Allow for proofs without premises

It also fixes the way the tests are done. Note that one test now fails because of that (having multiple premises for a subproof causes a syntax error, the test checks for a proof error, but the check was done incorrectly)

I will review it on Sunday. Great contribution, thanks!


blueprint prefix, route wildcard, and params not cooperating

I think these are all the relevant steps...

Turn on the blueprints prefix, ex 'v1'
to work around prefixing in routes, I did 'get /v*/myModel/:id/someRoute': 'myController:someRoute'
call the route GET /v1/myModel/8/someRoute
req.params.all() returns { '0': '8', id: '1' }

I'm not sure what you're going for with the /v*.  Are you trying to do API versioning?  Does this issue help?

Yes, sorry for the lack of clarity.
I was trying to do versioning with the URL.  I wanted to avoid re-writing the routes file in a version bump, so I was using the wildcard.
Yes I believe that issue is a workable solution.  Will try and implement that this week.

Very good.  As for the issue with req.params.all, that is...odd, but seems like a general Express router issue, so I'll close this one out.


ProcessRunner needs Redirect Standard Input

This might seem like a bit of an unusual request, but ProcessRunner needs to implement the ability to redirect stdin.  So, IProcess needs a StreamWriter StandardInput { get; }, and ProcessSettings needs a bool RedirectStandardInput { get;set; }.
The use case is developing an addin for Android's sdkmanager utility.  Unfortunately they don't provide a command line argument to accept the license agreement, so we have to pipe in y\r\n to stdin in order to accept the license during the process being run.
I've worked around this in my addin by basically subclassing Tool and creating my own RunProcess method which returns an object with a reference to the stdin stream.  Because of the way some members are marked private, I pretty much had to reimplement the whole class (fetching the toolpath, etc).

@Redth Sounds like a good idea.
To follow the existing code style of IProcess, perhaps we could make it public StreamWriter GetStandardInput()?

I need this too.

var toolPath = File("path/to/tool.exe");

var args = new ProcessArgumentBuilder();
args.Append("arg").AppendQuoted("arg2");

using (var process = new Process
{
    StartInfo = new ProcessStartInfo(toolPath, args.Render())
    {
        RedirectStandardInput = true,
        UseShellExecute = false
    }
})
{
    process.Start();

    process.StandardInput.WriteLine("password");

    process.WaitForExit();
    if (process.ExitCode != 0) throw new Exception(toolPath.Path.GetFilename() + " returned exit code " + process.ExitCode + ".");
}

In the meantime, this works:
var toolPath = File("path/to/tool.exe");

var args = new ProcessArgumentBuilder();
args.Append("arg").AppendQuoted("arg2");

using (var process = new Process
{
    StartInfo = new ProcessStartInfo(toolPath, args.Render())
    {
        RedirectStandardInput = true,
        UseShellExecute = false
    }
})
{
    process.Start();

    process.StandardInput.WriteLine("password");

    process.WaitForExit();
    if (process.ExitCode != 0) throw new Exception(toolPath.Path.GetFilename() + " returned exit code " + process.ExitCode + ".");
}

Any updates on this? I was going to submit a PR to the DockerLogin cake add-in to support passing in the password via stdin (to avoid a warning that shows on standard error), but it seems that's not possible with the current state of the IProcess framework.

Updates on this would be in this thread. In the meantime, Process.Start is a pretty usable API. 😊


Add iCloud in CI for basic API test

https://github.com/steilerDev/icloud-photos-sync/blob/main/.github/actions/test/api/action.yml
We may only be able to perform simple login validation. Is this necessary?

Is this necessary?

Necessary? Yes.
We currently don't have a dedicated CI account, and clearly, we can't use our daily use account for CI purposes.

Is this necessary?

Necessary? Yes.
We currently don't have a dedicated CI account, and clearly, we can't use our daily use account for CI purposes.

The account needs to be associated with the phone.. Actually, f2a is related to the serial number of the device that may be trusted...If this CI is successfully established, I suggest blocking this CI from other services besides icloud testing.


Whats the default download path?

Might sound really stupid, but I have no idea where its downloading the music to.

Well, I found one of the things that downloaded, in the system 32 folder.

any way to change default?

Yes, you can pass the -p or --path with a directory that you wish to download to. Also, if you want, you can organize within that directory (or the default directory) based on artist using -f.


Remove wrong CAST AST Node in coral-hive

What changes are proposed in this pull request, and why are they necessary?

There are two mechanisms in v3 for building abstract syntax trees (ASTs): operators and rewrite rules.
-> Using the antlr3 rewrite symbol ^ tree construction operator
By inspecting all the AST nodes produced by the grammar files, we can see that KW_CAST is not used as a node in the Hive AST. The AbstractASTVisitor is designed to visit all non-DDL AST nodes, so KW_CAST needs to be removed.
I wrote a simple demo that prints the AST including the CAST syntax. It is transformed into a TOK_FUNCTION node, which validates the above points.
String src10 = "SELECT id,name,CAST(salary AS FLOAT) as salary_float FROM employees";
ASTNode root = parseDriver.parse(src10).getTree();
System.out.println(root.dump());
nil
   TOK_QUERY
      TOK_FROM
         TOK_TABREF
            TOK_TABNAME
               employees
      TOK_INSERT
         TOK_DESTINATION
            TOK_DIR
               TOK_TMP_FILE
         TOK_SELECT
            TOK_SELEXPR
               TOK_TABLE_OR_COL
                  id
            TOK_SELEXPR
               TOK_TABLE_OR_COL
                  name
            TOK_SELEXPR
               TOK_FUNCTION
                  TOK_FLOAT
                  TOK_TABLE_OR_COL
                     salary
               salary_float
   <EOF>

How was this patch tested?

Test: The ParseTreeBuilderTest.java contains tests with SQL that includes the cast method. All Hive tests have passed.

@wmoustafa Please help review it.

There are two mechanisms in v3 for building abstract syntax trees (ASTs): operators and rewrite rules.
-> Using the antlr3 rewrite symbol ^ tree construction operator

Could you clarify what is the relationship between this intro and the PR? Especially the current coral-hive does not use Hive 3? Also, when stating v3 it is better to state it is v3 of which project, probably Hive.

While it is a good catch, I am not sure if it is sufficient to delete it based on the current tests passing. We probably need to dig deeper to find when this token is used since there might be other test cases that depend on it. Coral uses a suite of thousands of views to validate changes against internally and we might have to validate this through that framework. @KevinGe00 FYI.

There are two mechanisms in v3 for building abstract syntax trees (ASTs): operators and rewrite rules.
-> Using the antlr3 rewrite symbol ^ tree construction operator

Could you clarify what is the relationship between this intro and the PR? Especially the current coral-hive does not use Hive 3? Also, when stating v3 it is better to state it is v3 of which project, probably Hive.

V3 is used by Hive1 with ANTLR v3. This fix is based on Hive1 and the description has been clarified.


Write upgrade guide

I wrote a guide for users upgrading Chainer from v1 to v2. It includes changes that have not been merged to the _v2 branch yet, and some items whose specification is not fixed yet are left blank. The presentation for those who want to quickly skim the important changes could be improved more; let's discuss this point. Feel free to add any comments on other points, too.

I turned on the build on readthedocs. You can read the current version of the upgrade guide here: http://docs.chainer.org/en/v2-upgrade-guide/upgrade.html

Please add type_check.eval for users who make own functions. #2136

Added the changes on type checking APIs.

Could you add chainer.config.cudnn_deterministic to configuration.rst ?

@bkvogel Could you proofread the grammar if you haven't?

Both "Chainer v2" and "Chainer 2.x" are used to indicate next major version. Use either of them.

Same is true to "Chainer v1" and "Chainer 1.x"

Could you add the change that L.ConvolutionND and L.DeconvolutionND add bias vector by default (originally raised as #2018, which was resolved by #2185).

I will check release notes, issues, and PRs to check missing changes.

I added explanations of keep_graph_on_report and cudnn_deterministic to configuration.rst.

I added just 1 comment on grammar. Also, please change "codes" to "code" since only the singular form is used. LGTM other than that.

I added a note on layer freezing feature provided by UpdateRule.

@bkvogel Thank you, I fixed these points.

Since I have merged #2769 which breaks compatibility of the GRU API, could you add a mention of the following from that PR:
In Chainer v1, :class:~chainer.links.GRU was stateless,
as opposed to the current implementation.
To align with the naming convension of LSTM links, we have changed
the naming convension from Chainer v2 so that the shorthand name
points the stateful links.
You can use :class:~chainer.links.StatelessGRU for stateless version,
whose implementation is identical to chainer.linksGRU in v1.

Thank you, I added the note on GRU.

LGTM except comments. Please merge the latest _v2 branch.


Test Flowzone PR 509

Auto-generated by https://github.com/product-os/flowzone/pull/509
Will be closed automatically once the PR is merged.

Auto-closing pull request


Using provider caching with existing .terraformrc having provider_installation block defined.

@levkohimins
Since the original issue is now closed I created this one for visibility.
Unfortunately, v0.63.3 didn't fix our issue. Still seems like network_mirror is not respected. The error says that it's trying to call default terraform registry to install providers instead of pulling it from jFrog as configured in our .terraform.rc file.

Hey @nuryupin-kr, thanks for the feedback. In this time, I used your example for integration test, it should work now for sure.

I wonder if us setting TF_CLI_CONFIG_FILE env var to point to our .terraformrc file prior to running any Terragrunt has to do with it failing for us. As far as I understand Terragrunt should merge our .terraformrc with configuration of its own and then set TF_CLI_CONFIG_FILE to point to the new merged configuration, am I correct?
NOTE that when I remove our .terraformrc and not setting TF_CLI_CONFIG_FILE, Terragrunt is able to pull providers from default registry.terraform.io, but it fails to discover provider that we pre-download manually to terrgrunt-hcl-working-dir/terraform.d/plugins/. Seems like Terragrunt doesn't look at that location where Terraform does.
Please, let me know what other info can I provide for context to understand the problem better.

@nuryupin-kr.

I wonder if us setting TF_CLI_CONFIG_FILE env var to point to our .terraformrc file prior to running any Terragrunt has to do with it failing for us. As far as I understand Terragrunt should merge our .terraformrc with configuration of its own and then set TF_CLI_CONFIG_FILE to point to the new merged configuration, am I correct?

Yeah, correct, this is how it works.

NOTE that when I remove our .terraformrc and not setting TF_CLI_CONFIG_FILE, Terragrunt is able to pull providers from default registry.terraform.io, but it fails to discover provider that we pre-download manually to terrgrunt-hcl-working-dir/terraform.d/plugins/. Seems like Terragrunt doesn't look at that location where Terraform does as part of their implied local mirrors directories.

I found a bug with include and exclude directives when try to use your example, I have fixed and the release will be out soon.

Also, since we are executing Terraform/Terragrunt exclusively in the Github Workflows, we are setting credentials to our jfrog registry using the following line in the workflow: TF_TOKEN_myorg_jfrog_io: ${{secrets.JFROG_API_KEY}}. Terraform knows how to extract the part after TF_TOKEN_ so it's authenticating us to our registry without having to run terraform login command due to the process being non-interactive. In my attempts to fix our issue I just discovered that if I supplied myorg_jfrog_io to TERRAGRUNT_PROVIDER_CACHE_REGISTRY_NAMES env var, I get the following error:

I can't say for sure right now. it may work, since we use http proxy and it must transmit all headers with the request. Need to check.

@nuryupin-kr, could you try v0.63.6 release?

@levkohimins
Just tried it with v0.63.6

Without .terraformrc:
Works for all the providers except for pre-downloaded provider. Terragrunt still attempts to look for it in the registry.terraform.io instead of terrgrunt-hcl-working-dir/terraform.d/plugins/.

With .terraformrc:

Terragrunt still tries to pull providers from registry.terraform.io ignoring config from network_mirror block.

I've also tried to move .terraformrc file to a default directory $HOME/.terraformrc to avoid setting TF_CLI_CONFIG_FILE env var. However both times got same error which means the env var is not a problem.

With .terraformrc + setting TERRAGRUNT_PROVIDER_CACHE_REGISTRY_NAMES=myorg.jfrog.io:
Fails to pass through credentials from setting TF_TOKEN_myorg_jfrog_io: ${{secrets.JFROG_API_KEY}}

Is there an alternative way to specify credential?

Additional Context:
Env vars we set for terragrunt:
TERRAGRUNT_NON_INTERACTIVE: true
TERRAGRUNT_INCLUDE_EXTERNAL_DEPENDENCIES: true
TERRAGRUNT_PROVIDER_CACHE_REGISTRY_NAMES=myorg.jfrog.io - tried it on and off
for terraform:
TF_CLI_CONFIG_FILE: path/to/our/.terraformrc
TF_TOKEN_myorg_jfrog_io: ${{secrets.JFROG_API_KEY}}
TF_IN_AUTOMATION: true probably not needed
Full Terragrunt Command:
terragrunt run-all plan -lock-timeout=30m -out=tf_plan --terragrunt-provider-cache

I'm going to try running with TERRAGRUNT_LOG_LEVEL: debug and see if I can get more specific error information

Also just to make it clear - without setting --terragrunt-provider-cache flag, everything is working.

I've also just tried to use cat to read TF_CLI_CONFIG_FILE after Terragrunt fails, but it appears that env var is not set in the next step, which is odd :/

I really cannot understand why it is not working on your environment. I tested locally three provider installing methods together and it worked as expected. Could you provide a full log with running env var TERRAGRUNT_LOG_LEVEL=trace as well as .terraformrc ?

Fails to pass through credentials from setting TF_TOKEN_myorg_jfrog_io: ${{secrets.JFROG_API_KEY}}
Is there an alternative way to specify credential?

At the moment no, but we are implementing so that TF_TOKEN_* works

So maybe our problem is that Terragrunt can't pick up those credentials? Also, I'm not sure if I should use TERRAGRUNT_PROVIDER_CACHE_REGISTRY_NAMES in our case at all since we already have it configured in our .terraformrc

Yes, you need to specify in TERRAGRUNT_PROVIDER_CACHE_REGISTRY_NAMES all the provider registry names that you cache. This is most likely the reason why network_mirror does not work, for example:
--terragrunt-provider-cache-registry-names example.com --terragrunt-provider-cache-registry-names registry.opentofu.org --terragrunt-provider-cache-registry-names registry.terraform.io

When I provide TERRAGRUNT_PROVIDER_CACHE_REGISTRY_NAMES for our jfrog, I get this:

Since we are running in non-interactive mode in the Github Actions pipeline, I cannot use terraform login. Instead, I have to use TF_TOKEN_myorg_jfrog_io: ${{secrets.JFROG_API_KEY}}. Is there any other way to pass in credentials so that Terragrunt can recognize it?

@nuryupin-kr,

Since we are running in non-interactive mode in the Github Actions pipeline, I cannot use terraform login. Instead, I have to use TF_TOKEN_myorg_jfrog_io: ${{secrets.JFROG_API_KEY}}. But since it is currently not supported, is there any other way to pass in credentials so that Terragrunt can recognize it?

The current implementation of Terragrunt's provider cache does not allow to specify any credentials,  some requests it proxies, but when downloading assets it creates a request from scratch without any credentials. Please create a new issue with a request to add authentication to the Terragrunt provider cache to avoid messing up the .terraformrc issue with credentials.