Better Classification for Tenant/Landlord Problem

Description
As a user, I would like the problem classification to have a higher precision and recall, so that I can properly classify my response
Scope of Work

[ ] Research improvements to classifying text in NLP
[ ] Augment current data on classification of Tenant/Landlord's problem for "Deposit" category
[ ] Augment current data on classification of Tenant/Landlord's problem for "Rent Change" category
[ ] Augment current data on classification of Tenant/Landlord's problem for "Lease Termination" category
[ ] Augment current data on classification of Tenant/Landlord's problem for "Non Payment" category
[ ] Implement classification improvement

Story Points

[Undefined]

Priority

Medium

Risk

Medium

Acceptance Criteria

System classifies the Tenant/landlord's problem with an F1 score of 85% or higher

Realistically, I believe this one will be at a medium priority, as we need the system to improve its classification. Keep in mind that depending on what accuracy threshold we're able achieve with the initial story, this may change to become a high (or low) priority item.

Updated

Just checked out RASA NLU library, which is a wrapper around a suite of NLP tools. This may come in handy for NLP as it will have a better performance than a single technique

New persistence model structure

System communication flowchart, to be followed when implementing new NLP system.

Proposed ER diagram. I was thinking that the Fact table could represent the existence of a particular fact in the system, meaning if we had 20 total facts that could be resolved, there'd be 20 columns.
FactEntity would have a foreign key to the Fact, and would signify a resolved fact with a determined value.

Looks good to me, but every fact would be stored as a row (not as a column like you mentioned), right?

Oh yeah my bad, typo. Every Fact would be a row. Every FactEntity would simply hold a value and a reference to the Fact that the value is for. That way if you want to refer to the existence of a fact, you'd make a relation with the Fact table, however if you wanted a relation with resolved facts, you'd have a relation with FactEntity.
An example flow would be,

ML tells NLP that the next fact that needs to be resolved is Fact a
current_fact relation in conversation is set to point to Fact a in the Fact table.
The user answers a question pertaining to Fact a
New Message with the response text that references Fact a (relevant_fact relationship) is created
NLP resolves the fact as for example "false", knowing the relevant type by looking at Fact.type
NLP passes the Fact id and the resolved value to ML which creates a FactEntity that has value "false" and points to Fact a.
ML returns next Fact to ask question for

Yup, that's exactly how I had imagined it to be. Makes sense to me, I can't spot any obvious flaws. :+1:

Closing as we had previously obtained verbal signoff


breaks the savestate feature of speedrun tools

using the latest version (0.9.3) causes the savestate feature of speedrun tools to break, specifically when creating a savestate you can no longer input anything nor load the savestate. reloading the current map with f5 allows the usage of the created savestate but the same issue occurs again when creating another savestate
https://github.com/exscape/Celeste-FewerVisualDistractions/assets/90344513/d527ac4b-f4a0-4cfb-8599-0d1d2ebad540
the freezes in midair are the creation of the savestate, it doesnt appear well in the video but for a split second the death wipe shows up and disappears.
the master switch does not appear to change this behavior

Thanks for the report, and for including the video!
I had a look at this and traced the issue to the screen wipe removal in this mod. It changes the level's screen wipe to null (and then restores it again), and Speedrun Tool uses the screen wipe's onComplete action to unfreeze the game after saving/loading. So when the wipe is removed, the action never runs.
I made a quick fix that makes everything work when screen wipes are enabled in this mod (and so also when the master switch is off), but I'll try to rework the screen wipe patch such that you can disable screen wipes AND have save states working properly.

FewerVisualDistractions-0.9.4.zip
@Shiggy-dev Could you test this version?
If it works (it works fine for me) I'll upload it to GameBanana later today or tomorrow, unchanged.
When screen wipes are enabled (i.e. unmodded), everything works as-is now.
When they are disabled, v0.9.4 will execute any onComplete actions for screen wipes the next frame, which at least solves the hangs with Speedrun Tool.

this does seem to work for me as well, thank you!


pandas.Int64Index warning on xgboost 1.6.0

The following error occurred while I was running xgboost==1.6.0 for some tuning workloads on tvm:
/xxx/python3.8/site-packages/xgboost/compat.py:36: FutureWarning: pandas.Int64Index is deprecated and will be removed from pandas in a future version. Use pandas.Index with the appropriate dtype instead.
  from pandas import MultiIndex, Int64Index

I can send in a PR to fix this if necessary. Thanks!

Are you sure you are using XGBoost 1.6.0? In #7595, we removed all uses of Int64Index from the XGBoost codebase. This change is part of the 1.6.0 release.

@hcho3  Thanks! It turned out to be an issue with 1.5.2. Closing this issue.


IconDiffBot2 shits itself on some .dmi files with big icons

From:
https://github.com/yogstation13/Yogstation/runs/19222841503
Stack trace:
`Error handling job
An unexpected error occured during processing, possibly caused by malformed maps, icons, or server catching fire.
The following stack trace may be useful:
Stack trace
IconFile::from_bytes failed for "yogstation/icons/mob/screen_full_big.dmi"
Caused by:
Unexpected end of data before image end.`
File in question:
https://github.com/EdgeLordExe/Yogstation/blob/jungleland/yogstation/icons/mob/screen_full_big.dmi

We are getting this on https://github.com/BeeStation/BeeStation-Hornet/pull/9501/checks?check_run_id=19244107934


Bootstrap error

Fresh 10.10 install, ran commands per REDME.md, got this:

I just tried to run this on 10.11.2 and got the bootstrap.sh:13: = not found?

Hmm sh -x bootstrap.sh worked


Web UI, catalog, combo box app selection bug

A bug in web UI as seen on those screenshots:

Rancher Version:
1.2.0
Docker Version:
1.12.3
OS and where are the hosts located? (cloud, bare metal, etc):
RancherOS AMI, latest from AWS marketplace
Setup Details: (single node rancher vs. HA rancher, internal DB vs. external DB)
Single node master, test with 1 additional slave node.  internal DB, simple docker run install.
Environment Type: (Cattle/Kubernetes/Swarm/Mesos)
Probably unrelated but K8s, link looks like this: http://xx.xxx.xxx.xx:8080/env/1a16/catalog/community:kubernetes*rabbitmq
Steps to Reproduce:
Open some random app in catalog, I opened Zookeeper, then use combo box with app name to select other apps, without going back to main catalog page.
Results:
Description always stays the one of 1st used app (Zookeeper as in screenshot)
Expected:
Description to be relevant to selected app from combo box.

Version - 1.2.0
Checked this with the latest version and it is easily reproducible and indeed a bug.

#6470


github actions mamba error workaround

Applying the same change as @BelligerG made in https://github.com/MetOffice/improver_suite/pull/1282 to this repo.
That is to remove the json files under cache.
Additionally pinned 'click' to avoid issue with black error as per https://github.com/MetOffice/paraflow/pull/42
There is now a recent version of black (>=22.3.0) which fixes/avoids the issue.  I tried updating black but this resulted in a number of formatting issues found by black.  I considered fixing these out of scope for getting the actions up and running so I think updating black can be discussed in a separate issue.
Background

Removal of cache as per https://github.com/mamba-org/mamba/issues/488
Pinning of 'click' (dependency of black) as per https://github.com/psf/black/issues/2964

You're not using an environment cache in the scheduled.yml workflow?

Good spot.  The workaround isn't necessary in that case for 'scheduled.yml' (I'll update now).
Not sure why cache isn't used here but I think beyond scope of this PR.

You're not using an environment cache in the scheduled.yml workflow?

This is intentional - see https://github.com/metoppv/improver/pull/1651#issue-1108889073 for details.


Stegosaurus did not have a brain in it's tail

https://www.smithsonianmag.com/science-nature/the-double-dinosaur-brain-myth-12155823/

Um... fixed?


Glob matching is case sensitive on Windows

Exclude/Include filters should be case insensitive on Windows

There is a configuration option to ignore / not ignore case in files name - compareFolders.ignoreFileNameCase

Cool, thanks. Perhaps this should default to on for windowz?

It's a nice idea. I'll ask the community what they think should be default. Hope they will answer :)
https://www.linkedin.com/posts/moshfeu_comparefolders-activity-6698302120094957568-AA5t

Democracy is winning :)


minimum variance optional parameter

project variance to ensure a minimum bound on whatever method utilized

Codecov Report
Base: 98.50% // Head: 98.51% // Increases project coverage by +0.01% :tada:

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

Additional details and impacted files
@@            Coverage Diff             @@
##           master      #27      +/-   ##
==========================================
+ Coverage   98.50%   98.51%   +0.01%
==========================================
  Files           7        7
  Lines         268      270       +2
==========================================
+ Hits          264      266       +2
  Misses          4        4

Impacted Files
Coverage Δ

src/extern.jl
100.00% <100.00%> (ø)

src/types.jl
97.14% <100.00%> (+0.08%)
:arrow_up:

src/updatev.jl
98.76% <100.00%> (+0.03%)
:arrow_up:

src/HePPCAT.jl
100.00% <0.00%> (ø)

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

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

@javiersc-umich oh, it'd also be great if you could add a test to test/runtests.jl to cover the failure case. No worries if you don't though, I can add one later too.


Record & replay binary file response correctly

The way nock currently implements the loading of previously recorded fixtures does not support proper binary responses, as nock cannot differentiate between a binary file encoded as hex string and a simple string. To work around that I've added a new flag to fixtures (nockDef): responseIsBinary.
I could not find a better workaround for it, but this works.

actually no, still not working I think ugh I thought I got it. I’ll investigate further

An alternatively could be to prefix the hex-encoded string with something like binary: and then check for that instead of the additional responseIsBinary flag. Maybe that's more elegant?
I also realised that this is only testing the response case, not the request case, I'll extend the test & implementation to cover a binary file upload, too

I've updated the test to also record a binary upload but that seems to work just fine without any extra handling

Okay this is ready for review. @n30n0v @ierceg
In summary, nock recorder now adds a responseIsBinary flag to fixture definitions, besides scope, method, path, status, etc. It is only set to true if the response string (which is hex encoded) is a binary buffer, it is not set to false otherwise.
The only alternative I can think of is to prefix the hex string with something like binary: or NOCKBINARYHEX:

I'm super exited about this pr! Thank you!

Thanks for the review @simlu 👍
I’ll move forward and merge that in


Update Composer dependencies (2022-02-08-00-11)

Visual regression test passed!
View the visual regression test report


Object reference not set to an instance of an object when deploying app service or slot with one of the properties value as object.

Azure Bicep Cli Version - 0.9.1
We were using below module code to deploy app service since past 3 months but never faced the failure but now when we try to deploy it randomly throws the below error.
We are deploying 5 app services using a for loop and app service module.
"Object reference not set to an instance of an object ".

After spending couple of hours of debugging the below module, we concluded if the property value for 'ipSecurityRestrictions' is not passed then its working fine but as soon as we are passing this highlighted array then its failing randomly for any app service. On further checking the ARM template in deployment history its creating object for its values.
We are not only sending object as IPSecurityRestrictions but also for app service config application settings also.
Please let us know if this issue is due to recent upgrades in resource manage or do we need to pass all the objects as parameters.

This feels related to #7865. @alex-frankel could you check whether the Microsoft.Web team's fix will also apply to the Microsoft.Web/sites/slots resource?

@anthony-c-martin  @alex-frankel  The above error is being returned both when deploying app service and app service slot.
Shall we downgrade the bicep cli version in order to make it work ?

