Add question answer choices to ANES topics

The way the topics from the ANES are written, each topic can have a unique set of responses. We want our answer choices to match this pattern, and be something we can programmatically ask as a question both prior to and during a discussion. We should expand the current topic descriptions from the anes. They currently are formatted as:
# Federal spending on aid to the poor

## Prompt
What about aid to the poor? Should federal spending on aid to
the poor be increased, decreased, or kept the same?

we can create a separate section to contain the original response options as similar to:
# Federal spending on aid to the poor

## Prompt
What about aid to the poor? Should federal spending on aid to
the poor be increased, decreased, or kept the same?

## Responses
- Increased
- Kept the Same
- Decreased

Lets start by doing this for 5 topics and trying it out to see how it works.

I'm going to pick one topic of each type (Economic, Moral, Civil Rights, Security, and Non-Partisan) that offers 5 choices for responses.

Economic: fs_welfare (federal spending on border security seemed more divisive but that toes the line of security... this question is more geared towards specifically the economy)
Moral: climate_chng_importance
Civil Rights: worry_less_abt_eqlty (Questions asking specifically about inequality of Black people had higher variances and polarity but I'm worried that people will not be open with their true opinions if asked these questions in front of others. This effect may be worth studying down the line but this question about general equality may be better suited for this test drive.)
Security: protesters_actions (Question may have a different connotation in 2022 as opposed to 2020)
Nonpartisan: trust_washington

I updated these issues in the topics repo. Waiting on PR approval.


Fix link to example files

This addresses https://github.com/SweetIQ/schemats/issues/84

@crispmark


Enable Swift 6 mode when available, sync QueryEngine sources

As SwiftPM is more actively developed, let's consider it to be the source of truth and vendor QueryEngine back into swift-sdk-generator together with more fresh AsyncFileSystem code, storing all those files in Source/Helpers/Vendor subdirectory.
All this allows us to fix concurrency errors that prevent it from building in Swift 6 mode.

@swift-ci test

@swift-ci test

@swift-ci test

@swift-ci test

@swift-ci test

Let me check 5.8 compatibility before merging

@MaxDesiatov We need this change against AsyncFileSystem to keep 5.8 compatibility. https://github.com/swiftlang/swift-package-manager/pull/7928
Could you update the vendored files after the PR is merged?

@swift-ci test

@kateinoigakukun done, ready for review


Create connection string and Run database migrations to the production database

The command that provided in the "Create connection string" section is not accurate. Follow the instruction to run the command -'az sql db show-connection-string --client ado.net --server cephalin-core --name coreDB', it generates the connection string pointing to cephalin-core. -->'Server=tcp:cephalin-core.database.windows.net,1433;Database=coreDB;User ID=<username>;Password=<password>;Encrypt=true;Connection Timeout=30;' If use it in the next step-- "Run database migrations to the production database", it will give the errors as below because the Todo table already exist in the coreDB on cephalin-core server that probably created by somebody from Microsoft. The 'cephalin-core' should be replaced with '<server name>' and advise to change it before run the command.
Run migrations
dotnet ef database update
Build started...
Build succeeded.
info: Microsoft.EntityFrameworkCore.Infrastructure[10403]
Entity Framework Core 3.1.3 initialized 'MyDatabaseContext' using provider 'Microsoft.EntityFrameworkCore.Sqlite' with options: None
Done. To undo this action, use 'ef migrations remove'
Build started...
Build succeeded.
info: Microsoft.EntityFrameworkCore.Infrastructure[10403]
Entity Framework Core 3.1.3 initialized 'MyDatabaseContext' using provider 'Microsoft.EntityFrameworkCore.Sqlite' with options: None
info: Microsoft.EntityFrameworkCore.Database.Command[20101]
Executed DbCommand (17ms) [Parameters=[], CommandType='Text', CommandTimeout='30']
SELECT COUNT() FROM "sqlite_master" WHERE "name" = '__EFMigrationsHistory' AND "type" = 'table';
info: Microsoft.EntityFrameworkCore.Database.Command[20101]
Executed DbCommand (3ms) [Parameters=[], CommandType='Text', CommandTimeout='30']
SELECT COUNT() FROM "sqlite_master" WHERE "name" = '__EFMigrationsHistory' AND "type" = 'table';
info: Microsoft.EntityFrameworkCore.Database.Command[20101]
Executed DbCommand (3ms) [Parameters=[], CommandType='Text', CommandTimeout='30']
SELECT "MigrationId", "ProductVersion"
FROM "__EFMigrationsHistory"
ORDER BY "MigrationId";
info: Microsoft.EntityFrameworkCore.Migrations[20402]
Applying migration '20200507162557_InitialCreate'.
Applying migration '20200507162557_InitialCreate'.
fail: Microsoft.EntityFrameworkCore.Database.Command[20102]
Failed executing DbCommand (2ms) [Parameters=[], CommandType='Text', CommandTimeout='30']
CREATE TABLE "Todo" (
"ID" INTEGER NOT NULL CONSTRAINT "PK_Todo" PRIMARY KEY AUTOINCREMENT,
"Description" TEXT NULL,
"CreatedDate" TEXT NOT NULL
);
Failed executing DbCommand (2ms) [Parameters=[], CommandType='Text', CommandTimeout='30']
CREATE TABLE "Todo" (
"ID" INTEGER NOT NULL CONSTRAINT "PK_Todo" PRIMARY KEY AUTOINCREMENT,
"Description" TEXT NULL,
"CreatedDate" TEXT NOT NULL
);
Microsoft.Data.Sqlite.SqliteException (0x80004005): SQLite Error 1: 'table "Todo" already exists'.
at Microsoft.Data.Sqlite.SqliteException.ThrowExceptionForRC(Int32 rc, sqlite3 db)
at Microsoft.Data.Sqlite.SqliteCommand.PrepareAndEnumerateStatements(Stopwatch timer)+MoveNext()
at Microsoft.Data.Sqlite.SqliteCommand.GetStatements(Stopwatch timer)+MoveNext()
at Microsoft.Data.Sqlite.SqliteDataReader.NextResult()
at Microsoft.Data.Sqlite.SqliteCommand.ExecuteReader(CommandBehavior behavior)
at Microsoft.Data.Sqlite.SqliteCommand.ExecuteReader()
at Microsoft.Data.Sqlite.SqliteCommand.ExecuteNonQuery()
at Microsoft.EntityFrameworkCore.Storage.RelationalCommand.ExecuteNonQuery(RelationalCommandParameterObject parameterObject)
at Microsoft.EntityFrameworkCore.Migrations.MigrationCommand.ExecuteNonQuery(IRelationalConnection connection, IReadOnlyDictionary2 parameterValues)    at Microsoft.EntityFrameworkCore.Migrations.Internal.MigrationCommandExecutor.ExecuteNonQuery(IEnumerable1 migrationCommands, IRelationalConnection connection)
at Microsoft.EntityFrameworkCore.Migrations.Internal.Migrator.Migrate(String targetMigration)
at Microsoft.EntityFrameworkCore.Design.Internal.MigrationsOperations.UpdateDatabase(String targetMigration, String contextType)
at Microsoft.EntityFrameworkCore.Design.OperationExecutor.UpdateDatabaseImpl(String targetMigration, String contextType)
at Microsoft.EntityFrameworkCore.Design.OperationExecutor.UpdateDatabase.<>c__DisplayClass0_0.<.ctor>b__0()
at Microsoft.EntityFrameworkCore.Design.OperationExecutor.OperationBase.Execute(Action action)
SQLite Error 1: 'table "Todo" already exists'.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 00961883-36eb-f736-b906-73d4c35e69b0
Version Independent ID: 3a2fd493-9682-eedf-fad1-571b9391cd46
Content: Tutorial: ASP.NET Core with SQL Database - Azure App Service
Content Source: articles/app-service/app-service-web-tutorial-dotnetcore-sqldb.md
Service: app-service
GitHub Login: @cephalin
Microsoft Alias: cephalin

@tonytaowang Thanks for the feedback! We are currently investigating and will update you shortly.

I ran into the same problem.
'cephalin-core' should be definitely be replaced with '' in the connection string generation.
The knowledge level of someone running through these tutorials shouldn't have to track down why this isn't working themselves.

Having the same issue.
Is there a workaround to move to next step

Change 'cephalin-core' to your server name.

Yes, tried that. No change in the error message. Do I need to manually update the appsettings.json with Azure SQL DB connection string?

Hi Guys,
Im Pretty new to this but i cant get past the rm Migrations -r
every time i run in the VS for mac terminal i get
rm: Migrations: is a directory
rm: -r: No such file or directory
any ideas?
Delete old migrations
rm Migrations -r
Recreate migrations
dotnet ef migrations add InitialCreate
Set connection string to production database
PowerShell
$env:ConnectionStrings:MyDbConnection=""
CMD (no quotes)
set ConnectionStrings:MyDbConnection=
Bash (no quotes)
export ConnectionStrings__MyDbConnection=
Run migrations
dotnet ef database update

Adding the doc author as I'm having issues as well but it's not clear what is causing the issue.

@TekExpo @WikkidEdd @tonytaowang your migration should be ran against the  you created in az sql server create --name <server-name> --resource-group myResourceGroup --admin-user <db-username> --admin-password <db-password>.
The output you get from az sql db show-connection-string --client ado.net --server <server-name> --name coreDB will replace MyDbConnection in your appsettings.json. Because of services.AddDbContext<MyDatabaseContext>(options => options.UseSqlServer(Configuration.GetConnectionString("MyDbConnection")));, dotnet ef migrations will execute against MyDatabaseContext using MyDbConnection as the connection string. Notice that UseSqlite was replaced with UseSqlServer because an Azure Sql Server is what created using the CLI, which is likely where you issues are.
At this point, git status should return two modified files, Startup.cs and appsettings.json. The repo you cloned already contains migrations so we want to remove the folder to account for any API changes made to the ef global tool. Run dotnet ef migrations add InitialCreate to create the migrations folder which contains the code for create the Todo table followed by dotnet ef migrations update to apply that migration against the .coreDb that we created and got the connection string for earlier. Note that show-connection-string doesn't include the  or  as part of the output for security purposes so you'll need those values with what you used in the az sql server create command.
Hope this helps.

In addition for you @tonytaowang, Sqlite is a file based database system, so the az sql commands won't apply. Just use
services.AddDbContext<MyDatabaseContext>(options =>
        options.UseSqlite(Configuration.GetConnectionString("MyDbConnection")));

and set "MyDbConnection": "Data Source=localdatabase.db" in your appsettings.json file and you should be set. One caveat, since Sqlite is file based, when you make changes you will have to apply those migrations at runtime.

Sorry for the delay. I've replaced the hardcoded value with a parameter. The update should be published within a few hours. #please-close

@cephalin this change hasn't resolved the issue. Despite running 'export ConnectionStrings__MyDbConnection=' (with the  placeholder replaced with the actual connection string from the db), it never updates the connection string in App Settings. As a result, when I run 'dotnet ef database update' it tries to update the local database and not the database in Azure.

Hi Guys,
Im Pretty new to this but i cant get past the rm Migrations -r
every time i run in the VS for mac terminal i get
rm: Migrations: is a directory
rm: -r: No such file or directory
any ideas?
Delete old migrations
rm Migrations -r
Recreate migrations
dotnet ef migrations add InitialCreate
Set connection string to production database
PowerShell
$env:ConnectionStrings:MyDbConnection=""
CMD (no quotes)
set ConnectionStrings:MyDbConnection=
Bash (no quotes)
export ConnectionStrings__MyDbConnection=
Run migrations
dotnet ef database update

Change the order in the Delete old migration step:
rm -r Migrations
(was "rm Migrations -r")
The -r is used when you're deleting (rm) a folder directory instead of a single file. The -r stands for recursive as in it will apply rm recursively to other files within Migrations


Cyclonus network policy e2e fail

Expected Behavior
Actual Behavior
The following e2e test cases fail:
2: should support a 'default-deny-all' policy
13: should stop enforcing policies after they are deleted

Steps to Reproduce the Problem

Additional Info

Kubernetes version:
Output of kubectl version:
(paste your output here)

kube-ovn version:

v1.8/v1.10

Not observed in master/v1.9.

operation-system/kernel version:
Output of awk -F '=' '/PRETTY_NAME/ { print $2 }' /etc/os-release:
Output of uname -r:
(paste your output here)

2: should support a 'default-deny-all' policy
13: should stop enforcing policies after they are deleted
出错是一个问题
怀疑是脚本本身的问题。
规则如下

很明显应该是x namespace的pod 访问别的pod和被访问不通。
但脚本预期结果是X namespace的pod 访问别的pod和被访问不通。

重新跑测试没问题。

Test case 12 timed out:
starting test case #12
time="2023-01-28T03:16:18Z" level=info msg="cluster state reset"
time="2023-01-28T03:16:21Z" level=info msg="cluster state verified"
time="2023-01-28T03:16:21Z" level=info msg="step 1: waiting 5 seconds for perturbation to take effect"
time="2023-01-28T03:16:26Z" level=info msg="running probe &{AllAvailable:true PortProtocol:<nil> Mode:service-name}"
time="2023-01-28T03:16:26Z" level=info msg="running kube probe on try 1"
time="2023-01-28T03:17:45Z" level=info msg="running kube probe on try 2"


Removing references to now deprecated AKS-Engine

Removing references to now deprecated AKS-Engine, as asked by PG.

@bwren
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team


changing default values in template to be valid. These aren't ever us…

…ed as they are set in the parameters file but it is a cleanliness thing/I had a parameters file that didn't have that parameter and it caused a failure

This change is

correct I will regen them

@acs-bot test this please


Multiple Flex Microforms

Is it possible to generate multiple Flex microforms on a single page?  I have searched and searched through the documentation and have yet to find a definitive answer to this.  Everything I've seen is the assumption is only one credit card number needs to be tokenized per form.

This is supported in version 0.4 (specifically the 0.4.4 release). Please specify the Microform clientside library as follows to benefit from the latest patch releases:
https://flex.cybersource.com/cybersource/assets/microform/
0.4/flex-microform.min.js


Jest 23 and tests

Gonna see if jest tests work now: https://github.com/facebook/create-react-app/issues/2294
Upgrade to jest 23
Convert mocha tests to jest via https://github.com/facebook/create-react-app/pull/2316
Changed CSS test because of a JSDOM parsing issue (it couldn't handle the entire bootstrap css)
integration config was added because after ejecting jest would have its own config in package.json and I need to override it via --config.
tranformIgnorePatterns change is due to https://github.com/facebook/jest/issues/6385
Note: https://github.com/facebook/jest/pull/6523
 '[/\\\\\\\\]node_modules[/\\\\\\\\].+\\.(js|jsx|mjs)$'.replace(/(\/|(.)?\\(?![[\]{}()*+?.^$|\\]))/g, (_match, p1, p2) => (p2 && p2 !== '\\' ? p2 + '\\\\' : '\\\\')) === '[/\\\\]node_modules[/\\\\].+\\.(js|jsx|mjs)$'.replace(/(\/|\\(?!\.))/g, '\\\\');
blocked by https://github.com/facebook/jest/issues/6546

I would love to see this PR merged.

Can you please bring this up to date? I want to merge it before v2 releases.

Sounds good, will give it another shot!

Nice. Thanks.


Very important DSiWare Downgrade note for emu/redNAND users

If you are performing the DSiWare downgrade using an emu/redNAND on 3DS number 1, after buying a legitimate copy of either Fieldrunners or Legends of Exidia via the eShop, you must attain a copy of the same game on your sysNAND (it can be pirated or legitimate) or else your game will boot directly to the "an error has occurred" screen on emu/redNAND.
Also, for injecting the hacked save, you can use God/SafeMode9 because you can specifically select "emuNAND TWL FIRM" while FBI does not have this option.

This isn't that important.
You don't need to launch the game, just install the save and it will transfer just fine.
The guide uses FBI, which (if launched from emunand/rednand) will look in emunand twl.


Rust conditional breakpoints: usize is a string?

 For example:
#[derive(Clone, Copy, Debug, Eq, PartialEq)]
struct Foo {
    n: usize,
}

impl Foo {
    fn bar(&self) {
        // Break here, condition: `self.n > 1`
        println!("Bar called on foo: {:?}", self);
    }
}

The debugger always breaks and prints:
'>' not supported between instances of 'str' and 'int'

However, if I change the condition from self.n > 1 to int(self.n) > 1, it works as expected.
launch.json (I am using configuraton #1)
{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "type": "lldb",
            "request": "launch",
            "name": "Debug executable 'lldb_test'",
            "cargo": {
                "args": [
                    "build",
                    "--bin=lldb_test",
                    "--package=lldb_test"
                ],
                "filter": {
                    "name": "lldb_test",
                    "kind": "bin"
                }
            },
            "args": [],
            "cwd": "${workspaceFolder}"
        },
        {
            "type": "lldb",
            "request": "launch",
            "name": "Debug unit tests in executable 'lldb_test'",
            "cargo": {
                "args": [
                    "test",
                    "--no-run",
                    "--bin=lldb_test",
                    "--package=lldb_test"
                ],
                "filter": {
                    "name": "lldb_test",
                    "kind": "bin"
                }
            },
            "args": [],
            "cwd": "${workspaceFolder}"
        }
    ]
}

Debug log
Running `cargo build --bin=lldb_test --package=lldb_test --message-format=json`...
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
Raw artifacts:
{
  fileName: '/Users/jacobgreenfield/Git/lldb_test/target/debug/lldb_test',
  name: 'lldb_test',
  kind: 'bin'
}
Filtered artifacts:
{
  fileName: '/Users/jacobgreenfield/Git/lldb_test/target/debug/lldb_test',
  name: 'lldb_test',
  kind: 'bin'
}
configuration: {
  type: 'lldb',
  request: 'launch',
  name: "Debug executable 'lldb_test'",
  args: [],
  cwd: '${workspaceFolder}',
  relativePathBase: '/Users/jacobgreenfield/Git/lldb_test',
  program: '/Users/jacobgreenfield/Git/lldb_test/target/debug/lldb_test',
  sourceLanguages: [ 'rust' ]
}
liblldb: /Users/jacobgreenfield/.vscode/extensions/vadimcn.vscode-lldb-1.4.5/lldb/lib/liblldb.dylib
libpython: /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/Python
environment: {}
params: { sourceLanguages: [ 'rust' ] }
Listening on port 51866
[2020-01-19T17:38:01Z DEBUG codelldb] New debug session
INFO(Python) 12:38:01 rust: Initializing, module name=rust
DEBUG(Python) 12:38:01 rust: attaching summary get_tuple_summary to "^\(.*\)$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching synthetic StrSliceSynthProvider to "&str", is_regex=False
DEBUG(Python) 12:38:01 rust: attaching summary _get_synth_summary_StrSliceSynthProvider to "&str", is_regex=False
DEBUG(Python) 12:38:01 rust: attaching synthetic StrSliceSynthProvider to "str*", is_regex=False
DEBUG(Python) 12:38:01 rust: attaching summary _get_synth_summary_StrSliceSynthProvider to "str*", is_regex=False
DEBUG(Python) 12:38:01 rust: attaching synthetic StdStringSynthProvider to "collections::string::String", is_regex=False
DEBUG(Python) 12:38:01 rust: attaching summary _get_synth_summary_StdStringSynthProvider to "collections::string::String", is_regex=False
DEBUG(Python) 12:38:01 rust: attaching synthetic StdStringSynthProvider to "alloc::string::String", is_regex=False
DEBUG(Python) 12:38:01 rust: attaching summary _get_synth_summary_StdStringSynthProvider to "alloc::string::String", is_regex=False
DEBUG(Python) 12:38:01 rust: attaching synthetic StdVectorSynthProvider to "^collections::vec::Vec<.+>$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching summary _get_synth_summary_StdVectorSynthProvider to "^collections::vec::Vec<.+>$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching synthetic StdVectorSynthProvider to "^alloc::vec::Vec<.+>$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching summary _get_synth_summary_StdVectorSynthProvider to "^alloc::vec::Vec<.+>$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching synthetic SliceSynthProvider to "^&(mut\s*)?\[.*\]$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching summary _get_synth_summary_SliceSynthProvider to "^&(mut\s*)?\[.*\]$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching synthetic SliceSynthProvider to "^slice<.+>.*$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching summary _get_synth_summary_SliceSynthProvider to "^slice<.+>.*$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching synthetic StdCStringSynthProvider to "std::ffi::c_str::CString", is_regex=False
DEBUG(Python) 12:38:01 rust: attaching summary _get_synth_summary_StdCStringSynthProvider to "std::ffi::c_str::CString", is_regex=False
DEBUG(Python) 12:38:01 rust: attaching synthetic StdCStrSynthProvider to "std::ffi::c_str::CStr", is_regex=False
DEBUG(Python) 12:38:01 rust: attaching summary _get_synth_summary_StdCStrSynthProvider to "std::ffi::c_str::CStr", is_regex=False
DEBUG(Python) 12:38:01 rust: attaching synthetic StdOsStringSynthProvider to "std::ffi::os_str::OsString", is_regex=False
DEBUG(Python) 12:38:01 rust: attaching summary _get_synth_summary_StdOsStringSynthProvider to "std::ffi::os_str::OsString", is_regex=False
DEBUG(Python) 12:38:01 rust: attaching synthetic StdOsStrSynthProvider to "std::ffi::os_str::OsStr", is_regex=False
DEBUG(Python) 12:38:01 rust: attaching summary _get_synth_summary_StdOsStrSynthProvider to "std::ffi::os_str::OsStr", is_regex=False
DEBUG(Python) 12:38:01 rust: attaching synthetic StdPathBufSynthProvider to "std::path::PathBuf", is_regex=False
DEBUG(Python) 12:38:01 rust: attaching summary _get_synth_summary_StdPathBufSynthProvider to "std::path::PathBuf", is_regex=False
DEBUG(Python) 12:38:01 rust: attaching synthetic StdPathSynthProvider to "std::path::Path", is_regex=False
DEBUG(Python) 12:38:01 rust: attaching summary _get_synth_summary_StdPathSynthProvider to "std::path::Path", is_regex=False
DEBUG(Python) 12:38:01 rust: attaching synthetic StdRcSynthProvider to "^alloc::rc::Rc<.+>$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching summary _get_synth_summary_StdRcSynthProvider to "^alloc::rc::Rc<.+>$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching synthetic StdRcSynthProvider to "^alloc::rc::Weak<.+>$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching summary _get_synth_summary_StdRcSynthProvider to "^alloc::rc::Weak<.+>$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching synthetic StdArcSynthProvider to "^alloc::(sync|arc)::Arc<.+>$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching summary _get_synth_summary_StdArcSynthProvider to "^alloc::(sync|arc)::Arc<.+>$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching synthetic StdArcSynthProvider to "^alloc::(sync|arc)::Weak<.+>$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching summary _get_synth_summary_StdArcSynthProvider to "^alloc::(sync|arc)::Weak<.+>$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching synthetic StdMutexSynthProvider to "^std::sync::mutex::Mutex<.+>$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching summary _get_synth_summary_StdMutexSynthProvider to "^std::sync::mutex::Mutex<.+>$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching synthetic StdCellSynthProvider to "^core::cell::Cell<.+>$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching summary _get_synth_summary_StdCellSynthProvider to "^core::cell::Cell<.+>$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching synthetic StdRefCellSynthProvider to "^core::cell::RefCell<.+>$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching summary _get_synth_summary_StdRefCellSynthProvider to "^core::cell::RefCell<.+>$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching synthetic StdRefCellBorrowSynthProvider to "^core::cell::Ref<.+>$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching summary _get_synth_summary_StdRefCellBorrowSynthProvider to "^core::cell::Ref<.+>$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching synthetic StdRefCellBorrowSynthProvider to "^core::cell::RefMut<.+>$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching summary _get_synth_summary_StdRefCellBorrowSynthProvider to "^core::cell::RefMut<.+>$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching synthetic StdHashMapSynthProvider to "^std::collections::hash::map::HashMap<.+>$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching summary _get_synth_summary_StdHashMapSynthProvider to "^std::collections::hash::map::HashMap<.+>$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching synthetic StdHashSetSynthProvider to "^std::collections::hash::set::HashSet<.+>$", is_regex=True
DEBUG(Python) 12:38:01 rust: attaching summary _get_synth_summary_StdHashSetSynthProvider to "^std::collections::hash::set::HashSet<.+>$", is_regex=True
[2020-01-19T17:38:01Z DEBUG codelldb::wire_protocol] --> {"command":"initialize","arguments":{"clientID":"vscode","clientName":"Visual Studio Code","adapterID":"lldb","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true,"locale":"en-us"},"type":"request","seq":1}
[2020-01-19T17:38:01Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":1,"success":true,"command":"initialize","body":{"exceptionBreakpointFilters":[{"default":true,"filter":"rust_panic","label":"Rust: on panic"}],"supportTerminateDebuggee":true,"supportsCompletionsRequest":true,"supportsConditionalBreakpoints":true,"supportsConfigurationDoneRequest":true,"supportsDataBreakpoints":true,"supportsDelayedStackTraceLoading":true,"supportsEvaluateForHovers":true,"supportsFunctionBreakpoints":true,"supportsGotoTargetsRequest":true,"supportsHitConditionalBreakpoints":true,"supportsLogPoints":true,"supportsRestartFrame":true,"supportsSetVariable":true}}
[2020-01-19T17:38:01Z DEBUG codelldb::wire_protocol] --> {"command":"launch","arguments":{"type":"lldb","request":"launch","name":"Debug executable 'lldb_test'","args":[],"cwd":"/Users/jacobgreenfield/Git/lldb_test","relativePathBase":"/Users/jacobgreenfield/Git/lldb_test","program":"/Users/jacobgreenfield/Git/lldb_test/target/debug/lldb_test","sourceLanguages":["rust"],"_adapterSettings":{"displayFormat":"auto","showDisassembly":"auto","dereferencePointers":true,"suppressMissingSourceFiles":true,"evaluationTimeout":5,"consoleMode":"commands","sourceLanguages":null},"__sessionId":"d55e24e3-aabe-49fd-b2af-ec518ac04b14"},"type":"request","seq":2}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":1,"event":"initialized"}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] --> {"command":"setBreakpoints","arguments":{"source":{"name":"main.rs","path":"/Users/jacobgreenfield/Git/lldb_test/src/main.rs"},"lines":[8],"breakpoints":[{"line":8,"condition":"self.n > 1"}],"sourceModified":false},"type":"request","seq":3}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":3,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"id":1,"line":8,"message":"Locations: 2","source":{"name":"main.rs","path":"/Users/jacobgreenfield/Git/lldb_test/src/main.rs"},"verified":true}]}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] --> {"command":"setFunctionBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":4}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":4,"success":true,"command":"setFunctionBreakpoints","body":{"breakpoints":[]}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] --> {"command":"setDataBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":5}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":5,"success":true,"command":"setDataBreakpoints","body":{"breakpoints":[]}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] --> {"command":"setExceptionBreakpoints","arguments":{"filters":["rust_panic"]},"type":"request","seq":6}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":6,"success":true,"command":"setExceptionBreakpoints"}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] --> {"command":"configurationDone","type":"request","seq":7}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"request","seq":2,"command":"runInTerminal","arguments":{"args":["/Users/jacobgreenfield/.vscode/extensions/vadimcn.vscode-lldb-1.4.5/adapter2/codelldb","terminal-agent","--port=51868"],"cwd":"","kind":"integrated","title":"Debug executable 'lldb_test'"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] --> {"type":"response","seq":8,"command":"runInTerminal","request_seq":2,"success":true,"body":{"shellProcessId":22628}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":3,"event":"output","body":{"output":"Launching: /Users/jacobgreenfield/Git/lldb_test/target/debug/lldb_test\n"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":2,"success":true,"command":"launch"}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":7,"success":true,"command":"configurationDone"}
[2020-01-19T17:38:02Z DEBUG codelldb::debug_session] Debug event: 0x7fe3c7e36028 Event: broadcaster = 0x7fe3c981f618 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2020-01-19T17:38:02Z DEBUG codelldb::debug_session] Debug event: 0x7fe3c7e2a908 Event: broadcaster = 0x7fe3c981f618 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2020-01-19T17:38:02Z DEBUG codelldb::debug_session] Debug event: 0x7fe3c7f9ace8 Event: broadcaster = 0x7fe3c981f618 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2020-01-19T17:38:02Z DEBUG codelldb::debug_session] Debug event: 0x7fe3c7c9e4a8 Event: broadcaster = 0x7fe3c981f618 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2020-01-19T17:38:02Z DEBUG codelldb::debug_session] Debug event: 0x7fe3c9017bc8 Event: broadcaster = 0x7fe3c981f618 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2020-01-19T17:38:02Z DEBUG codelldb::debug_session] Debug event: 0x7fe3c9022928 Event: broadcaster = 0x7fe3c981f618 (lldb.target), type = 0x00000002 (modules-loaded), data = {dyld, lldb_test}
[2020-01-19T17:38:02Z DEBUG codelldb::debug_session] Debug event: 0x7fe3c9025660 Event: broadcaster = 0x7fe3c8a91050 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x7fe3c8a91018 (pid = 22825), state = running}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":4,"event":"module","body":{"module":{"addressRange":"100045000","id":"100045000","name":"dyld","path":"/usr/lib/dyld","symbolFilePath":"/usr/lib/dyld","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":5,"event":"module","body":{"module":{"addressRange":"100000000","id":"100000000","name":"lldb_test","path":"/Users/jacobgreenfield/Git/lldb_test/target/debug/lldb_test","symbolFilePath":"/Users/jacobgreenfield/Git/lldb_test/target/debug/deps/lldb_test-062cb768942dc771.dSYM/Contents/Resources/DWARF/lldb_test-062cb768942dc771","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":6,"event":"continued","body":{"allThreadsContinued":true,"threadId":0}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] --> {"command":"threads","type":"request","seq":9}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":9,"success":true,"command":"threads","body":{"threads":[{"id":52509052,"name":"1: tid=52509052"}]}}
[2020-01-19T17:38:02Z DEBUG codelldb::debug_session] Debug event: 0x7fe3c7e9b368 Event: broadcaster = 0x7fe3c981f618 (lldb.target), type = 0x00000002 (modules-loaded), data = {libSystem.B.dylib, libresolv.9.dylib, libcache.dylib, libcommonCrypto.dylib, libcompiler_rt.dylib, libcopyfile.dylib, libcorecrypto.dylib, libdispatch.dylib, libdyld.dylib, libkeymgr.dylib, liblaunch.dylib, libmacho.dylib, libquarantine.dylib, libremovefile.dylib, libsystem_asl.dylib, libsystem_blocks.dylib, libsystem_c.dylib, libsystem_configuration.dylib, libsystem_coreservices.dylib, libsystem_darwin.dylib, libsystem_dnssd.dylib, libsystem_info.dylib, libsystem_m.dylib, libsystem_malloc.dylib, libsystem_networkextension.dylib, libsystem_notify.dylib, libsystem_sandbox.dylib, libsystem_secinit.dylib, libsystem_kernel.dylib, libsystem_platform.dylib, libsystem_pthread.dylib, libsystem_symptoms.dylib, libsystem_trace.dylib, libunwind.dylib, libxpc.dylib, libobjc.A.dylib, libc++abi.dylib, libc++.1.dylib}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":7,"event":"module","body":{"module":{"addressRange":"7FFF7553E000","id":"7FFF7553E000","name":"libSystem.B.dylib","path":"/usr/lib/libSystem.B.dylib","symbolFilePath":"/usr/lib/libSystem.B.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":8,"event":"module","body":{"module":{"addressRange":"7FFF77663000","id":"7FFF77663000","name":"libresolv.9.dylib","path":"/usr/lib/libresolv.9.dylib","symbolFilePath":"/usr/lib/libresolv.9.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":9,"event":"module","body":{"module":{"addressRange":"7FFF783DD000","id":"7FFF783DD000","name":"libcache.dylib","path":"/usr/lib/system/libcache.dylib","symbolFilePath":"/usr/lib/system/libcache.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":10,"event":"module","body":{"module":{"addressRange":"7FFF783E2000","id":"7FFF783E2000","name":"libcommonCrypto.dylib","path":"/usr/lib/system/libcommonCrypto.dylib","symbolFilePath":"/usr/lib/system/libcommonCrypto.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":11,"event":"module","body":{"module":{"addressRange":"7FFF783ED000","id":"7FFF783ED000","name":"libcompiler_rt.dylib","path":"/usr/lib/system/libcompiler_rt.dylib","symbolFilePath":"/usr/lib/system/libcompiler_rt.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":12,"event":"module","body":{"module":{"addressRange":"7FFF783F5000","id":"7FFF783F5000","name":"libcopyfile.dylib","path":"/usr/lib/system/libcopyfile.dylib","symbolFilePath":"/usr/lib/system/libcopyfile.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":13,"event":"module","body":{"module":{"addressRange":"7FFF783FF000","id":"7FFF783FF000","name":"libcorecrypto.dylib","path":"/usr/lib/system/libcorecrypto.dylib","symbolFilePath":"/usr/lib/system/libcorecrypto.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":14,"event":"module","body":{"module":{"addressRange":"7FFF7850A000","id":"7FFF7850A000","name":"libdispatch.dylib","path":"/usr/lib/system/libdispatch.dylib","symbolFilePath":"/usr/lib/system/libdispatch.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":15,"event":"module","body":{"module":{"addressRange":"7FFF78544000","id":"7FFF78544000","name":"libdyld.dylib","path":"/usr/lib/system/libdyld.dylib","symbolFilePath":"/usr/lib/system/libdyld.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":16,"event":"module","body":{"module":{"addressRange":"7FFF78571000","id":"7FFF78571000","name":"libkeymgr.dylib","path":"/usr/lib/system/libkeymgr.dylib","symbolFilePath":"/usr/lib/system/libkeymgr.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":17,"event":"module","body":{"module":{"addressRange":"7FFF7857F000","id":"7FFF7857F000","name":"liblaunch.dylib","path":"/usr/lib/system/liblaunch.dylib","symbolFilePath":"/usr/lib/system/liblaunch.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":18,"event":"module","body":{"module":{"addressRange":"7FFF78580000","id":"7FFF78580000","name":"libmacho.dylib","path":"/usr/lib/system/libmacho.dylib","symbolFilePath":"/usr/lib/system/libmacho.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":19,"event":"module","body":{"module":{"addressRange":"7FFF78586000","id":"7FFF78586000","name":"libquarantine.dylib","path":"/usr/lib/system/libquarantine.dylib","symbolFilePath":"/usr/lib/system/libquarantine.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":20,"event":"module","body":{"module":{"addressRange":"7FFF78589000","id":"7FFF78589000","name":"libremovefile.dylib","path":"/usr/lib/system/libremovefile.dylib","symbolFilePath":"/usr/lib/system/libremovefile.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":21,"event":"module","body":{"module":{"addressRange":"7FFF7858B000","id":"7FFF7858B000","name":"libsystem_asl.dylib","path":"/usr/lib/system/libsystem_asl.dylib","symbolFilePath":"/usr/lib/system/libsystem_asl.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":22,"event":"module","body":{"module":{"addressRange":"7FFF785A3000","id":"7FFF785A3000","name":"libsystem_blocks.dylib","path":"/usr/lib/system/libsystem_blocks.dylib","symbolFilePath":"/usr/lib/system/libsystem_blocks.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":23,"event":"module","body":{"module":{"addressRange":"7FFF785A4000","id":"7FFF785A4000","name":"libsystem_c.dylib","path":"/usr/lib/system/libsystem_c.dylib","symbolFilePath":"/usr/lib/system/libsystem_c.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":24,"event":"module","body":{"module":{"addressRange":"7FFF7862C000","id":"7FFF7862C000","name":"libsystem_configuration.dylib","path":"/usr/lib/system/libsystem_configuration.dylib","symbolFilePath":"/usr/lib/system/libsystem_configuration.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":25,"event":"module","body":{"module":{"addressRange":"7FFF78630000","id":"7FFF78630000","name":"libsystem_coreservices.dylib","path":"/usr/lib/system/libsystem_coreservices.dylib","symbolFilePath":"/usr/lib/system/libsystem_coreservices.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":26,"event":"module","body":{"module":{"addressRange":"7FFF78634000","id":"7FFF78634000","name":"libsystem_darwin.dylib","path":"/usr/lib/system/libsystem_darwin.dylib","symbolFilePath":"/usr/lib/system/libsystem_darwin.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":27,"event":"module","body":{"module":{"addressRange":"7FFF7863B000","id":"7FFF7863B000","name":"libsystem_dnssd.dylib","path":"/usr/lib/system/libsystem_dnssd.dylib","symbolFilePath":"/usr/lib/system/libsystem_dnssd.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":28,"event":"module","body":{"module":{"addressRange":"7FFF78642000","id":"7FFF78642000","name":"libsystem_info.dylib","path":"/usr/lib/system/libsystem_info.dylib","symbolFilePath":"/usr/lib/system/libsystem_info.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":29,"event":"module","body":{"module":{"addressRange":"7FFF786B7000","id":"7FFF786B7000","name":"libsystem_m.dylib","path":"/usr/lib/system/libsystem_m.dylib","symbolFilePath":"/usr/lib/system/libsystem_m.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":30,"event":"module","body":{"module":{"addressRange":"7FFF78703000","id":"7FFF78703000","name":"libsystem_malloc.dylib","path":"/usr/lib/system/libsystem_malloc.dylib","symbolFilePath":"/usr/lib/system/libsystem_malloc.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":31,"event":"module","body":{"module":{"addressRange":"7FFF7872E000","id":"7FFF7872E000","name":"libsystem_networkextension.dylib","path":"/usr/lib/system/libsystem_networkextension.dylib","symbolFilePath":"/usr/lib/system/libsystem_networkextension.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":32,"event":"module","body":{"module":{"addressRange":"7FFF78739000","id":"7FFF78739000","name":"libsystem_notify.dylib","path":"/usr/lib/system/libsystem_notify.dylib","symbolFilePath":"/usr/lib/system/libsystem_notify.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":33,"event":"module","body":{"module":{"addressRange":"7FFF78756000","id":"7FFF78756000","name":"libsystem_sandbox.dylib","path":"/usr/lib/system/libsystem_sandbox.dylib","symbolFilePath":"/usr/lib/system/libsystem_sandbox.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":34,"event":"module","body":{"module":{"addressRange":"7FFF7875A000","id":"7FFF7875A000","name":"libsystem_secinit.dylib","path":"/usr/lib/system/libsystem_secinit.dylib","symbolFilePath":"/usr/lib/system/libsystem_secinit.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":35,"event":"module","body":{"module":{"addressRange":"7FFF7868E000","id":"7FFF7868E000","name":"libsystem_kernel.dylib","path":"/usr/lib/system/libsystem_kernel.dylib","symbolFilePath":"/usr/lib/system/libsystem_kernel.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":36,"event":"module","body":{"module":{"addressRange":"7FFF78741000","id":"7FFF78741000","name":"libsystem_platform.dylib","path":"/usr/lib/system/libsystem_platform.dylib","symbolFilePath":"/usr/lib/system/libsystem_platform.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":37,"event":"module","body":{"module":{"addressRange":"7FFF7874B000","id":"7FFF7874B000","name":"libsystem_pthread.dylib","path":"/usr/lib/system/libsystem_pthread.dylib","symbolFilePath":"/usr/lib/system/libsystem_pthread.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":38,"event":"module","body":{"module":{"addressRange":"7FFF7875D000","id":"7FFF7875D000","name":"libsystem_symptoms.dylib","path":"/usr/lib/system/libsystem_symptoms.dylib","symbolFilePath":"/usr/lib/system/libsystem_symptoms.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":39,"event":"module","body":{"module":{"addressRange":"7FFF78765000","id":"7FFF78765000","name":"libsystem_trace.dylib","path":"/usr/lib/system/libsystem_trace.dylib","symbolFilePath":"/usr/lib/system/libsystem_trace.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":40,"event":"module","body":{"module":{"addressRange":"7FFF7877C000","id":"7FFF7877C000","name":"libunwind.dylib","path":"/usr/lib/system/libunwind.dylib","symbolFilePath":"/usr/lib/system/libunwind.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":41,"event":"module","body":{"module":{"addressRange":"7FFF78782000","id":"7FFF78782000","name":"libxpc.dylib","path":"/usr/lib/system/libxpc.dylib","symbolFilePath":"/usr/lib/system/libxpc.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":42,"event":"module","body":{"module":{"addressRange":"7FFF76D77000","id":"7FFF76D77000","name":"libobjc.A.dylib","path":"/usr/lib/libobjc.A.dylib","symbolFilePath":"/usr/lib/libobjc.A.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":43,"event":"module","body":{"module":{"addressRange":"7FFF757D7000","id":"7FFF757D7000","name":"libc++abi.dylib","path":"/usr/lib/libc++abi.dylib","symbolFilePath":"/usr/lib/libc++abi.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":44,"event":"module","body":{"module":{"addressRange":"7FFF75783000","id":"7FFF75783000","name":"libc++.1.dylib","path":"/usr/lib/libc++.1.dylib","symbolFilePath":"/usr/lib/libc++.1.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-19T17:38:02Z DEBUG codelldb::debug_session] Callback for breakpoint location 1.1: where = lldb_test`bar + 12 at main.rs:8:8, address = 0x000000010000122c, resolved, hit count = 1
[2020-01-19T17:38:02Z DEBUG codelldb::debug_session] Debug event: 0x7fe3c9201bd0 Event: broadcaster = 0x7fe3c8a91050 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x7fe3c8a91018 (pid = 22825), state = stopped}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":45,"event":"output","body":{"category":"stderr","output":"'>' not supported between instances of 'str' and 'int'\n"}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":46,"event":"stopped","body":{"allThreadsStopped":true,"reason":"breakpoint","threadId":52509052}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] --> {"command":"threads","type":"request","seq":10}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":10,"success":true,"command":"threads","body":{"threads":[{"id":52509052,"name":"1: tid=52509052"}]}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] --> {"command":"stackTrace","arguments":{"threadId":52509052,"startFrame":0,"levels":1},"type":"request","seq":11}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":11,"success":true,"command":"stackTrace","body":{"stackFrames":[{"column":8,"id":1001,"line":8,"name":"bar","source":{"name":"main.rs","path":"/Users/jacobgreenfield/Git/lldb_test/src/main.rs"}}],"totalFrames":12}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] --> {"command":"scopes","arguments":{"frameId":1001},"type":"request","seq":12}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":12,"success":true,"command":"scopes","body":{"scopes":[{"expensive":false,"name":"Local","variablesReference":1002},{"expensive":false,"name":"Static","variablesReference":1003},{"expensive":false,"name":"Global","variablesReference":1004},{"expensive":false,"name":"Registers","variablesReference":1005}]}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] --> {"command":"variables","arguments":{"variablesReference":1002},"type":"request","seq":13}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":13,"success":true,"command":"variables","body":{"variables":[{"evaluateName":"self","name":"self","type":"&lldb_test::Foo","value":"{n:5}","variablesReference":1006}]}}
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] --> {"command":"stackTrace","arguments":{"threadId":52509052,"startFrame":1,"levels":19},"type":"request","seq":14}
[2020-01-19T17:38:02Z DEBUG codelldb::disassembly] lldb_test{{closure}}<()> + 18 at rt.rs:61:33 [2020-01-19T17:38:02Z DEBUG codelldb::disassembly] lldb_testdo_call<closure-0,i32> + 24 at panicking.rs:287:12
[2020-01-19T17:38:02Z DEBUG codelldb::disassembly] lldb_test__rust_maybe_catch_panic + 31 at lib.rs:86:1 [2020-01-19T17:38:02Z DEBUG codelldb::disassembly] lldb_testlang_start_internal + 542 [inlined] std::panicking::try + 51 at panic.rs:396
lldb_testlang_start_internal + 491 [inlined] std::panic::catch_unwind at rt.rs:47 lldb_testlang_start_internal + 491 at rt.rs:47
[2020-01-19T17:38:02Z DEBUG codelldb::disassembly] lldb_testlang_start<()> + 66 at rt.rs:61:4 [2020-01-19T17:38:02Z DEBUG codelldb::disassembly] lldb_testmain + 34
[2020-01-19T17:38:02Z DEBUG codelldb::disassembly] libdyld.dylib`start + 1
[2020-01-19T17:38:02Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":14,"success":true,"command":"stackTrace","body":{"stackFrames":[{"column":4,"id":1007,"line":15,"name":"main","source":{"name":"main.rs","path":"/Users/jacobgreenfield/Git/lldb_test/src/main.rs"}},{"column":0,"id":1008,"line":9,"name":"{{closure}}<()>","presentationHint":"subtle","source":{"name":"@std::rt::lang_start::$u7b$$u7b$closure$u7d$$u7d$::h57b76914c509959f","sourceReference":1000}},{"column":0,"id":1009,"line":12,"name":"std::rt::lang_start_internal::$u7b$$u7b$closure$u7d$$u7d$","presentationHint":"subtle","source":{"name":"@std::panicking::try::do_call::hd5a3af8d00c06681","sourceReference":1001}},{"column":0,"id":1010,"line":9,"name":"do_call<closure-0,i32>","presentationHint":"subtle","source":{"name":"@std::panicking::try::do_call::hd5a3af8d00c06681","sourceReference":1001}},{"column":0,"id":1011,"line":16,"name":"__rust_maybe_catch_panic","presentationHint":"subtle","source":{"name":"@__rust_maybe_catch_panic","sourceReference":1002}},{"column":0,"id":1012,"line":124,"name":"std::panicking::try","presentationHint":"subtle","source":{"name":"@std::rt::lang_start_internal::haa52aabac43378ff","sourceReference":1003}},{"column":0,"id":1013,"line":114,"name":"std::panic::catch_unwind","presentationHint":"subtle","source":{"name":"@std::rt::lang_start_internal::haa52aabac43378ff","sourceReference":1003}},{"column":0,"id":1014,"line":114,"name":"lang_start_internal","presentationHint":"subtle","source":{"name":"@std::rt::lang_start_internal::haa52aabac43378ff","sourceReference":1003}},{"column":0,"id":1015,"line":20,"name":"lang_start<()>","presentationHint":"subtle","source":{"name":"@std::rt::lang_start::h5f1bbb50c8e6982d","sourceReference":1004}},{"column":0,"id":1016,"line":12,"name":"main","presentationHint":"subtle","source":{"name":"@main","sourceReference":1005}},{"column":0,"id":1017,"line":4,"name":"start","presentationHint":"subtle","source":{"name":"@start","sourceReference":1006}}],"totalFrames":12}}

Can we close this now as we believe it to be fixed?

@gilescope  I usually give reporters a chance to confirm that the issue has indeed been fixed.

Sorry for the late response, this is working for me!


Error when use popup

vim or neovim?

[x] vim
[ ] neovim

Output of vim --version or nvim --version: 8.2
Output of :echo has("python"): 0
Output of :echo has("python3"): 1
Output of :echo &pythondll(only vim, not neovim):
Output of :echo &pythonthreedll(only vim, not neovim):
Output of :py print(sys.version): E319: Sorry, the command is not available in this version
Output of :py3 print(sys.version): 3.7.5 (default, Nov  1 2019, 02:16:32)
[Clang 11.0.0 (clang-1<IP_ADDRESS>)]
Output of :echo g:Lf_Debug_Cmd: E121: Undefined variable: g:Lf_Debug_Cmd
Output of :echo g:Lf_FilesFromCache: E121: Undefined variable: g:Lf_FilesFromCache
Operating system:

[ ] Linux
[x] Mac OS X
[ ] Windows
[ ] Etc.

Configurations related to LeaderF in vimrc:

Describe your question, feature request, or bug.
use :Leaderf file --popup  or let g:Lf_WindowPosition = 'popup'
Actual behaviour
show this error
Error detected while processing function leaderf#Any#start[4]..leaderf#LfPy:
line    1:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/a1/.vim/plugged/LeaderF/autoload/leaderf/python/leaderf/anyExpl.py", line
 780, in start
    the_args.start(arguments, *args, **kwargs)
  File "/Users/a1/.vim/plugged/LeaderF/autoload/leaderf/python/leaderf/anyExpl.py", line
 712, in _default_action
    manager.startExplorer(win_pos[2:], *args, **kwargs)
  File "/Users/a1/.vim/plugged/LeaderF/autoload/leaderf/python/leaderf/fileExpl.py", lin
e 729, in startExplorer
    super(FileExplManager, self).startExplorer(win_pos, *args, **kwargs)
  File "/Users/a1/.vim/plugged/LeaderF/autoload/leaderf/python/leaderf/manager.py", line
 1978, in startExplorer
    self._getInstance().enterBuffer(win_pos, not isinstance(content, list))
  File "/Users/a1/.vim/plugged/LeaderF/autoload/leaderf/python/leaderf/instance.py", lin
e 917, in enterBuffer
    self._createPopupWindow(clear)
  File "/Users/a1/.vim/plugged/LeaderF/autoload/leaderf/python/leaderf/instance.py", lin
e 485, in _createPopupWindow
    lfCmd("silent let winid = popup_create(%d, %s)" % (buf_number, str(options)))
vim.error: Vim(lcd):E344: Can't find directory "/usr/local/share/vim/vim82/File" in cdpa
th
Error detected while processing function leaderf#Any#start:
line    4:
E171: Missing :endif

thanks

Could you provide a minimum vimrc to reproduce it?

I think it's because this config autocmd bufenter * lcd %:p:h
when i use autocmd bufenter * silent! lcd %:p:h or remove it,  popup work

I'm not familiar with vim，maybe its my problem，i can fix it  by myself

vim's plugin can not protect itself from being conflict with other configurations. So I don't plan to fix it in LeaderF any more, your fix is just OK.

Very useful infomation. I guess quite a number of users setting auto change to buffer dir in their vimrc. Maybe mention this issue in help?


a11y: Explore possibly better fix for icons

Upstream discussion: https://github.com/adobe/aem-boilerplate/pull/280/files
Looking in Google Docs, there's no easy or obvious way I can see to add the alt text in for icon text, unlike for images where it can be in one of two Image Options places quite happily - the official Alt text > Description field, or the Alt text > Advanced options field.
There's also no obvious way for a developer/engineer to configure the alt text for a specific icon. So perhaps it's better left out?
Convention over configuration probably adds more trouble, it'd require a configuration convention like another yaml or json file (the repo currently takes both sides, e.g. fstab.yaml vs package.json) which could be subject to hot-spot problem and  so guarantee merge conflicts on larger projects...
Basically I don't think there's any easy and configurable answer here because who, where and how to configure it are not obvious to me at least.
So role: presentation makes the most sense for the built-in version, and perhaps some other mechanism for non-presentation roles will become more obvious.
Plus role:presention feels closer to SRP, i.e. probably the right direction.
Not sure why anyone would want to read my braindump, but if you did, thanks for reading.

Please always provide the GitHub issue(s) your PR is for, as well as test URLs where your change can be observed (before and after):
Fix #
Test URLs:

Before: https://main--aem-boilerplate--pzrq.hlx.page/
After: https://develop--aem-boilerplate--pzrq.hlx.page/

This takes me from 100 to 96, so more learning needed: https://dequeuniversity.com/rules/axe/4.7/link-name

🤔 So actually I've already found a naturally non-presentation case, as I have one new icon which is intended for navigation in addition to the batteries included search icon. Wow this is hard. I guess I'll stay with what I started with for now.


[AMD-AIE] Use emitOpError in consumer fusion pass and segregate the lit test

-- This commit uses proper pass failure instead of debug statements.
Signed-off-by: Abhishek Varma<EMAIL_ADDRESS>

Can you elaborate why we should fail if the input IR doesn't have the specific loop nest the pass is looking for. The subsequent passes, which may include this same pass but with a further lowered IR may be able co compile to success?

Can you elaborate why we should fail if the input IR doesn't have the specific loop nest the pass is looking for. The subsequent passes, which may include this same pass but with a further lowered IR may be able co compile to success?

Hi @nirvedhmeshram - the pass itself doesn't make any assumption on the loop nest structure and just tries to fetch the first scf.for* in the reverse order. I get your point though and now LLVM_DEBUG vs emitOpError's usage is similar to what we have today with iree-amdaie-fuse-fill-into-loop pass which should be acceptable now.

LGTM, may be update the PR title as now I think the addition from PR is that this is making two separate test files for scf.for and scf.for_all?

Well, that and couple of LLVM_DEBUG statements were changed to emitOpError, yes - I've changed the PR title to reflect the same.
@yzhang93 - since this is a follow-up patch can you please review this as well?


Compilation error on clean startup

Compilation error on clean startup
I want to try your awesome framework for the first time but got an error on the startup.
Tried with node versions 14, 16, 17
Screenshots

Desktop Enviroment:

OS: macOS Monterey
CPU: Apple M1 chip

Yes, this is related to mongodb latest version which introduced this ridiculous recursiveness to aid nested fields. Try using mongodb 4.2.x instead, let me know if this fixes for you. A long term solution is on the way, I am working with mongo team on this one.
Sent from my iPhone

On 15 Jan 2022, at 14:39, Burak @.***> wrote:

Reopened #158.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.

I've fixed the @bluelibs/x and also ensured mongo-bundle requires 4.2.2 as a version. If you go through the process again it should be seamless again, thank you for pointing it out.
I estimate a long-term fix in the next 1 month, I'm already following-up with them here: https://www.mongodb.com/community/forums/t/mongodb-node-js-driver-4-3-0-released/140479/2 and I've offered some potential solutions.

Yes, it worked with mongo:4.2 when i reinstall @bluelibs/x.  Thanks for the light speed help

No problem. Let me know how everything went, I care a lot about Developer Experience.


Moved some functions out of run_all_in_graph_and_eager_mode in attention_wrapper_test.py.

The indent seems to be quite weird in this file, are we using 4 space or 2 space?

I'm not sure I follow you, it's 4 spaces, what makes you think 2?
Also for the background, sorry, I should have been more explicit, see https://github.com/tensorflow/addons/issues/1328
We want to get rid of the decorator that traces test functions (run_all_in_graph_and_eager_mode).

The indent seems to be quite weird in this file, are we using 4 space or 2 space?
Also, I haven't follow the change history closely, but currently there is a nest structure of test classes in this file, which is bit anti-pattern. Is that expected?

I think in TensorFlow using 2 space, but here is with black, which is 4 space.


Provide option for evil-mode during generation

Hi @dylanfw.
I like this suggestion. However, i don't use evil and am not sure if just installing the package is enough without any configuration. It would be great if an evil-mode user could contribute his/her configs.

Hi. I'm new to emacs but very good user of vim.


TIMETZ docs

Fixes #5964.

Added TIMETZ to v20.1 docs (time.md and data-types.md).
Updated example output for TIME data type.

@otan for technical review.

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/5953094359ad20ea1461f011c93ef5e05c7db1e7/
Edited pages:

v19.2/timestamp.md
v20.1/data-types.md
v20.1/set-vars.md
v20.1/time.md
v20.1/timestamp.md

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/18237987a17bb343143d1a7eedcc6dde11f19c73/
Edited pages:

v19.2/timestamp.md
v20.1/data-types.md
v20.1/set-vars.md
v20.1/time.md
v20.1/timestamp.md


Support for multiple addresses per server

From @helje5:
https://github.com/swift-server/http/pull/81#issuecomment-342630664
An open question is, do we want to support multiple binds? I tend to say yes. This would modify the structure of the server a little.
(the other option is to use multiple servers if you want to listen on multiple addresses, but that would be kinda wasteful).

+1 for multiple binds


Too many levels of symlinks error when loading model in AWS Lambda function

Hi, I have been trying to containerize Speaker Recognition model in an AWS lambda function which has a read-only Linux file system with just '/tmp' folder available for write. Following issues #1001 and #1155, I have downloaded the model files and copied them into '/tmp' during build and loaded as below
diarizer = SpeakerRecognition.from_hparams(source='/tmp', savedir='/tmp', overrides={"pretrained_path": '/tmp'})
Getting a too many levels of symlinks error

Please let me know how I can fix it. Thanks

@Gastron, any idea?

Too many levels of symlinks results from some kind of broken, probably circular symlink. If you do the same thing on your own machine, do you get the same error. Also double check whether you're actually copying the model files and not just the symlinks (HuggingFace Hub downloads to its cache and SpeechBrain creates a symlink in savedir) during your build.

It could be that - and also, are you using the paths argument to Pretrainer? Perhaps you could simplify, name the checkpoint files appropriately in /tmp - maybe that is causing additional symlinks like for instance this label encoder file.
Other than that, if it works on the local side, but not on AWS Lambda, I suggest going over the loading process on the local side once more - perhaps it needs some other location (outside /tmp) after all? Or is there some other difference between the Lambda instance and your local? Can you replicate the environment where only /tmp is writeable?

Hello,
Any news with this issue please?
Thanks.
Adel

I noticed this issue before but the reason didn't occur to me until now: source and savedir cannot be the same, which likely causes a symlink into itself. We should add a check of some sort to prevent this, and reduce the use of symlinks in general (#2476).


[5.1] Block the queue when popping for jobs

Using the Redis BLPOP command the worker can wait until a job is poped (or pushed) in to the queue

Please update the mocking in the tests too. :)