@alex-frankel I 'think' I've just hit this same issue today (this was working without changes the last day or 2) whereby app service deployments are now failing with Object reference not set to an instance of an object
I've tried @Ppkd2021 workaround by removing the ipSecurityRestrictions node but this just moved the error into another deployment (presumably due to another property that we are passing in)
Do you know if this has regressed recently or some new change has been made?
I had originally thought it was #7865  that regressed, but this issue does seem slightly different

This has just appeared this morning for us too, attempting to deploy any AppService (Function, web, api) is causing the Object reference not set to an instance of an object. message.
As @wahyuen mentioned, occasionally some of the deploys are succeeding, and I can't see any commonality between which apps are succeeding and failing.
We're using AzureResourceManagerTemplateDeployment@3 via azure pipelines, but I can reproduce the error using Bicep 0.10.61 https://github.com/Azure/bicep/releases/tag/v0.10.61

Also currently butting up against this issue, seems to be no commonality between which passes and fails

We are also hitting this, which started yesterday. With no changes to our code or environment, this issue is happening every release of our Bicep template or its equivalent ARM.

We're hitting this issue intermittently today too. Oddly, we hit it even without changing anything in our deployment.
We can deploy once and it will deploy fine, then redeploy again and get this error, then redeploy again without changing anything and it will deploy fine. I suspect the issue is on the backend with azure's resource management, and not with bicep, since it deploys fine sometimes.

I've shared this with the Web Resource Provider team, so hoping they will investigate today. It might be productive for someone to open a support case in the meantime.

Stating yesterday, I'm seeing this issue as well with unchanged Static Webapps & App Service templates starting yesterday in East US 2.  Not all deployments are failing and will usually succeed on a re-deploy.  Seemingly no commonality between failures/sucesses.

I was deploying to East US 2 also. I opened a support case for it and redeployed until I got a failure for them to examine. We'll see what they say.

Can anyone share correlation IDs from when they run into this issue? That will help the web team track down the root cause.  The web team has also deployed some fixes recently that we think should be addressing some of these issues, but those need time to roll out, so it may take up to a week to get this fully resolved.

Hey All, as Alex mentioned we have a code change in flight and will be rolling out in the next couple weeks. We are aware of this intermittent issue and have applied a mitigation where this is occurring: East US 2, UK South & Australia East.
In order to help us track down how we reach this state: can you please share your templates? Or perhaps some information regarding the kinds of resources deployed on templates running into this problem:
Web Apps only?
Static Apps only?
Both?

Can anyone share correlation IDs and/or bicep code that repros from when they run into this issue? That will help the web team track down the root cause. The web team has also deployed some fixes recently that we think should be addressing some of these issues, but those need time to roll out, so it may take up to a week to get this fully resolved.

Correlation IDs:
Static Apps: 4ec81a8b-b854-49e5-b8ae-81ae85253460, aaec3680-9d69-4415-8e32-10cc4d96286c
App Service: eaf90fa9-4b51-4a72-8ba3-751f5919eaaf

App Service
CorrelationIds:
0ae3a679-f3b4-4a6b-8f39-f83cf3ab424c
ccf4d440-ef1b-4365-9429-3ef795b23712
f880db1e-bbfb-4e26-86cd-6586e55c2e86
c1843112-cd90-4152-83e0-b3a8a22650f7
e7396b06-8ecc-4672-9c26-c945744dd0d7
14d9ad6d-ed4a-4cee-9c9c-8131607250f0
38cef05b-d6b7-462e-b343-310f88517530
9d183ac0-f740-4a0a-9825-df0e23631fbc
308a4d14-8d76-4e5d-bf1c-ebe76541f47a
resource appService 'Microsoft.Web/sites@2021-03-01' = {
  name: appServiceName
  kind: 'app'
  location: location
  tags: tags
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    serverFarmId: serverFarmId
    enabled: true
    hostNameSslStates: [
      {
        name: '${appServiceName}.azurewebsites.net'
        sslState: 'Disabled'
        hostType: 'Standard'
      }
      {
        name: '${appServiceName}.scm.azurewebsites.net'
        sslState: 'Disabled'
        hostType: 'Repository'
      }
    ]
    siteConfig: {
      appSettings: [
        {
          name: 'APPINSIGHTS_INSTRUMENTATIONKEY'
          value: appInsightsInstrumentationKey
        }
        {
          name: 'WEBSITE_RUN_FROM_PACKAGE'
          value: '1'
        }
        {
          name: 'Auth0_AUTHENTICATION_SECRET'
          value: auth0SozeClientSecret
        }
      ]
      alwaysOn: true
      http20Enabled: true
      minTlsVersion: '1.2'
      use32BitWorkerProcess: false
      webSocketsEnabled: true
      netFrameworkVersion: 'v6.0'
      ftpsState: 'Disabled'
      ipSecurityRestrictions: includeFrontDoor ? [
        {
          ipAddress: 'AzureFrontDoor.Backend'
          action: 'Allow'
          tag: 'ServiceTag'
          priority: 100
          name: 'FrontDoor'
          headers: {
            'x-forwarded-host': [
                '${frontDoorName}.azurefd.net'
                '${hostName}'
            ]
            'x-azure-fdid' : [
                frontDoorId
            ]
        }
        }
      ] : null
    }
    httpsOnly: true
    scmSiteAlsoStopped: false
    clientAffinityEnabled: true
    clientCertEnabled: false
    clientCertMode: 'Required'
    hostNamesDisabled: false
    containerSize: 0
    dailyMemoryTimeQuota: 0
    redundancyMode: 'None'
    storageAccountRequired: false
    keyVaultReferenceIdentity: 'SystemAssigned'
  }
}

resource appServiceStack 'Microsoft.Web/sites/config@2021-03-01' = {
  name: 'metadata'
  kind: 'web'
  parent: appService
  properties: {
    CURRENT_STACK : 'dotnetcore'
  }
}

resource appServiceAuth 'Microsoft.Web/sites/config@2021-03-01' = if(includeEasyAuth) {
  name: 'authsettingsV2'
  kind: 'web'
  parent: appService
  properties: {
    globalValidation: {
      redirectToProvider: 'Auth0'
      requireAuthentication: true
      unauthenticatedClientAction: 'RedirectToLoginPage'
    }
    httpSettings: {
      forwardProxy: {
        convention: 'Standard'
      }
      requireHttps: true
      routes: {
        apiPrefix: '/${subRoute}/.auth'
      }
    }
    identityProviders: {
      azureActiveDirectory: {
        enabled: true
        login: {
          disableWWWAuthenticate: false
        }
        registration: {}
        validation: {
          defaultAuthorizationPolicy: {
            allowedPrincipals: {}
          }
          jwtClaimChecks: {}
        }
      }
      customOpenIdConnectProviders: {
        Auth0 : {
          registration: {
            clientCredential: {
              clientSecretSettingName: 'Auth0_AUTHENTICATION_SECRET'
            }
            clientId: auth0SozeClientId
            openIdConnectConfiguration: {
              wellKnownOpenIdConfiguration: 'https://${auth0SozeSubDomain}/.well-known/openid-configuration'
            }
          }
        }
      }
    }
    login: {
      allowedExternalRedirectUrls: []
      cookieExpiration: {
        convention: 'FixedTime'
        timeToExpiration: '08:00:00'
      }
      nonce: {
        nonceExpirationInterval: '00:05:00'
        validateNonce: true
      }
      preserveUrlFragmentsForLogins: false
      routes: {}
      tokenStore: {
        enabled: true
        tokenRefreshExtensionHours: 72
      }
    }
    platform: {
      enabled: true
      runtimeVersion: '~1'
    }
  }
}

Receiving this error intermittently with the following bicep template
@minLength(2)
@maxLength(60)
param name string

param tags object
param location string

@description('App service plan to associate to Function App')
param appServicePlanId string

@description('Storage account name to use for hosting')
param storageAccountName string

@description('Application Insights name to use for monitoring')
param appInsightsName string

@allowed([
  '~4'
  '~3'
  '~2'
  '~1'
])
@description('Specific version of the runtime on Windows')
param functionsExtensionVersion string = '~4'

@allowed([
  'dotnet'
  'node'
  'java'
  'python'
  'powershell'
])
@description('The language stack to be used for functions in this app')
param functionWorkerRuntime string = 'dotnet'

// Modules and resource declaration

resource functionApp 'Microsoft.Web/sites@2021-03-01' = {
  name: name
  location: location
  kind: 'functionapp'
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    serverFarmId: appServicePlanId
    httpsOnly: true
  }

  tags: tags
}

resource storageAccountRef 'Microsoft.Storage/storageAccounts@2022-05-01' existing = {
  name: storageAccountName
  scope: resourceGroup()
}

resource appInsightsRef 'Microsoft.Insights/components@2020-02-02' existing = {
  name: appInsightsName
  scope: resourceGroup()
}

resource swaAppSettings 'Microsoft.Web/sites/config@2021-01-15' = {
  name: 'appsettings'
  parent: functionApp
  properties: {
    AzureWebJobsStorage: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};EndpointSuffix=${environment().suffixes.storage};AccountKey=${storageAccountRef.listKeys().keys[0].value}'
    WEBSITE_CONTENTAZUREFILECONNECTIONSTRING: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};EndpointSuffix=${environment().suffixes.storage};AccountKey=${storageAccountRef.listKeys().keys[0].value}'
    WEBSITE_CONTENTSHARE: toLower(name)
    FUNCTIONS_EXTENSION_VERSION: functionsExtensionVersion
    APPINSIGHTS_INSTRUMENTATIONKEY: appInsightsRef.properties.InstrumentationKey
    FUNCTIONS_WORKER_RUNTIME: functionWorkerRuntime
    ftpsState: 'FtpsOnly'
    minTlsVersion: '1.2'
  }
}

output id string = functionApp.id


Plugin with dynamic api key option

Hello,
I'm developing an Ionic 5 app and I'm planning to incorporate this plugin. There are multiple companies that are interested in the app and they would like to distribute the app to their employees, which puts me in a bit of an odd situation.
Each company wants to use their own google api key (beause of the billing). Is there a way, to dynamically input the API key through js code?  This would allow me to use a single publish of the app for all the clients. Otherwise I'd have to create a publish (with the specific API key) for every company that wants to use the app.
Thank you for your time and effort

Hi,
Do you know that using Google Maps native SDK is free on iOS and Android? Therefore, do you really need a different API key for each company?

Is there a way, to dynamically input the API key through js code?

Unfortunately, no.


How to hide dynamic column from datagrid?

I have an installation of OROCRM 2.0. I have created an entity Asset than mapped asset with Account Bundle with migration.
class AccountMaptoAsset implements Migration, ExtendExtensionAwareInterface
{
  protected $extendExtension;

  public function setExtendExtension(ExtendExtension $extendExtension)
  {
      $this->extendExtension = $extendExtension;
  }

  public function up(Schema $schema, QueryBag $queries)
  {
      $this->extendExtension->addManyToOneRelation(
          $schema,
          'hotelivate_asset', // owning side table
          'account', // owning side field name
          'orocrm_account', // inverse side table
          'name', // column name is used to show related entity
          ['extend' => ['owner' => ExtendScope::OWNER_CUSTOM]]
      );
      $this->extendExtension->addManyToOneInverseRelation(
          $schema,
          'hotelivate_asset', // owning side table
          'account', // owning side field name
          'orocrm_account', // inverse side table
          'assets', // inverse side field name
          ['name'], // column names are used to show a title of owning side entity
          ['name'], // column names are used to show detailed info about owning side entity
          ['name'], // Column names are used to show owning side entity in a grid
          ['extend' => ['owner' => ExtendScope::OWNER_CUSTOM]]
      );
  }
}

All things working properly and in  datagrid a column named ACCOUNT  automatic appears according to migration.
But i want to hide or remove this column ACCOUNT from my datagrid. I don't understand how to do this beacuse in datagrids.yml  file i have not written any line of code to show this column.
Is there are any way to handle this? Please Reply if any possibility to do this.

Hi, kusgpt26
Yes, you can achieve this using datagrid event listeners.
You need to create your own listener for your datagrid and add option "'renderable' => false" to column 'ACCOUNT'
Please take a look at this example:
https://github.com/orocommerce/orocommerce/blob/master/src/Oro/Bundle/TaxBundle/EventListener/CustomerTaxCodeGridListener.php#L16
Although it is from orocommerce, in this case it doesnt matter.

Hi @kusgpt26,
Please, have a look at this https://github.com/orocrm/crm/issues/279

Duplicate of orocrm/crm#279


Ammy files fail to compile when referencing x64 class library

I'm running Ammy 1.2.10 from MyGet. I've got a class library which is compiled for x64 architecture. When I reference the library project in another project (also x64, running Ammy), I get compilation errors while trying to import any namespace from that library:
using AmmyTest.Foo; // ← This can't be resolved

Window "WpfApplication1.Window1" {
}

I've created a skeletal project to demonstrate the issue: https://yadi.sk/d/ksboLp_Q3Ettjn.
When I change both projects' architecture to AnyCPU, everything compiles fine.

Common solution for such issues is to run outside x86_64 process and communicate with it. So it could load any assembly without problems. I think many heavy VS plugins are working this way, mostly to overcome 2GB memory limitation of 32-bit VS.


This problem has gone in the new version 2.0.0

          This problem has gone in the new version 2.0.0

Originally posted by @theggs in https://github.com/TuringSoftware/CrystalFetch/issues/11#issuecomment-1679340898

Should be fixed by 604859d17ac75ab17c05902cc96f247127e9dc8d


A new rule that makes sure the user have explained the reason of reverting

@realmarv CI is red

Ignore all my comments above, let's rebase this PR first.

Should it be without a body?
On Thu, 17 Nov 2022 at 13:21, Andres G. Aragoneses @.***>
wrote:

@.**** commented on this pull request.
In commitlintplugins.test.ts
https://github.com/nblockchain/conventions/pull/32#discussion_r1024970835
:

expect(properRevertMessage1.status).not.toBe(0);
+});

+test('proper-revert-message2', () => {

let commitMsgWithProperRevertMessage =

   'Revert "add abbreviations.ts"\n\n' +

   'This reverts commit 0272f587c7eece147e8d1756116b0b43e11c34ac\n' +

   'because/otherwise bla bla.'

let properRevertMessage2 = runCommitLintOnMsg(commitMsgWithProperRevertMessage);
expect(properRevertMessage2.status).toBe(0);
+});

+test('proper-revert-message3', () => {

let commitMsgWithProperRevertMessage = 'Revert "add abbreviations.ts"';

@realmarv https://github.com/realmarv let's add a new test that has the
commit message "Revert .NET6 migration", and it should have
assert(status).toBe(0)
—
Reply to this email directly, view it on GitHub
https://github.com/nblockchain/conventions/pull/32#discussion_r1024970835,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AL6SKIXMFBU4CGMNC4TKU7LWIX52HANCNFSM6AAAAAASA4QFU4
.
You are receiving this because you were mentioned.Message ID:
@.***>

Should it be without a body?

Yes, just a title that says "Revert .NET6 upd as it broke CI"

"Revert .NET6 upd as it broke CI"

Done

You didn't push your branch with push1by1. Also, this PR needs a rebase.

You didn't push your branch with push1by1. Also, this PR needs a rebase.

Done

This PR is closed and replaced with https://github.com/nblockchain/conventions/pull/68 because some commits needed to be squashed and rebased.

This PR should also remove one TODO line from commitling.config.ts.

Oops, this one is closed, sorry.


Need to document support for the msteams object for Adaptive Cards Action.Submit

messageBack and imBack

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

ID: 28d1cbcc-9670-6eb3-d65a-5c30d307784a
Version Independent ID: 243e29b8-afbc-7d21-1d24-18f58619af60
Content: Add card actions in a bot - Teams
Content Source: msteams-platform/concepts/Cards/cards-actions.md
Product: msteams
GitHub Login: @o365devx
Microsoft Alias: o365devx

This will be taken care of once we merge https://github.com/MicrosoftDocs/msteams-docs/pull/220.

This is now live.


feat: add a deep thinking reasoner model (o1-preview/mini)

This starts to introduce the concept of a "slower" reasoner model (alongside accelerator and processor) - and uses it via a toolkit for enhanced debugging/understanding and code authoring.
It will use the o1 models in some cases as needed, to compliment gpt4-o and gpt-4o-mini in the openai case. The "reasoner" model doesn't do tool calling or planning directly, but is consulting.

I have been using this all week to great success.

@michaelneale curious what specific sort of thing do you feel was more effective or possible with this vs without?

@codefromthecrypt mostly harder problems - for example the "interactive" fix for goose came from it initially (goose wasn't able to solve things that deep before). It also seems to help avoid goose prematurely jumping to a solution by misunderstanding the nuances of a problem and doing a "too obvious" thing. Well worth it IMO (and as a toolkit - so it doesn't kick in all the time).

@baxen I think this is ready for review - if interested to include it as something people can opt in or not (as toolkit, no extra deps)


[4.2] [stdlib] Work-around incorrect name resolution with conditional BidirectionalCollections.

Explanation: If a type conditionally conforms to BidirectionalCollection, suffix's (and the
others) use of index ends up dispatching through Collection.index seemingly
because it is a protocol requirement. The intended function is
BidirectionalCollection's overloaded index (which isn't connected to a
protocol requirement), which is called for non-conditional conformances. As
such, this is a work-around to stop code crashing.
Scope: Any calls to suffix or dropLast or removeLast on a type that conditionally conforms to BidirectionalCollection will crash
Radar/SR Issue: rdar://problem/42408692
Risk: Low, this is just adding an internal layer of functions with public callers, without changing behaviour.
Testing: CI testing.
Reviewer: @moiseev
4.2 merge of https://github.com/apple/swift/pull/18066

@swift-ci please test

Build failed
Swift Test OS X Platform
Git Sha - 24457a8362fbda53f29cfff260ceae040f375896

@swift-ci please test

Build failed
Swift Test OS X Platform
Git Sha - 24457a8362fbda53f29cfff260ceae040f375896

Build failed
Swift Test Linux Platform
Git Sha - 24457a8362fbda53f29cfff260ceae040f375896

Build failed
Swift Test Linux Platform
Git Sha - 24457a8362fbda53f29cfff260ceae040f375896

@swift-ci please test

Build failed
Swift Test OS X Platform
Git Sha - f549d5109975779160ef574f9dfff245b75a7452

Build failed
Swift Test Linux Platform
Git Sha - f549d5109975779160ef574f9dfff245b75a7452

@swift-ci Please clean test

Build failed
Swift Test Linux Platform
Git Sha - f549d5109975779160ef574f9dfff245b75a7452

Build failed
Swift Test OS X Platform
Git Sha - f549d5109975779160ef574f9dfff245b75a7452

@swift-ci please test

Build failed
Swift Test OS X Platform
Git Sha - f549d5109975779160ef574f9dfff245b75a7452

Build failed
Swift Test Linux Platform
Git Sha - f549d5109975779160ef574f9dfff245b75a7452

@swift-ci please test

Superseded by the non-perf-impacting https://github.com/apple/swift/pull/18233


Drop the use of createLocation

Might as well merge the fixes to the match docs.

The last commit should be squashed - I have it separate for now to highlight this interesting new edge case that comes up.

So, we're doing all of this just for the server-side match API, right? What if the router just reached into history's internals and required history/lib/createLocation for now? Would that be terrible?

@mjackson It's not enough in the general case - you need to go through the logic in useQueries or useBasename. The creation of the location object has to go through the history.