Added a commit (ee80d46) but I'm not sure how to join it to the pull request, neither if it is correct...

Need more description as to advantages of doing it this way vs. other way, bugs this solves, etc. Is the Redis queue driver broken?

Redis queue is not broken, there isn't any bug here.
Using LPOP the queue can be empty and the next LPOP will take seconds (as configured). If instead BLPOP is used, the process will wait until the queue has an element, and then process it instantly.
It's a subtle enhancement, open to discussion

Going to hold off on this since there is no bug with current implementation.


Improve failure reasons

add additional failure reasons and also small refactoring
[test]

re[test]

[merge]


Android?

I understand that libusb offers some Android support.
Has anyone tested this on Android?

I'm also interested in a libusb rust-wrapper for android.
With the rust-android-gradle plugin and NDK 21 I had no luck to get libusb1-sys compiled.

It's on my TODO list to add this to the documentation, but for now refer to this PR for a working Android example https://github.com/a1ien/rusb/pull/39

@avantgardnerio @a1ien Do any of you have any suggestions on how to get libusb1-sys to build for the aarch64-linux-android and armv7-linux-androideabi targets?
This is what my cargo/config.toml looks like:
[target.aarch64-linux-android]
ar = "/opt/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android-ar"
linker = "/opt/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android26-clang"