One more commit we need to squash, to make sure we actually are always running through all the history enhancers (the test case is contrived, but it fails without the change, so that's good enough for me).

Good point. But my intention never was for people to construct a history
object on the server. Servers are stateless, so I'd prefer to have a
server-side API that doesn't require people to create one.
On Tue, Dec 8, 2015 at 3:50 PM Jimmy Jia<EMAIL_ADDRESS>wrote:

@mjackson https://github.com/mjackson It's not enough in the general
case - you need to go through the logic in useQueries or useBasename. The
creation of the location object has to go through the history.
—
Reply to this email directly or view it on GitHub
https://github.com/rackt/react-router/pull/2680#issuecomment-163059563.

I don't know that we have a good way to get around it. With e.g. the current router API, <Link>s depend on history.createHref to create their hrefs.
I like the idea of not requiring a history for server-side rendering, but we'd have to rethink a lot of assumptions to get there, and I don't know that we'd end up somewhere where we didn't just invent a "stateless history" that just supports creating hrefs and such.

This is all going to change a lot when useRoutes is refactored. @mjackson had proposed something like this a while ago, which I liked:
history.listen(location => {
  match(location, routes, (error, state) => {
    render(...)
  })
})```
And I assume that would be how the internals of RouterContext will eventually look. And for SSR, it would be a simple swap:
```js
app.use((req, res) => {
  match(req.url, routes, (error, state) => {
    render(...)
  })
})```

Generally, stuff like query parsing is already done by the time the request hits the router on the server. In express, for example, people can do:
app.use(function (req, res) {
  match({
    routes,
    location: {
      pathname: req.path,
      query: req.query,
      state: req.body // or session state, or whatever
    }
  }, ...)
})

@timdorr I thought I was taking things in that direction in https://github.com/rackt/react-router/pull/2676 by switching it from location to path in match, but as you pointed out, that sort of API would exclude using state per e.g. https://github.com/rackt/react-router/pull/2175.

Sorry, hit enter too soon.
In that case, then the server wouldn't require a history object at all. We only require it right now because match hasn't been refactored.

@mjackson I actually mean converting the query to a search - that has to go through useQueries right now, per the latest commit on this PR.
@timdorr You don't need a history to run the route matching, but you can't render a <Link> properly without a history because of https://github.com/rackt/react-router/blob/master/modules/Link.js#L118.

Yeah, that's true. But it doesn't mean we have to fake a navigation to a location in history just to get it to work server side. That seems like we're missing something on history.

In general it just feels wrong to be using a history object at all in a stateless environment. I'd like to find a way forward that doesn't require us to do that.
Right now, useQueries and useBasename are both concerned with doing things that are commonly already done in server-side routers before they hit react router. The only things that we use history objects for that maybe we shouldn't is for these create* functions. e.g. <Link> needs to ask a history object how to create its href. But maybe it shouldn't do that.

@timdorr
It's tricky - you can't get the behavior demonstrated in the PR with entries, because the createMemoryHistory function doesn't have access to the "wrapped" push and replace methods, so there isn't a good way for that function to use the logic in any history enhancers wrapping it.
We could introduce a new API point on history to support this, but I don't think the extra API surface area in that case pays for itself. I don't really see anything wrong with calling history.push just to run the location descriptor through the transformations in the enhancers.

@mjackson
I think the way we would do that would be to factor out the "location creation" parts from the "navigation management" parts of history. Essentially, have an immutable object that handles locations and location conversion (i.e. the current logic in createPath, createHref, createLocation, &c.), and another part wrapping that core thing that handles push, pull, &c. This would make e.g. query and basename support largely orthogonal from hash v browser history.
I feel like this is a bigger refactoring than is practical at the moment, though. I also don't really know how this would work w/e.g. createHashHistory, which needs to modify how hrefs are constructed.
To the extent that we want to make server-side rendering less coupled with history, though, I think we should keep around history.createLocation; i.e. the non-documentation commits on this PR would be a step in the wrong direction.
Given that, what do you think about keeping around history.createLocation?

what do you think about keeping around history.createLocation?

If anything I think this PR has me convinced that we need to keep it around at least a little bit longer. But I'd really like to find better ways to do it in the future.

Okay - and to be clear, to avoid breaking users, it has to be the instance method, because right now it's explicitly part of this API that match will do things like format queries and strip out the basename for you.
I'm going to close this PR and re-submit with just the doc fixes from the first commit, so it's obvious that we didn't merge these changes.


GPU Memory Allocator OOM Before Limit Reached

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): Sort of, the issue seems to be occurring with the ELMo tfhub model
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Ubuntu 16.04
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device: N/a
TensorFlow installed from (source or binary): Binary
TensorFlow version (use command below): 1.11.0 (git version v1.11.0-0-gc19e29306c)
Python version: 3.6
Bazel version (if compiling from source): N/a
GCC/Compiler version (if compiling from source): N/a
CUDA/cuDNN version: 9.2/7.2.1
GPU model and memory: 1080 Ti (11177 MiB)
Exact command to reproduce:

estimator = tf.estimator.DNNClassifier(
                           hidden_units=[500, 100],
                           feature_columns=[hub.text_embedding_column(key="cleaned", module_spec="https://tfhub.dev/google/elmo/2")],
                           n_classes=2,
                           optimizer=tf.train.ProximalAdagradOptimizer(learning_rate=0.003))
estimator.train(input_fn=train_input_fn, steps=1000)

You'll need to provide the data, but this should reproduce the error.
Describe the problem
According to the memory trace, only 4.47 GiB have been allocated before the OOM error. Tensorflow has 8.74 GiB available. Barely over half of the available memory is used when tensorflow throws the OOM.
Source code / logs
2018-09-27 22:58:14.599824: W tensorflow/core/graph/graph_constructor.cc:1263] Importing a graph with a lower producer version 26 into an existing graph with producer version 27. Shape inference will have run different parts of the graph with different producer versions.
2018-09-27 22:58:16.160346: I tensorflow/core/platform/cpu_feature_guard.cc:141] Your CPU supports instructions that this TensorFlow binary was not compiled to use: AVX2 FMA
2018-09-27 22:58:16.241355: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:964] successful NUMA node read from SysFS had negative value (-1), but there must be at least one NUMA node, so returning NUMA node zero
2018-09-27 22:58:16.241872: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1411] Found device 0 with properties:
name: GeForce GTX 1080 Ti major: 6 minor: 1 memoryClockRate(GHz): 1.683
pciBusID: 0000:01:00.0
totalMemory: 10.92GiB freeMemory: 8.74GiB
2018-09-27 22:58:16.241896: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1490] Adding visible gpu devices: 0
2018-09-27 22:58:16.465458: I tensorflow/core/common_runtime/gpu/gpu_device.cc:971] Device interconnect StreamExecutor with strength 1 edge matrix:
2018-09-27 22:58:16.465495: I tensorflow/core/common_runtime/gpu/gpu_device.cc:977]      0
2018-09-27 22:58:16.465500: I tensorflow/core/common_runtime/gpu/gpu_device.cc:990] 0:   N
2018-09-27 22:58:16.465757: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1103] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 8437 MB memory) -> physical GPU (device: 0, name: GeForce GTX 1080 Ti, pci bus id: 0000:01:00.0, compute capability: 6.1)
2018-09-27 22:58:22.105125: W tensorflow/core/common_runtime/bfc_allocator.cc:215] Allocator (GPU_0_bfc) ran out of memory trying to allocate 2.97GiB. The caller indicates that this is not a failure, but may mean that there could be performance gains if more memory were available.
2018-09-27 22:58:22.167820: W tensorflow/core/common_runtime/bfc_allocator.cc:215] Allocator (GPU_0_bfc) ran out of memory trying to allocate 2.03GiB. The caller indicates that this is not a failure, but may mean that there could be performance gains if more memory were available.
2018-09-27 22:58:25.227506: W tensorflow/core/common_runtime/bfc_allocator.cc:215] Allocator (GPU_0_bfc) ran out of memory trying to allocate 3.04GiB. The caller indicates that this is not a failure, but may mean that there could be performance gains if more memory were available.
2018-09-27 22:58:25.293991: W tensorflow/core/common_runtime/bfc_allocator.cc:215] Allocator (GPU_0_bfc) ran out of memory trying to allocate 2.03GiB. The caller indicates that this is not a failure, but may mean that there could be performance gains if more memory were available.
2018-09-27 22:58:29.024543: W tensorflow/core/common_runtime/bfc_allocator.cc:215] Allocator (GPU_0_bfc) ran out of memory trying to allocate 3.21GiB. The caller indicates that this is not a failure, but may mean that there could be performance gains if more memory were available.
2018-09-27 22:58:31.129676: W tensorflow/core/common_runtime/bfc_allocator.cc:215] Allocator (GPU_0_bfc) ran out of memory trying to allocate 2.43GiB. The caller indicates that this is not a failure, but may mean that there could be performance gains if more memory were available.
[I 22:58:31.786 NotebookApp] Saving file at /Tensorflow Spam Classification.ipynb
2018-09-27 22:58:41.991342: W tensorflow/core/common_runtime/bfc_allocator.cc:271] Allocator (GPU_0_bfc) ran out of memory trying to allocate 2.30GiB.  Current allocation summary follows.
2018-09-27 22:58:41.991374: I tensorflow/core/common_runtime/bfc_allocator.cc:610] Bin (256):   Total Chunks: 54, Chunks in use: 54. 13.5KiB allocated for chunks. 13.5KiB in use in bin. 720B client-requested in use in bin.
2018-09-27 22:58:41.991384: I tensorflow/core/common_runtime/bfc_allocator.cc:610] Bin (512):   Total Chunks: 8, Chunks in use: 7. 4.2KiB allocated for chunks. 3.8KiB in use in bin. 3.3KiB client-requested in use in bin.
2018-09-27 22:58:41.991391: I tensorflow/core/common_runtime/bfc_allocator.cc:610] Bin (1024):  Total Chunks: 3, Chunks in use: 3. 3.2KiB allocated for chunks. 3.2KiB in use in bin. 3.0KiB client-requested in use in bin.
2018-09-27 22:58:41.991399: I tensorflow/core/common_runtime/bfc_allocator.cc:610] Bin (2048):  Total Chunks: 7, Chunks in use: 4. 15.5KiB allocated for chunks. 8.2KiB in use in bin. 8.0KiB client-requested in use in bin.
2018-09-27 22:58:41.991405: I tensorflow/core/common_runtime/bfc_allocator.cc:610] Bin (4096):  Total Chunks: 6, Chunks in use: 2. 27.8KiB allocated for chunks. 8.0KiB in use in bin. 8.0KiB client-requested in use in bin.
2018-09-27 22:58:41.991412: I tensorflow/core/common_runtime/bfc_allocator.cc:610] Bin (8192):  Total Chunks: 7, Chunks in use: 5. 68.0KiB allocated for chunks. 48.0KiB in use in bin. 44.0KiB client-requested in use in bin.
2018-09-27 22:58:41.991419: I tensorflow/core/common_runtime/bfc_allocator.cc:610] Bin (16384):         Total Chunks: 2, Chunks in use: 0. 40.2KiB allocated for chunks. 0B in use in bin. 0B client-requested in use in bin.
2018-09-27 22:58:41.991424: I tensorflow/core/common_runtime/bfc_allocator.cc:610] Bin (32768):         Total Chunks: 2, Chunks in use: 1. 81.0KiB allocated for chunks. 32.0KiB in use in bin. 32.0KiB client-requested in use in bin.
2018-09-27 22:58:41.991431: I tensorflow/core/common_runtime/bfc_allocator.cc:610] Bin (65536):         Total Chunks: 7, Chunks in use: 4. 540.0KiB allocated for chunks. 298.0KiB in use in bin. 256.0KiB client-requested in use in bin.
2018-09-27 22:58:41.991439: I tensorflow/core/common_runtime/bfc_allocator.cc:610] Bin (131072):        Total Chunks: 3, Chunks in use: 1. 525.5KiB allocated for chunks. 195.5KiB in use in bin. 195.3KiB client-requested in use in bin.
2018-09-27 22:58:41.991445: I tensorflow/core/common_runtime/bfc_allocator.cc:610] Bin (262144):        Total Chunks: 4, Chunks in use: 4. 1.46MiB allocated for chunks. 1.46MiB in use in bin. 1.38MiB client-requested in use in bin.
2018-09-27 22:58:41.991451: I tensorflow/core/common_runtime/bfc_allocator.cc:610] Bin (524288):        Total Chunks: 2, Chunks in use: 0. 1.66MiB allocated for chunks. 0B in use in bin. 0B client-requested in use in bin.
2018-09-27 22:58:41.991457: I tensorflow/core/common_runtime/bfc_allocator.cc:610] Bin (1048576):       Total Chunks: 1, Chunks in use: 1. 1.95MiB allocated for chunks. 1.95MiB in use in bin. 1.95MiB client-requested in use in bin.
2018-09-27 22:58:41.991463: I tensorflow/core/common_runtime/bfc_allocator.cc:610] Bin (2097152):       Total Chunks: 0, Chunks in use: 0. 0B allocated for chunks. 0B in use in bin. 0B client-requested in use in bin.
2018-09-27 22:58:41.991468: I tensorflow/core/common_runtime/bfc_allocator.cc:610] Bin (4194304):       Total Chunks: 2, Chunks in use: 1. 8.00MiB allocated for chunks. 4.00MiB in use in bin. 4.00MiB client-requested in use in bin.
2018-09-27 22:58:41.991475: I tensorflow/core/common_runtime/bfc_allocator.cc:610] Bin (8388608):       Total Chunks: 4, Chunks in use: 4. 32.00MiB allocated for chunks. 32.00MiB in use in bin. 32.00MiB client-requested in use in bin.
2018-09-27 22:58:41.991481: I tensorflow/core/common_runtime/bfc_allocator.cc:610] Bin (16777216):      Total Chunks: 5, Chunks in use: 4. 84.00MiB allocated for chunks. 64.00MiB in use in bin. 64.00MiB client-requested in use in bin.
2018-09-27 22:58:41.991488: I tensorflow/core/common_runtime/bfc_allocator.cc:610] Bin (33554432):      Total Chunks: 3, Chunks in use: 1. 115.59MiB allocated for chunks. 41.80MiB in use in bin. 41.80MiB client-requested in use in bin.
2018-09-27 22:58:41.991494: I tensorflow/core/common_runtime/bfc_allocator.cc:610] Bin (67108864):      Total Chunks: 4, Chunks in use: 4. 256.00MiB allocated for chunks. 256.00MiB in use in bin. 256.00MiB client-requested in use in bin.
2018-09-27 22:58:41.991500: I tensorflow/core/common_runtime/bfc_allocator.cc:610] Bin (134217728):     Total Chunks: 0, Chunks in use: 0. 0B allocated for chunks. 0B in use in bin. 0B client-requested in use in bin.
2018-09-27 22:58:41.991506: I tensorflow/core/common_runtime/bfc_allocator.cc:610] Bin (268435456):     Total Chunks: 6, Chunks in use: 3. 7.75GiB allocated for chunks. 4.08GiB in use in bin. 4.08GiB client-requested in use in bin.
2018-09-27 22:58:41.991512: I tensorflow/core/common_runtime/bfc_allocator.cc:626] Bin for 2.30GiB was 256.00MiB, Chunk State:
2018-09-27 22:58:41.991523: I tensorflow/core/common_runtime/bfc_allocator.cc:632]   Size: 615.25MiB | Requested Size: 225.70MiB | in_use: 0, prev:   Size: 41.80MiB | Requested Size: 41.80MiB | in_use: 1, next:   Size: 615.25MiB | Requested Size: 615.25MiB | in_use: 1
2018-09-27 22:58:41.991532: I tensorflow/core/common_runtime/bfc_allocator.cc:632]   Size: 1.17GiB | Requested Size: 1.17GiB | in_use: 0, prev:   Size: 615.25MiB | Requested Size: 615.25MiB | in_use: 1, next:   Size: 1.17GiB | Requested Size: 1.17GiB | in_use: 1
2018-09-27 22:58:41.991539: I tensorflow/core/common_runtime/bfc_allocator.cc:632]   Size: 1.90GiB | Requested Size: 2.0KiB | in_use: 0, prev:   Size: 2.30GiB | Requested Size: 2.30GiB | in_use: 1
2018-09-27 22:58:41.991545: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0000000 of size 1280
2018-09-27 22:58:41.991550: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0000500 of size 256
2018-09-27 22:58:41.991554: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0000600 of size 256
2018-09-27 22:58:41.991558: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0000700 of size 256
2018-09-27 22:58:41.991562: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0000800 of size 256
2018-09-27 22:58:41.991566: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0000900 of size 256
2018-09-27 22:58:41.991570: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0000a00 of size 256
2018-09-27 22:58:41.991575: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0000b00 of size 256
2018-09-27 22:58:41.991579: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0000c00 of size 256
2018-09-27 22:58:41.991583: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0000d00 of size 256
2018-09-27 22:58:41.991587: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0000e00 of size 256
2018-09-27 22:58:41.991591: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0000f00 of size 256
2018-09-27 22:58:41.991595: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0001000 of size 256
2018-09-27 22:58:41.991599: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0001100 of size 256
2018-09-27 22:58:41.991603: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0001200 of size 256
2018-09-27 22:58:41.991607: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0001300 of size 256
2018-09-27 22:58:41.991611: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0001400 of size 256
2018-09-27 22:58:41.991615: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0001500 of size 256
2018-09-27 22:58:41.991619: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0001600 of size 256
2018-09-27 22:58:41.991623: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0001700 of size 256
2018-09-27 22:58:41.991627: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0001800 of size 256
2018-09-27 22:58:41.991631: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0001900 of size 256
2018-09-27 22:58:41.991635: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0001a00 of size 256
2018-09-27 22:58:41.991639: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0001b00 of size 256
2018-09-27 22:58:41.991644: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0001c00 of size 512
2018-09-27 22:58:41.991648: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0001e00 of size 256
2018-09-27 22:58:41.991652: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0001f00 of size 256
2018-09-27 22:58:41.991656: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0002000 of size 256
2018-09-27 22:58:41.991660: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0002100 of size 256
2018-09-27 22:58:41.991664: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0002200 of size 256
2018-09-27 22:58:41.991668: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0002300 of size 256
2018-09-27 22:58:41.991672: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0002400 of size 256
2018-09-27 22:58:41.991676: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0002500 of size 256
2018-09-27 22:58:41.991680: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0002600 of size 256
2018-09-27 22:58:41.991684: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0002700 of size 256
2018-09-27 22:58:41.991688: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0002800 of size 256
2018-09-27 22:58:41.991692: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0002900 of size 256
2018-09-27 22:58:41.991696: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0002a00 of size 256
2018-09-27 22:58:41.991700: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0002b00 of size 256
2018-09-27 22:58:41.991704: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0002c00 of size 256
2018-09-27 22:58:41.991708: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0002d00 of size 256
2018-09-27 22:58:41.991712: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0002e00 of size 256
2018-09-27 22:58:41.991716: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0002f00 of size 256
2018-09-27 22:58:41.991720: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0003000 of size 256
2018-09-27 22:58:41.991724: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0003100 of size 256
2018-09-27 22:58:41.991727: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0003200 of size 256
2018-09-27 22:58:41.991731: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0003300 of size 512
2018-09-27 22:58:41.991735: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0003500 of size 256
2018-09-27 22:58:41.991739: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0003600 of size 256
2018-09-27 22:58:41.991743: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0003700 of size 256
2018-09-27 22:58:41.991747: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0003800 of size 768
2018-09-27 22:58:41.991752: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0003b00 of size 512
2018-09-27 22:58:41.991756: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0003d00 of size 256
2018-09-27 22:58:41.991760: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Free  at 0x7f94a0003e00 of size 91136
2018-09-27 22:58:41.991764: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a001a200 of size 8192
2018-09-27 22:58:41.991768: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Free  at 0x7f94a001c200 of size 16640
2018-09-27 22:58:41.991772: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0020300 of size 1024
2018-09-27 22:58:41.991779: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Free  at 0x7f94a0020700 of size 24576
2018-09-27 22:58:41.991786: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0026700 of size 8192
2018-09-27 22:58:41.991793: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Free  at 0x7f94a0028700 of size 50176
2018-09-27 22:58:41.991799: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0034b00 of size 256
2018-09-27 22:58:41.991805: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Free  at 0x7f94a0034c00 of size 12288
2018-09-27 22:58:41.991812: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0037c00 of size 4096
2018-09-27 22:58:41.991818: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Free  at 0x7f94a0038c00 of size 512
2018-09-27 22:58:41.991823: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0038e00 of size 512
2018-09-27 22:58:41.991829: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Free  at 0x7f94a0039000 of size 4096
2018-09-27 22:58:41.991834: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a003a000 of size 4096
2018-09-27 22:58:41.991839: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a003b000 of size 256
2018-09-27 22:58:41.991845: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Free  at 0x7f94a003b100 of size 74752
2018-09-27 22:58:41.991850: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a004d500 of size 512
2018-09-27 22:58:41.991855: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Free  at 0x7f94a004d700 of size 8192
2018-09-27 22:58:41.991860: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a004f700 of size 8192
2018-09-27 22:58:41.991866: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a0051700 of size 308736
2018-09-27 22:58:41.991871: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a009cd00 of size 256
2018-09-27 22:58:41.991876: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Free  at 0x7f94a009ce00 of size 198656
2018-09-27 22:58:41.991882: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a00cd600 of size 2048
2018-09-27 22:58:41.991887: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Free  at 0x7f94a00cde00 of size 2048
2018-09-27 22:58:41.991893: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a00ce600 of size 256
2018-09-27 22:58:41.991898: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a00ce700 of size 256
2018-09-27 22:58:41.991903: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Free  at 0x7f94a00ce800 of size 4352
2018-09-27 22:58:41.991909: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a00cf900 of size 2304
2018-09-27 22:58:41.991914: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a00d0200 of size 67108864
2018-09-27 22:58:41.991920: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a40d0200 of size 12288
2018-09-27 22:58:41.991925: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a40d3200 of size 256
2018-09-27 22:58:41.991930: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a40d3300 of size 65536
2018-09-27 22:58:41.991936: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a40e3300 of size 8388608
2018-09-27 22:58:41.991941: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Free  at 0x7f94a48e3300 of size 81920
2018-09-27 22:58:41.991946: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a48f7300 of size 67108864
2018-09-27 22:58:41.991952: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a88f7300 of size 65536
2018-09-27 22:58:41.991957: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a8907300 of size 8388608
2018-09-27 22:58:41.991963: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a9107300 of size 2048000
2018-09-27 22:58:41.991968: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a92fb300 of size 2048
2018-09-27 22:58:41.991973: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a92fbb00 of size 12288
2018-09-27 22:58:41.991979: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Free  at 0x7f94a92feb00 of size 3328
2018-09-27 22:58:41.991985: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a92ff800 of size 32768
2018-09-27 22:58:41.991991: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a9307800 of size 301056
2018-09-27 22:58:41.991996: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a9351000 of size 92160
2018-09-27 22:58:41.992001: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a9367800 of size 512
2018-09-27 22:58:41.992007: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Free  at 0x7f94a9367a00 of size 2048
2018-09-27 22:58:41.992012: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a9368200 of size 1024
2018-09-27 22:58:41.992017: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Free  at 0x7f94a9368600 of size 7424
2018-09-27 22:58:41.992022: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a936a300 of size 2048
2018-09-27 22:58:41.992028: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Free  at 0x7f94a936ab00 of size 4352
2018-09-27 22:58:41.992033: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a936bc00 of size 200192
2018-09-27 22:58:41.992038: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Free  at 0x7f94a939ca00 of size 917504
2018-09-27 22:58:41.992044: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a947ca00 of size 81920
2018-09-27 22:58:41.992049: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Free  at 0x7f94a9490a00 of size 139264
2018-09-27 22:58:41.992054: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a94b2a00 of size 458752
2018-09-27 22:58:41.992060: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a9522a00 of size 458752
2018-09-27 22:58:41.992065: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94a9592a00 of size 67108864
2018-09-27 22:58:41.992070: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Free  at 0x7f94ad592a00 of size 819200
2018-09-27 22:58:41.992075: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94ad65aa00 of size 8388608
2018-09-27 22:58:41.992081: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94ade5aa00 of size 67108864
2018-09-27 22:58:41.992086: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94b1e5aa00 of size 8388608
2018-09-27 22:58:41.992092: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94b265aa00 of size 4194304
2018-09-27 22:58:41.992097: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Free  at 0x7f94b2a5aa00 of size 4194304
2018-09-27 22:58:41.992102: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94b2e5aa00 of size 16777216
2018-09-27 22:58:41.992108: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Free  at 0x7f94b3e5aa00 of size 20971520
2018-09-27 22:58:41.992113: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94b525aa00 of size 16777216
2018-09-27 22:58:41.992118: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Free  at 0x7f94b625aa00 of size 33554432
2018-09-27 22:58:41.992123: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94b825aa00 of size 16777216
2018-09-27 22:58:41.992129: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94b925aa00 of size 16777216
2018-09-27 22:58:41.992134: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Free  at 0x7f94ba25aa00 of size 43827200
2018-09-27 22:58:41.992139: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94bcc26a00 of size 43827200
2018-09-27 22:58:41.992145: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Free  at 0x7f94bf5f2a00 of size 645136384
2018-09-27 22:58:41.992150: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f94e5d32a00 of size 645136384
2018-09-27 22:58:41.992155: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Free  at 0x7f950c472a00 of size<PHONE_NUMBER>
2018-09-27 22:58:41.992161: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f9557832a00 of size<PHONE_NUMBER>
2018-09-27 22:58:41.992166: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Chunk at 0x7f95a2bf2a00 of size<PHONE_NUMBER>
2018-09-27 22:58:41.992172: I tensorflow/core/common_runtime/bfc_allocator.cc:645] Free  at 0x7f9635df2a00 of size<PHONE_NUMBER>
2018-09-27 22:58:41.992177: I tensorflow/core/common_runtime/bfc_allocator.cc:651]      Summary of in-use Chunks by size:
2018-09-27 22:58:41.992184: I tensorflow/core/common_runtime/bfc_allocator.cc:654] 54 Chunks of size 256 totalling 13.5KiB
2018-09-27 22:58:41.992190: I tensorflow/core/common_runtime/bfc_allocator.cc:654] 6 Chunks of size 512 totalling 3.0KiB
2018-09-27 22:58:41.992196: I tensorflow/core/common_runtime/bfc_allocator.cc:654] 1 Chunks of size 768 totalling 768B
2018-09-27 22:58:41.992202: I tensorflow/core/common_runtime/bfc_allocator.cc:654] 2 Chunks of size 1024 totalling 2.0KiB
2018-09-27 22:58:41.992208: I tensorflow/core/common_runtime/bfc_allocator.cc:654] 1 Chunks of size 1280 totalling 1.2KiB
2018-09-27 22:58:41.992213: I tensorflow/core/common_runtime/bfc_allocator.cc:654] 3 Chunks of size 2048 totalling 6.0KiB
2018-09-27 22:58:41.992219: I tensorflow/core/common_runtime/bfc_allocator.cc:654] 1 Chunks of size 2304 totalling 2.2KiB
2018-09-27 22:58:41.992225: I tensorflow/core/common_runtime/bfc_allocator.cc:654] 2 Chunks of size 4096 totalling 8.0KiB
2018-09-27 22:58:41.992231: I tensorflow/core/common_runtime/bfc_allocator.cc:654] 3 Chunks of size 8192 totalling 24.0KiB
2018-09-27 22:58:41.992238: I tensorflow/core/common_runtime/bfc_allocator.cc:654] 2 Chunks of size 12288 totalling 24.0KiB
2018-09-27 22:58:41.992244: I tensorflow/core/common_runtime/bfc_allocator.cc:654] 1 Chunks of size 32768 totalling 32.0KiB
2018-09-27 22:58:41.992250: I tensorflow/core/common_runtime/bfc_allocator.cc:654] 2 Chunks of size 65536 totalling 128.0KiB
2018-09-27 22:58:41.992256: I tensorflow/core/common_runtime/bfc_allocator.cc:654] 1 Chunks of size 81920 totalling 80.0KiB
2018-09-27 22:58:41.992262: I tensorflow/core/common_runtime/bfc_allocator.cc:654] 1 Chunks of size 92160 totalling 90.0KiB
2018-09-27 22:58:41.992268: I tensorflow/core/common_runtime/bfc_allocator.cc:654] 1 Chunks of size 200192 totalling 195.5KiB
2018-09-27 22:58:41.992274: I tensorflow/core/common_runtime/bfc_allocator.cc:654] 1 Chunks of size 301056 totalling 294.0KiB
2018-09-27 22:58:41.992280: I tensorflow/core/common_runtime/bfc_allocator.cc:654] 1 Chunks of size 308736 totalling 301.5KiB
2018-09-27 22:58:41.992286: I tensorflow/core/common_runtime/bfc_allocator.cc:654] 2 Chunks of size 458752 totalling 896.0KiB
2018-09-27 22:58:41.992292: I tensorflow/core/common_runtime/bfc_allocator.cc:654] 1 Chunks of size 2048000 totalling 1.95MiB
2018-09-27 22:58:41.992298: I tensorflow/core/common_runtime/bfc_allocator.cc:654] 1 Chunks of size 4194304 totalling 4.00MiB
2018-09-27 22:58:41.992304: I tensorflow/core/common_runtime/bfc_allocator.cc:654] 4 Chunks of size 8388608 totalling 32.00MiB
2018-09-27 22:58:41.992310: I tensorflow/core/common_runtime/bfc_allocator.cc:654] 4 Chunks of size 16777216 totalling 64.00MiB
2018-09-27 22:58:41.992316: I tensorflow/core/common_runtime/bfc_allocator.cc:654] 1 Chunks of size 43827200 totalling 41.80MiB
2018-09-27 22:58:41.992322: I tensorflow/core/common_runtime/bfc_allocator.cc:654] 4 Chunks of size 67108864 totalling 256.00MiB
2018-09-27 22:58:41.992328: I tensorflow/core/common_runtime/bfc_allocator.cc:654] 1 Chunks of size 645136384 totalling 615.25MiB
2018-09-27 22:58:41.992333: I tensorflow/core/common_runtime/bfc_allocator.cc:654] 1 Chunks of size<PHONE_NUMBER> totalling 1.17GiB
2018-09-27 22:58:41.992339: I tensorflow/core/common_runtime/bfc_allocator.cc:654] 1 Chunks of size<PHONE_NUMBER> totalling 2.30GiB
2018-09-27 22:58:41.992345: I tensorflow/core/common_runtime/bfc_allocator.cc:658] Sum Total of in-use chunks: 4.47GiB
2018-09-27 22:58:41.992352: I tensorflow/core/common_runtime/bfc_allocator.cc:660] Stats:
Limit:<PHONE_NUMBER>
InUse:<PHONE_NUMBER>
MaxInUse:<PHONE_NUMBER>
NumAllocs:                   54412
MaxAllocSize:<PHONE_NUMBER>

2018-09-27 22:58:41.992366: W tensorflow/core/common_runtime/bfc_allocator.cc:275] ******_______********_____________*******************************************_______________________
2018-09-27 22:58:41.992384: W tensorflow/core/framework/op_kernel.cc:1273] OP_REQUIRES failed at conv_ops.cc:693 : Resource exhausted: OOM when allocating tensor with shape[128,1024,107,44] and type float on /job:localhost/replica:0/task:0/device:GPU:0 by allocator GPU_0_bfc

Thanks for posting with the full log!
It is failing while trying to allocate 2.30GiB memory that is not available in any of the following three chunks (from the log) because of the fragmentation.
Size: 615.25MiB | Requested Size: 225.70MiB | in_use: 0, prev:   Size: 41.80MiB | Requested Size: 41.80MiB | in_use: 1, next:   Size: 615.25MiB | Requested Size: 615.25MiB | in_use: 1
Size: 1.17GiB | Requested Size: 1.17GiB | in_use: 0, prev:   Size: 615.25MiB | Requested Size: 615.25MiB | in_use: 1, next:   Size: 1.17GiB | Requested Size: 1.17GiB | in_use: 1
Size: 1.90GiB | Requested Size: 2.0KiB | in_use: 0, prev:   Size: 2.30GiB | Requested Size: 2.30GiB | in_use: 1
Consider reducing size of the network and/or batch size so that it does not allocate very large tensors. If you still run into issues or need further advice, try Stack Overflow for further help and support.


ZXingScannerView does not stretch for UWP in Xamarin.Forms

I use ZXingScannerView in a Xamarin.Forms application. I test it with Android API 21+ and Windows Mobile 10. While in Android the camera stream expands to the boundaries of the scanner view perfectly, this is not true for UWP. No matter that the emulator size or resolution. I"ve also tried with a real windows phone device and the issue still appears.
I place the ZXingScannerView in a content page similar to this:
<ContentPage.Content>
	<StackLayout Spacing="20" Padding="15">
		...
		<Grid
			HorizontalOptions="FillAndExpand"
			VerticalOptions="FillAndExpand">
			<zxing:ZXingScannerView
				x:Name="zxing"
				Result="{Binding ScannerResult, Mode=TwoWay}"
				IsScanning="{Binding ScannerScanning}"
				IsVisible="{Binding ScannerVisible}"
				IsAnalyzing="{Binding ScannerAnalyzing}"
				ScanResultCommand="{Binding ScannedCommand}"/>
			<v:MainPageZXingOverlayView />
		</Grid>
		...
	</StackLayout>
</ContentPage.Content>

Also I've noticed that the view .xaml has a capture element set to Stretch="Fill"
 <CaptureElement
	Grid.Row="0"
	Grid.Column="0"
	x:Name="captureElement"
	Stretch="Fill" />

also in view .cs
// *after* the preview is setup, set this so that the UI layout happens
// otherwise the preview gets stuck in a funny place on screen
captureElement.Stretch = Stretch.UniformToFill;

Anyone experiencing the same problem or have a fix for it?
My original question / bug confirmation was posted on Stack Overflow

Thanks for reporting this issue!  Unforunately it took me way too long to respond 😭.  Sorry, I apologize!  Recently the source code for this project was completely refactored to modernize it.  Many PR's were included in this effort, and many bugs were hopefully fixed.  Please try out the latest 3.x series of NuGet packages (currently in prerelease).  To try and make the project more maintainable in my spare time going forward, I've decided to close all existing issues to start with a clean slate.  If you're still experiencing this issue on the newest version, please open a new issue with as much detail as possible.  Thank you for your patience and understanding!  Happy scanning!


Add SOCKS5 and SOCKS5H schemes

Description of changes:
Added schemes required for proxying connections to socks5 and socks5h (with host resolution) with CURL library.
Proxifying your connections to AWS is a very common requirement when using AWS SDK. unfortunately, since the default client only accepts http and https schemas, we cannot use socks5 and socks5h proxies that are already supported by curl. socks5h is especially useful in my case since I'm running my WebAssembly application on Google Chrome, and the only way to connect to AWS servers with WebAssembly is by proxifying the requests to a SOCKS proxy AND doing the DNS resolution on the proxy itself.
I could create a new client and use the overriding function but I found it too much of a hassle to create a new client and implement the overriding method and then setting as a default client configuration just so that I can add the schema.
Check all that applies:

[X] Did a review by yourself.
[ ] Added proper tests to cover this PR. (If tests are not applicable, explain.)
Not applicable: it doesn't add anything functional. It just enables prepending socks5 and socks5h to the host name
[ ] Checked if this PR is a breaking (APIs have been changed) change.
[ ] Checked if this PR will not introduce cross-platform inconsistent behavior.
[ ] Checked if this PR would require a ReadMe/Wiki update.

Check which platforms you have built SDK on to verify the correctness of this PR.

[X] Linux
[X] Windows
[X] Android
[X] MacOS
[X] IOS
[X] Other Platforms
WebAssembly

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Will this be merged any time in the future?

Hi @ahmedyarub,
We are evaluating the impact of this change to those not using CURL as httpclient.
BTW, if you don't mind to share, what environment/parameters are you using to build websassembly?
Best,
Damian

Hi @ahmedyarub,
We are evaluating the impact of this change to those not using CURL as httpclient.
BTW, if you don't mind to share, what environment/parameters are you using to build websassembly?
Best,
Damian

I made this contribution to vcpkg to fix building using Emscripten: https://github.com/microsoft/vcpkg/pull/17348
Before that I used to build like this:
zlib:
emcmake cmake -DBUILD_SHARED_LIBS=FALSE -DBUILD_SHARED_LIBS=FALSE -DCMAKE_INSTALL_PREFIX=/usr/local/wasm32 ~/Documents/cpp/zlib

Build OpenSSL:
git checkout OpenSSL_1_1_1-stable
emconfigure ./config threads no-engine no-dso no-asm no-shared no-sse2 no-srtp --prefix="/usr/local/wasm32" --openssldir="/usr/local/wasm32" --cross-compile-prefix="/"

emmake make install_sw -j4

Build curl:
emcmake cmake -DBUILD_CURL_EXE=FALSE -DHAVE_SELECT=0 -DHAVE_POLL=1 -DHAVE_POLL_FINE=1 -DHAVE_POLL_H=1 -DHAVE_SIGACTION=0 -DENABLE_DEBUG=TRUE -DCMAKE_BUILD_TYPE=Debug -DBUILD_SHARED_LIBS=FALSE -DCMAKE_PREFIX_PATH=/usr/local/wasm32 -DCMAKE_FIND_ROOT_PATH=/usr/local/wasm32 -DCMAKE_INSTALL_PREFIX=/usr/local/wasm32 ~/Documents/cpp/curl

Build AWS SDK:
emcmake cmake -DBUILD_ONLY="core;ec2;ecr" -DENABLE_TESTING=FALSE -DENABLE_UNITY_BUILD=ON -DAWS_DEPS_INSTALL_DIR=/usr/local/wasm32 -DGEN_PLATFORM_ARG="-DCMAKE_PREFIX_PATH=/usr/local/wasm32 -DCMAKE_FIND_ROOT_PATH=/usr/local/wasm32" -DBUILD_SHARED_LIBS=FALSE -DCMAKE_PREFIX_PATH=/usr/local/wasm32 -DCMAKE_FIND_ROOT_PATH=/usr/local/wasm32 -DCMAKE_INSTALL_PREFIX=/usr/local/wasm32 ~/Documents/cpp/aws-sdk-cpp

nano .deps/build/src/AwsCEventStream-build/CMakeCache.txt
aws-c-common_DIR:PATH=/usr/local/wasm32/lib/aws-c-common/cmake/
aws-checksums_DIR:PATH=/usr/local/wasm32/lib/aws-checksums/cmake/

emcmake cmake -DCMAKE_PREFIX_PATH=/usr/local/wasm32 -DCMAKE_FIND_ROOT_PATH=/usr/local/wasm32 -DBUILD_SHARED_LIBS=FALSE -DCMAKE_FIND_ROOT_PATH="~/Qt/5.15.1/wasm_32;/usr/local/wasm32/" -Wno-dev

emmake make
emmake make install

Hi @ahmedyarub,
Do you happen to have a container with proxy SOCKS5 setup and an integration test to check things work as expected?

Hi @ahmedyarub,
Do you happen to have a container with proxy SOCKS5 setup and an integration test to check things work as expected?

I did test it on my machine and it worked. However, I can create a container and an integration test for you in the next few days.

Hi @ahmedyarub,
Do you happen to have a container with proxy SOCKS5 setup and an integration test to check things work as expected?

I did test it on my machine and it worked. However, I can create a container and an integration test for you in the next few days.

@sdavtaker test added with Dockerfile and instructions.

Thanks @ahmedyarub for the contribution
We will review in the next few days.


Quoted Identifiers in Column Names

Hi! If  I use of quoted identifiers in the names of table columns,  then return [].
CREATE TABLE IF NOT EXISTS shema.table
(
    field_1        BIGINT,
    `partition`   STRING,
);

@lapter57  hi, yes, right now supported form only with "" quotes & without, I will add support for `

@lapter57 https://github.com/xnuinside/simple-ddl-parser/pull/56/files released, test added, version 0.19.2 with fix https://pypi.org/project/simple-ddl-parser/


Demo sidebar is not scrollable

In your demo, no scrollbar appears when the expanded item list extends past the current visible area. I haven't dug enough to see if this is particular to the demo or an issue with the component being used itself.

I have released a fixed version of the docs. The issue was with the docs itself, not the component.


Expose dx & dy in NodePositionChange in ReactFlow

Please describe the feature that you want to propose
Feature: expose dx & dy (change in x position coordinate & change in y position coordinate) in NodePositionChange event in ReactFlow. EDIT: for this use case, interested in positionAbsolute.dx & positionAbsolute.dy specifically
Motivation: When xyflow is used with multiplayer technology, when moving a node, sending movement intent (i.e. changes, like dx & dy) is recommended over sending final positions. This allows for dealing with cases where two people attempt to move the same node.
While in some straightforward cases it is possible to reverse engineer dx & dy. In others (for example, when using scale factors that are separate from xyflow zoom level) it becomes problematic as scale factor multiplication starts to significantly distort dx & dy reconstruction beyond certain scales.
Even without scales, I am doing calculations to reconstruct dx & dy, where I'd rather not since xyflow already must have done it in order to generate NodePositionChange.

Thanks for the idea! We will check, if it's possible to send the delta along with the other changes.

@tristanls Thanks for your patience — we have been quite preoccupied with getting v12 out the door and fixing up loose ends.
Currently, you can easily determine deltas by calculating differences between the current position or size of the InternalNode and the NodePositionChange or NodeDimensionChange. Here a small sandbox showing the rough idea.
Adding deltas on library side would add unwarranted complexity, due to the way we internally track and modify these changes.
Your concerns around scaling (I assume you mean adding some transform: scale to nodes) are justified, as RF does not support it. Internally, we do not correct for any additional transforms. It probably still works because we use measured node dimensions to make any calculations. But note that this breaks apart the moment you add some kind of scaling to the node with an origin besides [0, 0]. I recommend leaving positioning and sizing in the hands of React Flow.
I will close this for now. Don't hesitate to continue the discussion or reopen the issue if any problems persist.

Hi @peterkogo.
I will give reconstructing dx & dy using InternalNode a try. As long as this gives me back the user's input and remains available, it should be sufficient.
I'm confused by the sandbox example as I don't see it using getInternalNode() in the code.

@tristanls ah dang, codesandbox didn't save my changes. Will update it in a second.

Sorry having some issue with codesandbox. Try this link here.

@peterkogo, the sandbox at the latest link is a good summary, I appreciate it.


Add non_essential_load3 to the grid

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
This function is not available
Expected behaviour
Please add non_essential_load3: to the grid. I know there is limited space on the card, but I think it would work :)
Thanks in advance for your great work and patience with annoying users like me.
For information on how load3 would look on the card, see screenshot.
Possible Solutions