[target.armv7-linux-androideabi]
ar = "/opt/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/arm-linux-androideabi-ar"
linker = "/opt/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/armv7a-linux-androideabi26-clang"

Building for the host OS that I'm on (Linux) with this library works fine, probably because I have libusb installed and in PATH.
I'm able to build and run for the android targets without this library, so I know they are configured correctly, the problem occurs when I have rusb = "0.8" installed, building with this library results in the following error:

Click to show error log
project git:(master) ✗ cargo build --target armv7-linux-androideabi
   Compiling libusb1-sys v0.5.0
error: failed to run custom build command for `libusb1-sys v0.5.0`

Caused by:
  process didn't exit successfully: `/home/nohac/Dev/Rust/project/target/debug/build/libusb1-sys-49e24e6f1687238c/build-script-build` (exit code: 1)
  --- stdout
  cargo:rerun-if-env-changed=LIBUSB_1.0_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_armv7-linux-androideabi
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_armv7_linux_androideabi
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_ALLOW_CROSS
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS
  Can't find libusb pkg: CrossCompilation
  cargo:vendored=1
  cargo:static=1
  cargo:include=/home/nohac/Dev/Rust/project/target/armv7-linux-androideabi/debug/build/libusb1-sys-ba3ad791dc5ab88a/out/include
  cargo:rerun-if-env-changed=LIBUDEV_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_armv7-linux-androideabi
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_armv7_linux_androideabi
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_ALLOW_CROSS
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS
  Including posix!
  TARGET = Some("armv7-linux-androideabi")
  OPT_LEVEL = Some("0")
  HOST = Some("x86_64-unknown-linux-gnu")
  CC_armv7-linux-androideabi = None
  CC_armv7_linux_androideabi = None
  TARGET_CC = None
  CC = None
  CFLAGS_armv7-linux-androideabi = None
  CFLAGS_armv7_linux_androideabi = None
  TARGET_CFLAGS = None
  CFLAGS = None
  CRATE_CC_NO_DEFAULTS = None
  DEBUG = Some("true")
  running: "arm-linux-androideabi-clang" "-O0" "-DANDROID" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "-I" "/home/nohac/Dev/Rust/project/target/armv7-linux-androideabi/debug/build/libusb1-sys-ba3ad791dc5ab88a/out/include" "-I" "libusb/libusb" "-Wall" "-Wextra" "-DPRINTF_FORMAT(a, b)=" "-DENABLE_LOGGING=1" "-DOS_LINUX=1" "-DHAVE_ASM_TYPES_H=1" "-D_GNU_SOURCE=1" "-DHAVE_TIMERFD=1" "-DHAVE_EVENTFD=1" "-DHAVE_SYS_TIME_H=1" "-DHAVE_NFDS_T=1" "-DPLATFORM_POSIX=1" "-DHAVE_CLOCK_GETTIME=1" "-DDEFAULT_VISIBILITY=__attribute__((visibility(\"default\")))" "-o" "/home/nohac/Dev/Rust/project/target/armv7-linux-androideabi/debug/build/libusb1-sys-ba3ad791dc5ab88a/out/libusb/libusb/os/linux_netlink.o" "-c" "libusb/libusb/os/linux_netlink.c"

  --- stderr

  error occurred: Failed to find tool. Is `arm-linux-androideabi-clang` installed?

First off, I don't actually want to cross compile libusb as I already have the pre-built libraries for the architectures I need, however, I have no clue how to point rust or pkg-config to those libraries, it always uses the one I have installed on the system. I'm sorry if this should be obvious, I'm still pretty new to rust.
I also don't understand why it's trying to use arm-linux-androideabi-clang when the linker I configured is called armv7a-linux-androideabi26-clang
I'm sorry for directly tagging both of you, but I've been stuck on this for the last few days and would really appreciate some guidance. Thanks!

Try this
PATH=/opt/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin:$PATH cargo build --target armv7-linux-androideabi

Linker and compiler it's different things. For building libusb1-sys can be used installed version of libusb from distro package or vendored version.
When you cross-compile libusb for android you must add compiler to PATH
Also you can manual specify cross-compiler
PATH=/opt/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin:$PATH CC=armv7a-linux-androideabi26-clang cargo build --target armv7-linux-androideabi

@a1ien That last suggestion worked, thanks for the quick reply!


** IT'S BEEN A YEAR SINCE THE LAST RELEASE ON RUBYGEMS **

I was evaluating whether or not to use this gem, but it seems that it's currently abandoned. I also wonder if something happened to @bblimke
Is there any other maintainer in this repo?

Nothing happened to me apart from being busy and not having enough time for opensource :/ Just releasing new version.