Mode
full
Context / Reason
The possibility of using more home appliances and having a better overview of energy.

Let me think about it 😄

This will be a tight fit if you a or using all the card option

I use a different style of battery layout than yours. It works very well for me.

Its because you dont define this entity switch.sunsynk_toggle_system_timer. I also need to think about all the other users of the card. It will only work if there is a conditional check to only show the 3rd load if this is false.

I understand. Unfortunately, I didn't realize that.
The only option is to move the cells to the right a little.

I figured out how to do this. Will push in the next release. It will only display the 3rd load if you are not using the inverter timer schedules.

I don't use the inverter timer, I solve it with node red.
Thank you very much.


[#12] - Download quotes for Offline view

Minor changes to styling and started working on downloading the quotes

Closes [#12 ]


package.json dependencies

@nfarina:
Is there a reason, why you've defined a commit-ish suffix for the hap-nodejs dependency?
The default is Master and should install the latest version.

When HAP-nodeJS changes, Nick wants to make sure that homebridge is capable of the changes. So he adds each tested commit point.

@snowdd1: This is a reason, otherwise I've seen users getting troubles, because the homebridge package.json wasn't updated and the "old" HAP-NodeJS was installed instead of the new one.

If HAP-NodeJS were in npm with semver, then we could automatically get bug fixes by requiring "^1.3.x" or similar - but since it's a git dependency, we don't know when it may change in a way that breaks homebridge. So we need to pin it to the last specific version that is "verified good".

I've read about publishing on npm, it seems to be easy. Let see what the future will bring.

@KhaosT is there a reason why it's not?


New remark and rehype plugin explainer with extends

What kind of changes does this PR include?

New or updated content

Description
We have a new way to preserver Astro's default remark plugins when you apply your own: extends! https://github.com/withastro/astro/pull/4474.
This PR addresses a couple concerns:

Add short explainers on remark and rehype based on the MDX docs. New markdown users probably don't know what these plugins can do or where to find a list of popular options (I definitely didn't a month ago). This should make plugins easier to understand.
Move tip on Astro's defaults to in-line explainer
Replace remark-autolink-headings example with remark-toc. Autolink headings is the one plugin we shouldn't recommend, since it conflicts with Astro's own heading ID plugin 😅
Add new code examples with and without extends

LGTM, Ben!

Good job @bholmesdev, LGTM!


Release procedure: fix paths for docker-build-deb.sh and docker-build-rpm.sh

Motivation
While preparing the release for Pulsar 2.7.2 I had a problem executing docker-build-rpm.sh and docker-build-deb.sh  on MacOS.
It looks like the reference to the Pulsar main directory is wrong and we are mounting the wrong directory while launching docker.
 includes invalid characters for a local volume name, only "[a-zA-Z0-9][a-zA-Z0-9_.-]" are allowed. If you intended to pass a host directory, use absolute path.

@lhotari thanks for your quick feedback, I have updated the patch.


ONNXHybridTransformPass

Includes a new pattern-based shape inference implementation.
So far only combines shape inference and canonicalization but the plan is to include constant propagation and decomposition so that a single pass with all the patterns can cascade shape inference and all the transforms in a single pass.
I encountered a model with a long dependency chain between shape inference, canonicalization, and constant propagation which requires an incredible number of repetitive passes with the current pass infrastructure.
See PR #1770 for an earlier version of this PR.

If I enable the new pass, by changing the --onnx-hybrid-pass flag default to true, then these lit tests fail:
Failed Tests (8):
  Open Neural Network Frontend :: onnx/onnx_bundle_memory_pool.mlir
  Open Neural Network Frontend :: onnx/onnx_lowering.mlir
  Open Neural Network Frontend :: onnx/onnx_lowering_O3.mlir
  Open Neural Network Frontend :: onnx/onnx_lowering_range_op.mlir
  Open Neural Network Frontend :: onnx/onnx_lowering_with_canonicalize.mlir
  Open Neural Network Frontend :: onnx/onnx_lowering_with_canonicalize_O3.mlir
  Open Neural Network Frontend :: onnx/onnx_seq_dealloc.mlir
  Open Neural Network Frontend :: onnx/onnx_shape_inference.mlir

I haven't looked into them yet.

We can progressively increase the patterns in the hybrid pass. It might be too much to add all the patterns at once.
Need help on If/Loop/Scan?
What's the failure for lit test, compilation error or match error?

Need help on If/Loop/Scan?
What's the failure for lit test, compilation error or match error?

it's mostly match errors
there's a crash in @test_loop_simple_one_scan_main_graph in onnx_shape_inference.mlir,
it crashes because we attempt to cast an unranked tensor type tensor<*xi64> to RankedTensorType in Loop.cpp:
https://github.com/onnx/onnx-mlir/blob/main/src/Dialect/ONNX/ONNXOps/ControlFlow/Loop.cpp#L84
maybe it's because I left out the fixes to ONNXScanOp::inferShapes() and ONNXLoopOp::inferShapes() from PR #1770 when I rebased
your help would be appreciated if you can checkout my branch and run the lit tests with the default value of the enableONNXHybridPass flag set to true in CompilerOptions.cpp

I should probably also try to port the fixes to lit tests from PR #1770, it looks like some of the same lit tests are the same as I fixed back then

Comments on the control flow Ops. I will use LoopOp as an example.
There are three part of the inferShape function:

Set the type of body arguments with the initial value
Use parameter  function pointer on the body region. Originally, the function will traverse the body and call inferShape for each Op.
Set type for the returned values

In hybrid transformation:

when loop is encountered, inferShape is called with a function pointer doing nothing. So we actually perform step#1 and step#3. The step#3 is not needed yet.
When return of the loop is encountered, inferShape for its LoopOp is called with a function pointer doing nothing. In this step, what we really want is just step#3.

After you fixed the unranked tensor issue, such flow with unnecessary work is OK.
I am thinking whether we can get rid of the unnecessary work by separating out the code into entering and leaving the node. In hybrid transformation, we pass a Null function pointer. So the code for loop looks like:
ONNXLoopOp::JoinEdges() {
      // set type when control flow join
}

ONNXLoopOp::InferShape(doShapeInference) {
     // set the entry type
    if (doShapeInference != nullptr) {
        doShapeInference(insideRegion); // traverse and infer shape for the region
        joinEdges();
     }
}

For the ReturnOp:
if (it is the return for a LoopOp, loop) {
    loop.JoinEdge();
}

In hybrid transformation, always call : inferShape(nullptr)

We can merge this PR without such changes. I just want to check with you whether my understanding of the flow is correct.

We can merge this PR without such changes. I just want to check with you whether my understanding of the flow is correct.

Yes, this is correct.
I'd be very interested in making the type of improvements you suggest as a follow-up.

@jenkins-droid test this please

@gongsu832 can you tell why MLIR-Windows-CI is failing? https://github.com/onnx/onnx-mlir/pull/2098/checks?check_run_id=12765970850

You can click on the "Details" -> "1 errors / 0 warnings" -> "Build_onnx_mlir_Windows" and you can see the error.
2023-04-15T00:52:03.8473519Z ##[section]Starting: Test onnx-mlir
2023-04-15T00:52:04.1222663Z ==============================================================================
2023-04-15T00:52:04.1223031Z Task         : Command line
2023-04-15T00:52:04.1223182Z Description  : Run a command line script using Bash on Linux and macOS and cmd.exe on Windows
2023-04-15T00:52:04.1223473Z Version      : 2.212.0
2023-04-15T00:52:04.1223618Z Author       : Microsoft Corporation
2023-04-15T00:52:04.1223797Z Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/utility/command-line
2023-04-15T00:52:04.1224106Z ==============================================================================
2023-04-15T00:52:07.2654004Z Generating script.
2023-04-15T00:52:07.3125315Z ========================== Starting Command Output ===========================
2023-04-15T00:52:07.3440286Z ##[command]"C:\Windows\system32\cmd.exe" /D /E:ON /V:OFF /S /C "CALL "D:\a\_temp\3c94cc30-c84c-4a26-987d-d36cccbc85ba.cmd""
2023-04-15T00:52:08.0166916Z **********************************************************************
2023-04-15T00:52:08.0168365Z ** Visual Studio 2019 Developer Command Prompt v16.11.25
2023-04-15T00:52:08.0169042Z ** Copyright (c) 2021 Microsoft Corporation
2023-04-15T00:52:08.0170136Z **********************************************************************
2023-04-15T00:52:09.4024705Z [vcvarsall.bat] Environment initialized for: 'x64'
2023-04-15T00:52:11.9495939Z lit: C:\hostedtoolcache\windows\Python\3.9.13\x64\lib\site-packages\lit\llvm\config.py:46: note: using lit tools: C:\Program Files\Git\usr\bin
2023-04-15T00:52:13.3561772Z -- Testing: 205 tests, 4 workers --
2023-04-15T00:52:17.4210420Z Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.
2023-04-15T00:52:17.4238521Z FAIL: Open Neural Network Frontend :: krnl/krnl_getref_lowering.mlir (138 of 205)
2023-04-15T00:52:17.4240399Z ******************** TEST 'Open Neural Network Frontend :: krnl/krnl_getref_lowering.mlir' FAILED ********************
2023-04-15T00:52:17.4248321Z Script:
2023-04-15T00:52:17.4251530Z --
2023-04-15T00:52:17.4253805Z : 'RUN: at line 1';   d:\a\1\onnx-mlir\build\release\bin\onnx-mlir-opt.exe -O3 --convert-krnl-to-affine --convert-krnl-to-llvm D:\a\1\onnx-mlir\test\mlir\krnl\krnl_getref_lowering.mlir -split-input-file | d:\a\1\llvm-project\build\bin\filecheck.exe D:\a\1\onnx-mlir\test\mlir\krnl\krnl_getref_lowering.mlir
2023-04-15T00:52:17.4255401Z --
2023-04-15T00:52:17.4256204Z Exit Code: 2
2023-04-15T00:52:17.4256642Z
2023-04-15T00:52:17.4257285Z Command Output (stdout):
2023-04-15T00:52:17.4257602Z --
2023-04-15T00:52:17.4257896Z $ ":" "RUN: at line 1"
2023-04-15T00:52:17.4259020Z $ "d:\a\1\onnx-mlir\build\release\bin\onnx-mlir-opt.exe" "-O3" "--convert-krnl-to-affine" "--convert-krnl-to-llvm" "D:\a\1\onnx-mlir\test\mlir\krnl\krnl_getref_lowering.mlir" "-split-input-file"
2023-04-15T00:52:17.4260221Z note: command had no output on stdout or stderr
2023-04-15T00:52:17.4261140Z error: command failed with exit status:<PHONE_NUMBER>
2023-04-15T00:52:17.4262373Z $ "d:\a\1\llvm-project\build\bin\filecheck.exe" "D:\a\1\onnx-mlir\test\mlir\krnl\krnl_getref_lowering.mlir"
2023-04-15T00:52:17.4263252Z # command stderr:
2023-04-15T00:52:17.4264126Z FileCheck error: '<stdin>' is empty.
2023-04-15T00:52:17.4265222Z FileCheck command line:  d:\a\1\llvm-project\build\bin\filecheck.exe D:\a\1\onnx-mlir\test\mlir\krnl\krnl_getref_lowering.mlir
2023-04-15T00:52:17.4265806Z
2023-04-15T00:52:17.4266463Z error: command failed with exit status: 2
2023-04-15T00:52:17.4266666Z
2023-04-15T00:52:17.4266919Z --
2023-04-15T00:52:17.4267013Z
2023-04-15T00:52:21.7567643Z ********************
2023-04-15T00:52:21.7568179Z Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
2023-04-15T00:52:21.7593153Z ********************
2023-04-15T00:52:21.7593957Z Failed Tests (1):
2023-04-15T00:52:21.7594649Z   Open Neural Network Frontend :: krnl/krnl_getref_lowering.mlir
2023-04-15T00:52:21.7595304Z
2023-04-15T00:52:21.7595483Z
2023-04-15T00:52:21.7595925Z Testing Time: 9.70s
2023-04-15T00:52:21.7598372Z   Unsupported:  72
2023-04-15T00:52:21.7598869Z   Passed     : 132
2023-04-15T00:52:21.7599320Z   Failed     :   1
2023-04-15T00:52:21.7813231Z [1/6] cmd.exe /C "cd /D D:\a\1\onnx-mlir\build\src\Runtime\jni && "C:\Program Files\CMake\bin\cmake.exe" -E copy_if_different D:/a/1/onnx-mlir/build/src/Runtime/jni/jsoniter/maven/jsoniter-0.9.23.jar D:/a/1/onnx-mlir/build/src/Runtime/jni/jsoniter/jsoniter-0.9.23.jar"
2023-04-15T00:52:21.7814113Z [2/3] Running utility command for javaruntime
2023-04-15T00:52:21.7814696Z [2/3] Running the ONNX-MLIR regression tests
2023-04-15T00:52:21.7815188Z FAILED: test/mlir/CMakeFiles/check-onnx-lit D:/a/1/onnx-mlir/build/test/mlir/CMakeFiles/check-onnx-lit
2023-04-15T00:52:21.7815986Z cmd.exe /C "cd /D D:\a\1\onnx-mlir\build\test\mlir && C:\hostedtoolcache\windows\Python\3.9.13\x64\python3.exe C:/hostedtoolcache/windows/Python/3.9.13/x64/Scripts/lit.exe -sv D:/a/1/onnx-mlir/build/test/mlir"
2023-04-15T00:52:21.7816661Z ninja: build stopped: subcommand failed.
2023-04-15T00:52:21.8737588Z ##[error]Cmd.exe exited with code '1'.
2023-04-15T00:52:21.9156787Z ##[section]Finishing: Test onnx-mlir

@gongsu832 thanks for the explanation, but what confuses me is that I cannot pinpoint the problem from reading the contents of the log - can you tell what the cause of the failure is?

@sorenlassen I pretty much know nothing about lit tests. But from the error message:
2023-04-15T00:52:17.4259020Z $ "d:\a\1\onnx-mlir\build\release\bin\onnx-mlir-opt.exe" "-O3" "--convert-krnl-to-affine" "--convert-krnl-to-llvm" "D:\a\1\onnx-mlir\test\mlir\krnl\krnl_getref_lowering.mlir" "-split-input-file"
2023-04-15T00:52:17.4260221Z note: command had no output on stdout or stderr
2023-04-15T00:52:17.4261140Z error: command failed with exit status:<PHONE_NUMBER>

The onnx-mlir-opt.exe failed so it didn't produce anything on stdout, which is supposed to be piped into filecheck.exe:
2023-04-15T00:52:17.4262373Z $ "d:\a\1\llvm-project\build\bin\filecheck.exe" "D:\a\1\onnx-mlir\test\mlir\krnl\krnl_getref_lowering.mlir"
2023-04-15T00:52:17.4263252Z # command stderr:
2023-04-15T00:52:17.4264126Z FileCheck error: '<stdin>' is empty.

So filecheck.exe failed. I have no idea why the onnx-mlir-opt.exe failed. Perhaps one of the Microsoft folks can help?

@jenkins-droid test this please

Jenkins Linux s390x Build #10707 [push] ONNXHybridTransformPass ... started at 10:08

Jenkins Linux amd64 Build #10697 [push] ONNXHybridTransformPass ... started at 09:08

Jenkins Linux ppc64le Build #9755 [push] ONNXHybridTransformPass ... started at 10:11

@gongsu832 thank you for looking into this. I never figured it out but I retried the MLIR-Windows-CI once more and it finally succeeded, so it appears to have been a temporary problem of some sort. (It had failed the same way 2 or 3 times when I reported the problem.)

Jenkins Linux amd64 Build #10697 [push] ONNXHybridTransformPass ... passed after 1 hr 16 min

Jenkins Linux s390x Build #10707 [push] ONNXHybridTransformPass ... passed after 1 hr 24 min

Jenkins Linux ppc64le Build #9755 [push] ONNXHybridTransformPass ... passed after 2 hr 5 min


key_user_actions configuration drift on terraform apply

Hi,
In our organization we use Key User Actions (part of dynatrace_web_application resource) a lot. We also try to utilize IaC approach and keep configuration up to date and consistent across the environments and products.
The problem is, no matter if key_user_actions block has been changed or not, terraform will always show a change in configuration.
Here is an output of a regular terraform apply with unchanged key_user_actions resource
 # module.dynatrace-web-application-adm.dynatrace_web_application.dynatrace_web_application will be updated in-place
  ~ resource "dynatrace_web_application" "dynatrace_web_application" {
        id                                   = "APPLICATION-1D4F63F413835AB6"
        name                                 = "qa-qa5-am-adm"
        # (5 unchanged attributes hidden)

      ~ key_user_actions {
          ~ action {
              ~ name   = "load bonus packages page" -> "load messaging page"
                # (2 unchanged attributes hidden)
            }
          ~ action {
              ~ name   = "load discover page" -> "load conversation page"
                # (2 unchanged attributes hidden)
            }
          ~ action {
              ~ name   = "load messaging page" -> "load bonus packages page"
                # (2 unchanged attributes hidden)
            }
          ~ action {
              ~ name   = "load conversation page" -> "load discover page"
                # (2 unchanged attributes hidden)
            }
        }

Not seeing the actual drift makes our daily tasks more complicated and we would appreciate a fix or improvement with this. Thank you.

Hello @ruslanakchurin, with the upcoming release of the provider the key user actions will be treated as an unordered list. That will take care of the drift issue. Thanks for the hint!