@bblimke glad you're ok!!
What are your thoughts on adding the top 5 contributors as maintainers?


[Bug]: Unable to deploy extension via CI/CD

Please confirm that you have:

[X] Searched existing issues to see if your issue is a duplicate. (If you’ve found a duplicate issue, feel free to add additional information in a comment on it.)
[X] Reproduced the issue in the latest CLI version.

In which of these areas are you experiencing a problem?
Extension
Expected behavior
Deploy extensions to Shopify successfully.
Actual behavior
The Partners GraphQL API responded unsuccessfully with the HTTP status  200 and errors

Stack trace
No response
Reproduction steps

Deploy extensions via GitHub actions

Operating System
Ubuntu 20.04.5 5 LTS
Shopify CLI version (check your project's package.json if you're not sure)
3.44.1
Shell
No response
Node version (run node -v if you're not sure)
18
What language and version are you using in your application?
No response

Hi @iamvishnusankar . Thanks for your effort adding more context to the issue.
Regarding the first error posted in the description of the issue

The error 500 in this case means that your are trying to deploy a local app with extensions that don't exist in the remote app. The CLI is trying to create those extensions remotely however the partners token does not have permissions for that only for modifying the app. So that's the source of the problem of that 500 error. To avoid that you should always do a manual deployment and after it's successfully finished you can configure the CI/CD with the values you will find in the .env file generated. These instructions are better explained here

Regarding the second error
2023-03-01T16:30:40.4351513Z - Sec-CH-UA-PLATFORM: linux
2023-03-01T16:30:40.4352135Z - Content-Type: application/json
2023-03-01T16:30:40.4352405Z
2023-03-01T16:31:40.7382094Z ╭─ error ──────────────────────────────────────────────────────────────────────╮
2023-03-01T16:31:40.7383022Z │ │
2023-03-01T16:31:40.7383812Z │ │
2023-03-01T16:31:40.7384667Z │ The Partners GraphQL API responded unsuccessfully with the HTTP status │
2023-03-01T16:31:40.7385528Z │ 504 and errors: │
2023-03-01T16:31:40.7386259Z │ │
2023-03-01T16:31:40.7387048Z │ _** │
2023-03-01T16:31:40.7387770Z │ │
2023-03-01T16:31:40.7388466Z │ │
2023-03-01T16:31:40.7389237Z ╰──────────────────────────────────────────────────────────────────────────────╯
2023-03-01T16:31:40.7389609Z
2023-03-01T16:31:40.7608847Z 2023-03-01T16:31:40.760Z: Obtaining the dependency manager in directory /home/runner/work/appnamey/appnamey...
2023-03-01T16:31:40.7610917Z 2023-03-01T16:31:40.760Z: Obtaining the dependency manager in directory /home/runner/work/appnamey/appnamey...
2023-03-01T16:31:40.7732866Z 2023-03-01T16:31:40.773Z:
2023-03-01T16:31:40.7733729Z Running system process:

where you can see a 504 it seems to be a temporary error due to some network congestion, so it should not be persistent

Im still facing this issue
 ╭─ error ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │                                                                                │ │                                                                                │ │  The Partners GraphQL API responded unsuccessfully with errors:                                                                           │ │                                                                                │ │  [                                                                                │ │    {                                                                                │ │      "message": "Unexpected system error",                                                                                │ │      "extensions": {                                                                                │ │        "code": "500"                                                                                │ │      }                                                                                │ │    }                                                                                │ │  ]                                                                                │ │                                                                                │ │  Request ID: 2b013ae6-1684-4149-9f79-d231d050f36a-1729786228                                                                              │ │                                                                                │ │                                                                                │ │  To investigate the issue, examine this stack trace:                                                                                │ │    at makeRequest (Program%20Files/NVM/v20.10.0/node_modules/@shopify/cli/dist/chunk-OBGMH362.js:29869)                                   │ │    at processTicksAndRejections (node:internal/process/task_queues:95)                                                                    │ │    at async makeVerboseRequest (Program%20Files/NVM/v20.10.0/node_modules/@shopify/cli/dist/chunk-OBGMH362.js:29899)                      │ │    at async retryAwareRequest (Program%20Files/NVM/v20.10.0/node_modules/@shopify/cli/dist/chunk-OBGMH362.js:29972)                       │ │    at (Program%20Files/NVM/v20.10.0/node_modules/@shopify/cli/dist/chunk-OBGMH362.js:31486)                                               │ │    at (Program%20Files/NVM/v20.10.0/node_modules/@shopify/cli/dist/chunk-XQBHX6FC.js:29921)                                               │ │                                                                                │ ╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯


Items given to verified person that ordered.

Package is somehow linked to person so that a different user does not pick up someone else's food package
Possibilities are ID verification or ticket.

Determine best way to manage this.


Unable to get a Windows

Hi, i've installed Kivy on the new relase of Jessie (Stretch).
Now, when i lounch videoplayer.py i see this error:
[WARNING] [Config      ] Older configuration version detected (0 instead of 20)
[WARNING] [Config      ] Upgrading configuration in progress.
[INFO   ] [Logger      ] Record log in /root/.kivy/logs/kivy_17-08-31_0.txt
[INFO   ] [Kivy        ] v1.10.1.dev0, git-500de18, 20170831
[INFO   ] [Python      ] v2.7.13 (default, Jan 19 2017, 14:48:08)
[GCC 6.3.0 20170124]
[INFO   ] [Factory     ] 194 symbols loaded
[INFO   ] [Image       ] Providers: img_tex, img_dds, img_sdl2, img_pil, img_gif                                           (img_ffpyplayer ignored)
[INFO   ] [Text        ] Provider: sdl2
[INFO   ] [VideoGstplayer] Using Gstreamer <IP_ADDRESS>
[INFO   ] [Video       ] Provider: gstplayer
[INFO   ] [Window      ] Provider: egl_rpi
libEGL warning: DRI3: xcb_connect failed
libEGL warning: DRI2: xcb_connect failed
libEGL warning: DRI2: xcb_connect failed
[INFO   ] [OSC         ] using  for socket
[INFO   ] [Window      ] Provider: sdl2(['window_egl_rpi'] ignored)
error: XDG_RUNTIME_DIR not set in the environment.
[CRITICAL] [Window      ] Unable to find any valuable Window provider.
egl_rpi - EGLError: EGL_NOT_INITIALIZED (code x3001)
File "/usr/local/lib/python2.7/dist-packages/kivy/core/init.py", line 67,                                           in core_select_lib
cls = cls()
File "/usr/local/lib/python2.7/dist-packages/kivy/core/window/init.py", li                                          ne 949, in init
self.create_window()
File "/usr/local/lib/python2.7/dist-packages/kivy/core/window/window_egl_rpi.p                                          y", line 38, in create_window
self._create_egl_context(self.win, 0)
File "/usr/local/lib/python2.7/dist-packages/kivy/core/window/window_egl_rpi.p                                          y", line 68, in _create_egl_context
egl.Initialise(display)
File "kivy/lib/vidcore_lite/egl.pyx", line 352, in kivy.lib.vidcore_lite.egl.I                                          nitialise (/tmp/pip-6kvoQv-build/kivy/lib/vidcore_lite/egl.c:2591)
File "kivy/lib/vidcore_lite/egl.pyx", line 322, in kivy.lib.vidcore_lite.egl.r                                          aise_egl_error (/tmp/pip-6kvoQv-build/kivy/lib/vidcore_lite/egl.c:2168)
sdl2 - RuntimeError: No available video device
File "/usr/local/lib/python2.7/dist-packages/kivy/core/init.py", line 67,                                           in core_select_lib
cls = cls()
File "/usr/local/lib/python2.7/dist-packages/kivy/core/window/window_sdl2.py",                                           line 140, in init
super(WindowSDL, self).init()
File "/usr/local/lib/python2.7/dist-packages/kivy/core/window/init.py", li                                          ne 949, in init
self.create_window()
File "/usr/local/lib/python2.7/dist-packages/kivy/core/window/window_sdl2.py",                                           line 269, in create_window
self.fullscreen, resizable, state)
File "kivy/core/window/_window_sdl2.pyx", line 84, in kivy.core.window._window                                          _sdl2._WindowSDL2Storage.setup_window (/tmp/pip-6kvoQv-build/kivy/core/window/_w                                          indow_sdl2.c:2390)
File "kivy/core/window/_window_sdl2.pyx", line 57, in kivy.core.window._window                                          _sdl2._WindowSDL2Storage.die (/tmp/pip-6kvoQv-build/kivy/core/window/_window_sdl                                          2.c:1967)
x11 - ImportError: No module named window_x11
File "/usr/local/lib/python2.7/dist-packages/kivy/core/init.py", line 59,                                           in core_select_lib
fromlist=[modulename], level=0)
[CRITICAL] [App         ] Unable to get a Window, abort.
Can you help me?

Sorry, not really a help but I wanted to add that I also have major problems getting kivy running on jessie (stretch). I was already afraid when I saw that there was a new raspbian version (which, in the past was bad for installing kivy). Now even kivy has a new version...
The problem above accured and was fixed by switching from ssh to the real pi and attaching a monitor/mouse etc to it. But then only other errors relating pygames and so on occured.
@Developers
Please update your raspbian installation tutorial if possible... It was already out of date and didn't worked before version 1.10. (You have to downgrade to Cython 0.20 instead of installing the newst version) Now I can't even install it anymore because there are no insights about the new version...

error: XDG_RUNTIME_DIR not set in the environment.
sdl2 - RuntimeError: No available video device

I'm not sure, but it seems to me like you're running just the console and not the window manager. I got a similar error long ago in Travis when I didn't run the window manager / display.

I have the same problem on raspbian Stretch lite version (without GUI).
I want run kivy without Xorg... is possible? what is missing for work?

#5362
The foundation renamed some libraries in August 2017 to clear up some confusion.
libGLESv2.so became libbrcmGLESv2.so
libEGL.so became libbrcmEGL.so
and so on. Why ? It turns out Mesa ships libraries with exactly the same name and people were gettting confused which libraries were from Mesa and which from Broadcom. This is especially fatal since the libraries Mesa provides are better integrated with X , but less stable and a bit slower (speed has increased dramatically since hardware rendering was added).
reference: https://jp.raspberrypi.org/forums/viewtopic.php?f=68&t=192869
On kivy >= 1.10.1 is already fixed, therefore on raspbian Stretch must be used:
pip install --upgrade --force-reinstall git+https://github.com/kivy/kivy.git@master

Nice findings, especially the date. Perhaps you could include it to the RPi installation docs as a .. note::? I bet it will help someone using stable versions instead of digging through the github issues.

if you want i can, but how?

@submax82 you can edit this file, check the RST syntax on this page and submit a pull request :)

I see this is closed but still experience the error.
I am running:
sysop@pipaos:~$ cat /etc/*-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"

also have the latest kivy installed (pip installed from master)
sysop@pipaos:~$ cat /usr/local/lib/python2.7/dist-packages/kivy/version.py
# THIS FILE IS GENERATED FROM KIVY SETUP.PY
__version__ = '1.10.1.dev0'
__hash__ = 'ae3665c32e1fdb9b7564aa6bbceeb58b5cd09ec5'
__date__ = '20180423'

and when i run a basic examples as python /usr/local/share/kivy-examples/demo/camera/main.py i get
[CRITICAL] [Window      ] Unable to find any valuable Window provider.
egl_rpi - ImportError: cannot import name bcm
  File "/usr/local/lib/python2.7/dist-packages/kivy/core/__init__.py", line 59, in core_select_lib
    fromlist=[modulename], level=0)
  File "/usr/local/lib/python2.7/dist-packages/kivy/core/window/window_egl_rpi.py", line 12, in <module>
    from kivy.lib.vidcore_lite import bcm, egl

sdl2 - RuntimeError: No available video device
  File "/usr/local/lib/python2.7/dist-packages/kivy/core/__init__.py", line 67, in core_select_lib
    cls = cls()
  File "/usr/local/lib/python2.7/dist-packages/kivy/core/window/window_sdl2.py", line 140, in __init__
    super(WindowSDL, self).__init__()
  File "/usr/local/lib/python2.7/dist-packages/kivy/core/window/__init__.py", line 960, in __init__
    self.create_window()
  File "/usr/local/lib/python2.7/dist-packages/kivy/core/window/window_sdl2.py", line 272, in create_window
    self.fullscreen, resizable, state)
  File "kivy/core/window/_window_sdl2.pyx", line 93, in kivy.core.window._window_sdl2._WindowSDL2Storage.setup_window
  File "kivy/core/window/_window_sdl2.pyx", line 66, in kivy.core.window._window_sdl2._WindowSDL2Storage.die

x11 - ImportError: No module named window_x11
  File "/usr/local/lib/python2.7/dist-packages/kivy/core/__init__.py", line 59, in core_select_lib
    fromlist=[modulename], level=0)

[CRITICAL] [App         ] Unable to get a Window, abort.

I am seeing the exact same error as @ivopashov on kivy 1.10.1.dev0 using a Raspberry Pi 3B+ and Raspbian Stretch
The fix presented above does not fix it.

Hello! As a start. I have never got the Kivy Camera to run on my Desktop PC.
So you would probably need to check the source code for it.
Using PiCamera python-bindings you might find more success with.
If you set the OpenGL driver to Full KMS. You do that by running sudo raspi-config.
And add this to /home/pi/.bashrc: export DISPLAY=:0.0
sudo reboot or just run in Terminal: source ~/.bashrc
It should do the trick and even hide FBO errors.
I'm doing research regarding these issues. Hopefully tomorrow is the day for me to know the real answer for everything!

Hi, i'm more or less in this case, except i'd like to downgrade from 1.11dev0.
I'm assuming to run with python3 i must use pip3 instead of pip

am i right ?
and for downgrading a kivy installed i should use
pip install --upgrade --force-reinstall<EMAIL_ADDRESS>

I am seeing the exact same error as @ivopashov on kivy 1.10.1 using a Raspberry Pi 3B+ and Raspbian Stretch.
I am using the official RasPi 7" touchscreen, and python2. Is there any testing I can do to help? Thnx

I hope you guys have tried this Guide.
Otherwise Ubuntu Mate is using different drivers for the Graphics. So If Raspbian fails on you that much that you get FBO errors and such. Then I advice you to try out Ubuntu Mate.

@kuzeyron thanks, yes was building from the Kivy.org guide. Can't use Ubuntu Mate, want to use PipaOS for lightweight boot.

OK, it's working for me today:
Hardware: Raspberry Pi 3B+, official 7" touchscreen
OS: Rasbian Stretch Lite, latest release (June 2018) from here
Following build steps from Kivy.org here to install latest Kivy globally.
Kivy: 1.11.0.dev0 (@master) git-ce8017c, 20180918
Python: 2.7.13
python /usr/local/share//kivy-examples/demo/showcase/main.py
... runs fine

@Neex101 It will work unless you try running ScreenManager. I hit easily the memory leak.
But on the other hand, Kivy runs smoothly for me as well on ArchLinux which is on my Pi3B+.
But I'm only using Carousel so that's fine.

@kuzeyron  hi! So Kivy won't work on 3B+ with ScreenManager?? Is it a memory leak or just not enough memory? (maybe I can adjust the memory allocated to the GPU?). Is ArchLinux better than Rasbian Stretch Lite for this application, if so why? Many thanks,

@Neex101 Ubuntu Mate is known to have working drivers. Raspbian and Arch is using the same drivers.
I haven't looked on Ubuntu Mates drivers on how they compiled it and which syntaxes.
If I or someone else would manage to get the same drivers. Then the drivers could be placed on its own place and Kivy would simply just link it so other users know where to grab it from.
Yes, it's a memory leak. Not sure of the cause. But the Raspberry Pi foundation should be looking at the issue AFAIK. This is what I know: raspberrypi.org/forums

Wow. I'm shocked... thank you for your very helpful direction. I will try Mate immediately.

No I don't have any particular version. But as long as the drivers are using "llvmpipe" it should be good to go.

I had the same issue solved it by changing "multisamples=2" to "multisamples=0" in config.ini present in directory C:<username>.kivy\ if multisamples is beforehand equal to 0 change it to 2

Thank you. On my side it was an issue with full screen initialisation that was working on Windows but not on RPi. I'll try the multisamples option, too.

My issue is solved by changing the screen resolution of your raspberry-pi become smaller.

U are all des piiiites


Enable tests to run both against mock and api-server.

Move the tests from the config directory to the test directory and run
them both against the mock server as well as the api-server running as
a container (integration tests).
Mocks ApiClient.filterByParent should use parent uuid.

LGTM  waiting CI get success


Request Queue Rework

New version of #83 and #83 as per requests of @davidplowman.
This PR makes the request flow of picamera2 much simpler by:

Making the function queue 1:1 with a futures queue.
Removing the "completed_requests" management
Treating  wait andsignal_function the same everywhere.

This is done by using  a deque primitive and using builtin behaviors of Future objects.  Calls into the async underbelly now queue and unspool cleanly, and multiple callers into the module are supported.

Hi, thanks for this PR. There are quite a few things going on here, and I was wondering if each change could be put into its own commit so that it's a bit easier to tell what has changed and why. Maybe some of them would be better in their own PRs? I'd really like to merge some of your work, but I'd really also like to take it one change at a time. For example:

The changes to handling wait and signal_function - seems like a good thing so I'd like to be able to merge this without having to understand and merge everything else.
Removing the completed_requests queue - this was fulfilling a particular function so I'm not entirely clear why this has gone. Maybe we need to think about this one some more?
Creating a futures queue - I recall we talked about my use-case where I want to be able to wait for particular controls to take effect, so I'm keen to improve the code whilst still fulfilling these requirements. I haven't understood if these changes address that or not. Is there a way forward, do you think?

Thanks!

Its kind of tricky to pull these things apart. I keep trying to do smaller bits, but getting a bit hungup on the entanglement of part in the process_requests loop which has at least 7 distinct responsibilities.
Its hard to fix the signal_function and wait semantics as they hinge on how the futures mature/lock unlock, the "residual" completed requests make it really hard to work against the other futures surface while still supporting the pluripotent call structure.
As an aside, having to rebase/squash/sign for any change (when squash-merge is a GH supported merge option), interact with a custom linter, custom testing stack, and atypical branching structure make the work per-PR very high for me.

Hi again, I got the impression that  the wait/signal_function changes were maybe something that could be done in isolation, separate from everything else? It seemed like a good change, and something that could be targeted first?
As things stand I'm a bit reluctant to get rid of the completed_requests list as it performs a specific function (it reduces the time application loops have to sit waiting for the next frame after they have processed the previous one), Hence why I'm always keen to take things in pieces, easier ones first!!

This makes sense, but also the completed_requests internal storage leadds to a situation where a call to capture_frame can return an image from before the call was issued. I think this is a pretty unexpected behavior....

This makes sense, but also the completed_requests internal storage leads to a situation where a call to capture_*** can return an image from before the call was issued.

Yes that's true, maybe both mechanisms should be possible?

Also, there is no way to ensure the capture of serial frames presently...
I think this is a pretty unexpected behavior for a camera library....

The thing that is really at the lynch-pin of this complexity is this call.
There is a very complex combinatoric possibility space that functions entertains:

wait = True/False/None (3 bits)
signal_function is None or a callback (1 bit)
completed_requests is empty/full (thread linked!) (1 bit)

Depending on those inputs:

16/32 of branches will actually run the passed in function twice, once in the thread loop, and once in the calling thread. (I think this is a bug)
24/32 will return the result of the function, the rest return None
8/32 will raise exceptions from the function call if it raises any

Also, I should note that it calls to wait() aren't safe as another call to it, or an error in the thread loop could have removed the object.

@davidplowman I wanted to make sure you saw my note about how _exectute_or_dispatch() will often run functions twice.

Thanks for the reminder, I must have missed that previously!
Could you maybe just explain in a little more detail? Looking back at that piece of code, it looks like the function will remain on the list and get called again if done came back as False (I wasn't sure if that was the case you were referring to), but I believe is the intention there. But if I've overlooked something, then please do let me know. Thank you very much for your help!


Update Import-RecipientDataProperty.md

Submitted via Learn Editor.

Updated with "Important" note, per Bug 633835


Allow Running kedro-mlflow projects with an MLflow orchestrator

Description
kedro projects are mostly executed with kedro and kedro-mlflow is responsible in starting a new MLflow run/session with a given configs.
There are some scenarios where the kedro project could be executed with some sort of orchestrators, such as MLflow project, or an Airflow pipeline. Theses orchestrators can start themeseleves an MLflow RUN to take the control of the overall session. for example :

MLflow project that start an MLflow RUN where it put all the execution context before running the kedro project
An airflow Job that Start Run, execute kedro project, then get the resuts from the RUN to register or deploy the model

Context
We want to use MLflow project so we can run the kedro project from remote repo (for reproductibility) and fit the python environnement alongside with the fitted model (for accurate code dependencies)
This feature can also enable the integration of kedro-mlflow with more upstream tools
Possible Implementation
Maybe we can check here if mlflow have already an active RUN, if it's the case, we can use it when starting the kedro-mlflow run

In such a situation, what is the expected behaviour at the end of the pipeline. Do we expect the run to be closed? The other problem is that if mlflow is not properly configured by the orchestrator, the active run may be located in another tracking_uri than the one specified in the configuration, hence raising a mlflow.exceptions.MlflowException: Run 'xxx' not found error.
The easiest way to inject behaviour would be to pass the tracking.run.id to the configuration, but it requires the orchestrator modifying the config...

So the final decision is:

if an active mlflow run exists, we ignore all configuration in mlflow.yml and uses the configuration from environment
the pipeline logs in this active run
the mlflow run is NOT closed at the end of the kedro run

That looks good to me. It makes sense to delegate the entire session to the entity that created the run in the first place.


Parameter UI remove the chosen parameters after showing the report

It seems that the parameter UI does not save its state, so it removes all the parameters after the report has shown.
In the old Birt viewer you don't loose your chosen parameters.

We still have this problem, the parameter won't be marked.

My fault, this works as expected, forget to update the navbar.html


added test for vSphere Web Services API to fix #668

This adds a test that works in 0.8.0 but fails in 0.9.x, addressing issue #668.
Note that the vSphere Web Services WSDL is pretty complex and required the mocha timeout to be increased from the default 2000ms.

Would it be possible to shorten the WSDL so that we don't have to have the full file in our tests? I'm not happy with adding those full WSDL files for testing this particular issue only. If we'd do that, the size of the library would explode...
I know that this would perhaps take some time, but otherwise I'm afraid I can't merge the PR as the file sizes are so big (when I compare this to other rejected PRs in the past which where done by the main contributor @jsdevel) :(

WSDL shortened, and I was able to switch the test timeout back to defaults.

Thanks a lot for your effort :+1:

closing for lack of activity

I'd vote to reopen this one @jsdevel , as this PR was intended to introduce a failing test for this library, so that another community-member is able to take the challenge of providing a fix for it. I thouth it would be a good idea to have some "failing" request-response tests, so that we're aware of the bug/feature-request.
Maybe we can add the "needs pull-request" flag (which is kind of ironic, to flag a PR with)? I think it would make sense to keep this (and maybe we'll have some more of this kind) when I think of closing the "issues" section all together in the near future :smiley:

I concur -- I created this pull request, as something between 0.8.0 and 0.9.x caused my module node-vsphere-soap to break.
That plus issue #668 is still open, and this pull request was created so that a fix could be made so that issue could be closed.

@reedog117 do you plan on fixing the issue?

I'm not totally familiar with how node-soap parses the WSDL, so I'm not sure where to begin.  Any pointers as to where to look first so I'm not spinning my wheels as much?

I'd just dig in and trace it down to where the problem is.

closing for lack of activity