Microsoft Teams "Hello World" Bot is not working - Library.Exceptions.PermissionDeniedException

Hi,
Thank you for a detailed example of hello world bot for Microsoft Teams in C#. Since I'm new to Bot development, I tried following the tutorial to the details, but unfortunately, I got stuck with my server returning "500: Internal Server Error".
Initially, I tried to test my app against Microsoft Bot Emulator and it worked wonderfully.

After that, I tried to change my server-side MicrosoftAppID to a wrong one intentionally, and I got "401: Unauthorized" error message instead, so I guess the authentication has no problem.
Digging in, I tried to add a break point and recovered the following stack trace:
Exception thrown: 'Microsoft.Bot.Connector.ErrorResponseException' in mscorlib.dll
Microsoft.Bot.Connector.ErrorResponseException: Operation returned an invalid status code 'Forbidden'
   at Microsoft.Bot.Connector.Conversations.<ReplyToActivityWithHttpMessagesAsync>d__10.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Bot.Connector.ConversationsExtensions.<ReplyToActivityAsync>d__11.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Polly.Policy.<>c__DisplayClass241_0`1.<<ExecuteAsyncInternal>b__0>d.MoveNext() in C:\projects\polly\src\Polly.Shared\Policy.Async.cs:line 0
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Polly.RetrySyntaxAsync.<>c__DisplayClass21_1.<<WaitAndRetryAsync>b__1>d.MoveNext() in C:\projects\polly\src\Polly.Shared\Retry\RetrySyntaxAsync.cs:line 467
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Polly.Retry.RetryEngine.<ImplementationAsync>d__1`1.MoveNext() in C:\projects\polly\src\Polly.Shared\Retry\RetryEngineAsync.cs:line 33
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Polly.Retry.RetryEngine.<ImplementationAsync>d__1`1.MoveNext() in C:\projects\polly\src\Polly.Shared\Retry\RetryEngineAsync.cs:line 54
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Polly.Policy.<ExecuteAsyncInternal>d__241`1.MoveNext() in C:\projects\polly\src\Polly.Shared\Policy.Async.cs:line 61
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Bot.Connector.RetryHelpers.<ExecuteWithRetries>d__13`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Bot.Connector.RetryHelpers.<ReplyToActivityWithRetriesAsync>d__8.MoveNext()

Do you have any idea / suggestion to what is wrong here?
Thank you!

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

ID: 98cd21c7-e87c-3c5b-7574-998a355f9f08
Version Independent ID: 5e312707-facc-03fc-af59-90267d0c7b8a
Content: Get started with C#/.NET - Teams
Content Source: msteams-platform/get-started/get-started-dotnet-app-studio.md
Product: msteams
GitHub Login: @o365devx
Microsoft Alias: o365devx

@freedomofkeima - Could you please share your bot id? Also, are you trying this in 1:1 scope? Could you please send the sceenshot of Teams chat as well?

Hi,
Thanks for your reply.
My bot ID is 8b230f18-b004-4a76-9a60-505fe6dc5526.

Also, are you trying this in 1:1 scope?

If I understand the question correctly, I tried it via both direct Chat and Teams, both gave back similar result.

The /api/messages 202 Accepted came from Bot Framework Emulator while all 500 came from Microsoft Teams. It occurred either when I used @botname and when I clicked on the card menu.
Thank you.

I tried your bot and it's working fine for me in 1:1 scope as well as Team scope.

We are looking into this issue.

Thanks.
I'm not sure if this is helpful, but the differences between reply to the emulator & Teams:
Emulator
ChannelId: "emulator"
Locale: ""
ReplyToId: "110e9c30-40b1-11e9-949c-297d75a33724"
ServiceUrl: "http://localhost:64283"
Timestamp: {3/7/2019 8:14:45 AM +00:00}

Teams:
ChannelId: "msteams"
Locale: "en-US"
ReplyToId: "1551946622307"
ServiceUrl: "https://smba.trafficmanager.net/apac/"
Timestamp: {3/7/2019 8:17:09 AM +00:00}

I have an update and this issue gets more strange. I tried it with other test tenant (dev.hdetrial.jp, now it works) and without breakpoints, it runs normally except the trace looks strange.

It seems the server still throws Microsoft.Bot.Connector.ErrorResponseException: Operation returned an invalid status code 'Forbidden' but there's an auto-retry and it always works on the second attempt.
Digging in, I modified the sample code into:
try {
    await connector.Conversations.ReplyToActivityWithRetriesAsync(reply);
} catch (ErrorResponseException e) {
    Debug.WriteLine(e.ToString());
}

Now, as we can expect, all of the statuses have changed to 202 Accepted.

The strange bit is, only half of my messages got through.

Sorry for the another post. Today, I investigated the issue further and rewrote the REST API with Go.
The problem that I encountered is exactly the same as yesterday. Now I understand where the Forbidden message comes from, the error message is:
Status Code: 403
Body: {"error":{"code":"BadArgument","message":"Exception of type 'Library.Exceptions.PermissionDeniedException' was thrown."}}

Request Information:
Token URL: https://login.microsoftonline.com/botframework.com/oauth2/v2.0/token
Bot Scope: "https://api.botframework.com/.default"
Bot Client ID: "8b230f18-b004-4a76-9a60-505fe6dc5526"

From the first post, where failure is 100% (always failed):
Tenant Name: nobitatest.onmicrosoft.com
Tenant ID: 55d4406a-3b48-4a52-9306-c9d172befc66
Teams Channel ID for GET members operation<EMAIL_ADDRESS>

From the second post, where 500 is always followed with 200 (50% success rate):
Tenant Name: dev.hdetrial.jp
Tenant ID: 56a8632d-6c92-432a-988a-7f1a4f71b61e
Teams Channel ID for GET members operation<EMAIL_ADDRESS>

IP address (The IP address is always the same throughout all operations):
login.microsoftonline.com <-> <IP_ADDRESS>:443
smba.trafficmanager.net <-> <IP_ADDRESS>:443

@freedomofkeima - This seems to be an issue with Tenant configuration with regards to sideloaded apps. We are working on this.

@freedomofkeima - Could you please try again and check if you getting any "Library.Exceptions.PermissionDeniedException" exceptions?

I am unsure if this is the exact same issue, but we have started getting this "Library.Exceptions.PermissionDeniedException" within the last few hours, and I cannot find much about it outside of this post. We are also using a sideloaded app, and everything worked as expected up through yesterday.
 [onTurnError]: Error: Exception of type 'Library.Exceptions.PermissionDeniedException' was thrown.
BotFrameworkAdapter.processActivity(): 500 ERROR - Error: Exception of type 'Library.Exceptions.PermissionDeniedException' was thrown.

About half of the messages or cards that our sideloaded app sends will fail, but trying again immediately after with the same content works.
Trying to echo "a" in a 1-on-1 scope (with the id's snipped out):
{ text: 'a', textFormat: 'plain', type: 'message',
timestamp: 2019-03-12T16:16:07.109Z,
localTimestamp: 2019-03-12T16:16:07.109Z,
id: '', channelId: 'msteams', serviceUrl: '',
from: { (user) conversation: { (convo) },
recipient: { (bot) },
entities:  [ { locale: 'en-US', country: 'US', platform: 'Windows', type: 'clientInfo' } ],
channelData: { (tenant) }, locale: 'en-US' }

  [onTurnError]: Error: Exception of type 'Library.Exceptions.PermissionDeniedException' was thrown.

# success immediately after
{ text: 'a', textFormat: 'plain', type: 'message',
timestamp: 2019-03-12T16:16:10.924Z,
localTimestamp: 2019-03-12T16:16:10.924Z,

The same is true when running a command and returning a card:
{ text: '<at>mention</at> get site domain.com\n', textFormat: 'plain', attachments: [(text), type: 'message',
timestamp: 2019-03-12T15:53:53.320Z,
localTimestamp: 2019-03-12T15:53:53.320Z,
(snip)

{ contentType: 'application/vnd.microsoft.card.adaptive',
  content:
    { type: 'AdaptiveCard',
      body: [ [Object], [Object], [Object] ],
      '$schema': 'https://adaptivecards.io/schemas/adaptive-card.json',
      version: '1.0' } }

 [onTurnError]: Error: Exception of type 'Library.Exceptions.PermissionDeniedException' was thrown.

# success immediately after
{ text: '<at>mention</at> get site domain.com\n', textFormat: 'plain', attachments: [(text), type: 'message',
timestamp: 2019-03-12T15:54:21.709Z,
localTimestamp: 2019-03-12T15:54:21.709Z,

@snlnspc this was a bug that we recently fixed. Does it still happen for you?

@billbliss Yes, this only started happening to me today, and just failed again ~20 seconds ago with the same error
[onTurnError]: Error: Exception of type 'Library.Exceptions.PermissionDeniedException' was thrown.
BotFrameworkAdapter.processActivity(): 500 ERROR - Error: Exception of type 'Library.Exceptions.PermissionDeniedException' was thrown.

@snlnspc - what's your Bot ID?

@billbliss thanks much for looking into this!
28:5984914a-448e-4166-84f9-2b765c6d8243

@billbliss I just started getting this error today (about a couple hours before this post). My bot ID is a9124452-301b-4fe1-a43e-cec44f46be52. Everything was working perfectly fine this morning and now I get the response:
{ error:
      { code: 'BadArgument',
        message:
         'Exception of type \'Library.Exceptions.PermissionDeniedException\' was thrown.' } } }

We're using v3 of the bot SDK (node)

Hi, we have the same issue (library.exception.permissiondeniedexception) with team channel with the bot id 816c00fa-4eb3-402a-b68f-3a1bfb7864e1 for a couple of days now.
Only way to make it work is to reboot it and it will work for 2 minutes maximum.
Any ideas of what we can do?

Same issue with me getting exception
Exception of type 'Library.Exceptions.PermissionDeniedException' was thrown.
My Bot id is
f2726326-bfeb-48fd-8cee-641b79f0e431

Hi, we have the same issue (library.exception.permissiondeniedexception) with team channel with the bot id 816c00fa-4eb3-402a-b68f-3a1bfb7864e1 for a couple of days now.
Only way to make it work is to reboot it and it will work for 2 minutes maximum.
Any ideas of what we can do?

I was able to work around by locally adding the app to Company catalogue and disabling site loading of external apps at tenant level

Now the issue is also happening for locally added apps to catalog store since today morning ! This does appear to intermittently going up and down, not sure how can it be avoided ?

As an update: from wednesday morning on, I was getting PermissionDeniedException on 100% of messages, but since (at least) yesterday, I seem to be back to all successes

As an update: from wednesday morning on, I was getting PermissionDeniedException on 100% of messages, but since (at least) yesterday, I seem to be back to all successes

Same here it started working again. I am concerned here on part where if it goes down again ?

We are working on fix for this issue. We will update this post once it is fixed.

I also started getting such errors after deploying the bot into a different Teams tenant.
    at new RestError (D:\home\site\wwwroot\node_modules\@azure\ms-rest-js\dist\msRest.node.js:1397:28)
    at D:\home\site\wwwroot\node_modules\@azure\ms-rest-js\dist\msRest.node.js:1849:37
    at <anonymous>
    at process._tickDomainCallback (internal/process/next_tick.js:228:7)
  code: 'BadArgument',
  statusCode: 403,
  request:
   WebResource {
     streamResponseBody: false,
     url: 'https://smba.trafficmanager.net/amer/v3/conversations/a%3A1oE0cbn7Oy7jYfU6y9ktTcP4Dh97Kzgff1EtosyedysCj9AZsoankWtS2Dkl4OtgiDH47YeidAc6FqGlxq8IBDIMWbUvCaFgIhcMrfjqUEMaBCHn1TOu3RPG--dHyiNsl/activities/1553086591817',
     method: 'POST',
     headers: HttpHeaders { _headersMap: [Object] },
     body: '{"type":"message","serviceUrl":"https://smba.trafficmanager.net/amer/","channelId":"msteams","from": ...}',
     query: undefined,
     formData: undefined,
     withCredentials: false,
     abortSignal: undefined,
     timeout: 0,
     onUploadProgress: undefined,
     onDownloadProgress: undefined,
     operationSpec:
      { httpMethod: 'POST',
        path: 'v3/conversations/{conversationId}/activities/{activityId}',
        urlParameters: [Array],
        requestBody: [Object],
        responses: [Object],
        serializer: [Object] } },
  response:
   { body: '{"error":{"code":"BadArgument","message":"Exception of type \'Library.Exceptions.PermissionDeniedException\' was thrown."}}',
     headers: HttpHeaders { _headersMap: [Object] },
     status: 403 },
  body:
   { error:
      { code: 'BadArgument',
        message: 'Exception of type \'Library.Exceptions.PermissionDeniedException\' was thrown.' } } }```

Is there a way I could get more details about the context of this underlying Library.Exceptions.PermissionDeniedException exception ? I would like to know for which reason exactly this exception has been thrown. Thx!

I'm seeing this issue as well. It appears to be intermittent. Our bot is deployed across about 150 tenants and for some it works the majority of the time, and for others, it has never worked.
We receive the Library.Exceptions.PermissionDeniedException.
We're not using any special frameworks, just POSTing or PUTing to the serviceUrl endpoint.

Update: Yesterday the problem disappeared. The bot is fully working now! It seems the problem occurs just after a new deployment and can remain for hours before it automatically resolves by itself. I also confim it appears to be intermittent. Thx.

I have the same issue:
3/22/2019, 3:29:47 PM | Exception of type 'Library.Exceptions.PermissionDeniedException' was thrown.
On two tenants it works and on the third (production) it doesn't.
Any help would be appreciated.
Thanks
Chris

Hi team, I developed with Visual Studio and didn't receive any error message , just is not working for Tab and Bot.
Bot ID:1c8f6c3a-1169-43a7-b50f-21074cbe5f97
can you please take a look for my app ,thanks !

@XimenaWang - Is it hitting your /api/messages endpoint locally? Could you please raise separate issue  as this is not related to PermissionDeniedException?

I have the same issue:
3/22/2019, 3:29:47 PM | Exception of type 'Library.Exceptions.PermissionDeniedException' was thrown.
On two tenants it works and on the third (production) it doesn't.
Any help would be appreciated.
Thanks
Chris

It works now on my tenant.

This issue has been fixed. Could you please confirm if you are still getting this error?

@Wajeed-msft I am also seeing this problem (same exception) with couple of my Bots.

@Srinath-Sadda - Could you please share you bot Id and timestamp when you got this exception?

Never mind. After clearing OAuth connection details (sign out) for all of our Bot users, our Bot users were able to communicate wit Bot fine without any permission denied errors.

I'm having this exception when trying to reply using botframeworkbot "Exception of type 'Library.Exceptions.PermissionDeniedException' was thrown." Any idea?

Did you try signing out and signing back in as discussed above?
If so, and it didn't work, then please provide the bot ID and timestamp when you got this exception.

4/26/2019, 9:49:33 PM 8fca8dbb-7c91-4668-b328-ea42ae7d270d

Please re-open if anyone is still facing this issue.

This morning I start getting this error again. Is there something that has changed recently ?

@Wajeed-msft This morning I start getting this error again. Is there something that has changed recently ?

Hi all, I have same issue with my bot. Here ist the ID: f61caa7d-ba35-4215-a946-36e4d3e982c1.
Thanks.

After ca. 10 hours it starts to work. So just wait a while.

@ralphsche You are right. Mine also restarted to work but after a couple of days. @Wajeed-msft Do you have an explanation why this problem occurs intermittently ? Thx!

@Wajeed-msft Hi same issue here today. BotId 4cd3c92d-7dbf-4cb4-b9b8-7c2949c891c8


GH-1083: Disallow reuse bean name for bindings

Resolves spring-cloud/spring-cloud-stream#1083
By default Spring Framework allows beans overriding via the same name.
The binding target definitions (@Input and @Output) populate beans as well
and when we use the same name for target we end up with unexpected behavior
but without errors.
Since it isn't so obvious via Spring Framework bean definition DSLs
(XML or Java & Annotations) how to override beans with the same name,
that is absolutely easy to use the same value for @Input and @Output
definitions even in different binding interfaces.
That's hard to analyze fro the target application since mostly
@Input and @Output produce MessageChannel beans.

Fail fast with the BeanDefinitionStoreException when we meet existing
bean definition for the same name
Add JavaDocs to the @Input and @Output to explain that their value
is a bean name, as well as destination by default

Since @EnableBinding is @Inherited, the inheritor picks up it from the
super class during configuration class parsing.
The parsing process logic is such that after the root class we go to parse its
super classes, and therefore come back to the @EnableBinding again.
In this case we process all the @Imports one more time and collect them to
the root configurationClass.
Essentially we get a duplication for the ImportBeanDefinitionRegistrars
such as BindingBeansRegistrar.
The last one parsed @EnableBinding and registers appropriate beans for the
@Input and @Output, as well as for the binding interface - BindableProxyFactory.
But since we have it twice in the configurationClass we end up with
BeanDefinitionStoreException mentioned before.
That's how Spring Framework works with inheritance for configuration classes
and that's may be why it allows to override beans by default

Skip parsing @EnableBinding one more time if the bean definition for
binding interface is already present in the registry
Fix AggregateWithMainTest do not process @ComponentScan what causes
picking up the configuration classes for children contexts in the aggregation
Fix testBindableProxyFactoryCaching() do not register Source and Processor
in the same application context because both of them cause registration for the
Source.OUTPUT bean

Codecov Report

Merging #1084 into master will increase coverage by 0.02%.
The diff coverage is 87.5%.

@@             Coverage Diff              @@
##             master    #1084      +/-   ##
============================================
+ Coverage     51.46%   51.48%   +0.02%
- Complexity      705      706       +1
============================================
  Files           134      134
  Lines          4001     4005       +4
  Branches        540      541       +1
============================================
+ Hits           2059     2062       +3
  Misses         1786     1786
- Partials        156      157       +1

Impacted Files
Coverage Δ
Complexity Δ

...am/binding/BindingBeanDefinitionRegistryUtils.java
85.36% <100%> (+1.15%)
8 <2> (+1)
:arrow_up:

...ork/cloud/stream/config/BindingBeansRegistrar.java
92.3% <80%> (-7.7%)
4 <0> (ø)

Continue to review full report at Codecov.

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

LGTM - merged.


ja: Make docs/concepts/overview/working-with-objects/kubernetes-objects.md follow v1.19 of the original text

This is a Feature Request

What would you like to be added
Update docs/concepts/overview/working-with-objects/kubernetes-objects.md to follow v1.19 of the original (English) text.
Why is this needed
content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md is outdated.
Comments
/language ja
/good-first-issue
File to update
https://github.com/kubernetes/website/tree/dev-1.19-ja.1/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md
Original
https://github.com/kubernetes/website/tree/release-1.19/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
diff between translated and v1.19
https://gist.github.com/b02064fe97a59deabedf3a47732a47b8
Note
Currently, we use dev-1.19-ja.1 branch. Please open a PR targeting the branch.
ref
https://kubernetes.io/ja/docs/contribute/localization/
If you have a question, feel free to ask us at slack.k8s.io #kubernetes-docs-ja channel.

/triage accepted

/assign

/close


Failed to install binary-<IP_ADDRESS>: Cannot parse #if directive

Trying to compile https://github.com/simonmichael/hledger/tree/master/hledger-lib with eta, using gradle
build.gradle
buildscript {
  repositories {
    mavenLocal()

    dependencies {
      classpath 'com.typelead:gradle-eta:0.0.1-SNAPSHOT'
    }
  }
}

apply plugin: 'eta'

eta {
    etlasVersion = '<IP_ADDRESS>'
}

And got:
Found patch in eta-hackage for binary-<IP_ADDRESS>
Configuring binary-<IP_ADDRESS>...
Building data-default-instances-containers-0.0.1...
Building mtl-2.2.1...
Building pretty-show-1.6.15...
Building binary-<IP_ADDRESS>...
Failed to install binary-<IP_ADDRESS>
Build log ( $PROJECTS/hledger/hledger-lib/.cabal-sandbox/logs/eta-<IP_ADDRESS>/binary-<IP_ADDRESS>-XCulyUW0jLDfM8QjWWONO.log ):
etlas: Entering directory '/tmp/etlas-tmp-20990/binary-<IP_ADDRESS>'
Configuring binary-<IP_ADDRESS>...
Preprocessing library for binary-<IP_ADDRESS>..
Building library for binary-<IP_ADDRESS>..
eta: panic! (the 'impossible' happened)
  (Eta version 0.0.9b6):
	Cannot parse #if directive in file src/Data/Binary/Get/Internal.hs  at line 64 col 1:
    end of input

Please report this as a Eta bug: http://github.com/typelead/eta/issues

I have no idea what's happening, just following the instructions. :P
Trying to compile hledger-lib to use it in an android project for something, got this far and got stuck. I thought a patch is missing and may be needed, but no, a patch exists. What's happening here? What can I try now?

Sorry about that, there's a mistake in the patch that only gets executed on the older versions of Eta. I fixed the patch. Start the project from scratch and try again.

binary compiles fine, but there are other dependencies that still need patching. Should I open patch requests on eta-hackage? I can try to write the patches myself but will probably need some initial handholding.

Sure, go ahead. I'm closing this issue since it's solved.


Constant rebuilds if used as a crates.io dependency

I was playing around with using this crate, and found that if I had it set up as a crates.io dependency, i.e, my dependency was on version = "^0.14.1", it would rebuild rusoto every time I did a cargo build. It appears that the codegen subdirectory isn't present in the released code, and so when cargo sees that directory is missing, it decides that rusoto is not fresh and rebuilds it.
Switching to having a local checkout of the code and using it as a path dependency, i.e, path = ../rusoto appears to work correctly.

If I had to guess, I'd say this was introduced in https://github.com/rusoto/rusoto/pull/270.

Yeah, it was introduced in #270.  I just noticed this over the weekend myself.
#270 has the desired effect if you're developing and building rusoto itself, or have a local dependency on rusoto, but causes it to recompile every time as described above if you're using rusoto as a crates.io dependency due to the rerun-if-changed=codegen pointing to a codegen directory that doesn't exist in that case.

I think the easiest fix would be to only output the rerun-if-changed directive at all if the codegen directory exists.  I'll test that out and get a fix in.

@ahwatts - v1.15.1 was just published to crates.io with a fix for this.

Thanks!


show the count of selected lines in code editor

Hello
is it possible to show the count of selected lines in code editor [ New Feature ]

I would like to work on it


OSX DNS flush to cover El Capitan

Updated the readme to cover OSX El Capitan for flushing DNS

Heya @StevenBlack ,
Thank you. Just did the pull request on readme_template.md . I will close this one. :+1:


Ensure /health API returns 204 No Content for "OK" responses

As documented in #1405, the API is returning "204 No Response" instead of the
commonly accepted "204 No Content", which is also the documented behavior. This
change fixes the implementation and adds a test for the expected response
reason.
Closes #1405

If there's any value in asserting the same http_reason expectation on all other 204s I can add that as well.

:+1:

@cwjohnston I am surprised that anyone cared about a status string :-)

I'm glad someone's keeping us honest :)

@cwjohnston looks great, merging!


<IP_ADDRESS> is not compatible with IntelliJ 2018.1 on Linux

I have update IntelliJ to 2018.1 on my Ubuntu desktop. Then I found BashSupport does not work any more. Since I use snap to install IntelliJ, I remove it and clean all the configuration folders. I use JetBrains Toolbox App to install IntelliJ 2018.1. This time I can not BashSupport in Browse JetBrains Plugins dialog.
Version <IP_ADDRESS> works on IntelliJ 2018.1 on Windows 10 64bits.

@liaoya BashSupport is not available as Jetbrains Plugins, you have to choose "Browser Plugins...". If it's still not working, then please reopen this issue.


Creating a non-ssl listener seems impossible

Related:
We're trying to run a az network application-gateway http-listener create command
az network application-gateway http-listener create --help tells us that --ssl-cert is not required.
But when we try and create one without an ssl certificate specified, we get the following:
Resource ...sslCertificates/None referenced by resource ...httpListeners/listener02 was not found. Please make sure that the referenced resource exists, and that both resources are in the same region.
There doesn't seem to be way to specify http instead of https when creating the listener.

Hi @bewatts, the reason you can't set the protocol directly is because the CLI automatically sets the protocol based on whether or not you specified an SSL cert. Which commands did you run prior?

Nevermind--I have confirmed this is a bug.

@bewatts the fix has been merged in. Please try again. Thanks for reporting this!


[UI] the error message should be cleared after close dialog.

Close inline alert.

close it as fixed.


Ortho projection fails at south pole in pcolormesh

I am plotting gridded satellite data using basemap 1.0.7 (I can't get 1.0.8 via pip yet).  The grid is 0.25 degrees resolution, global coverage.
For polar views, I use pcolormesh.  It works fine for the north polar view:
    bmap = Basemap(projection='ortho', lat_0=90, lon_0=270, resolution='c')
    show_map = bmap.pcolormesh(lons, lats, darray, vmin=vminval, vmax=vmaxval,
                               norm=norm, cmap=this_cmap, alpha=1.0, latlon=True)

but the corresponding map centered on the south pole plots garbage:
    bmap = Basemap(projection='ortho', lat_0=-90, lon_0=270, resolution='c')
    show_map = bmap.pcolormesh(lons, lats, darray, vmin=vminval, vmax=vmaxval,
                               norm=norm, cmap=this_cmap, alpha=1.0, latlon=True)

However, pcolor plots correctly at the south pole.  This one is fine:
    bmap = Basemap(projection='ortho', lat_0=-90, lon_0=270, resolution='c')
    show_map = bmap.pcolor(lons, lats, darray, vmin=vminval, vmax=vmaxval,
                               norm=norm, cmap=this_cmap, alpha=1.0, latlon=True)

In this case, my gridded data array is pretty small and the time difference between pcolormesh and pcolor is negligible, but I'm guessing this is something that ought to be fixed, unless it already has been addressed in 1.0.8.

Thanks @awarnock3.
Any chance you could provide a SSCCE example which allows us to see the problem without needing to have access to your data (i.e. use np.arange to produce coordinates)? That should speed up development time, as well as allowing us to suggest potential problems with your approach / potential options beyond pcolor.
Appreciate the time you've taken to raise this despite you having a workaround. Thanks again!

Probably. Let me see what I can come up with.
As a matter of fact, I do speak for my iPad.

On Oct 2, 2015, at 3:52 AM, Phil Elson<EMAIL_ADDRESS>wrote:
Thanks @awarnock3.
Any chance you could provide a SSCCE example which allows us to see the problem without needing to have access to your data (i.e. use np.arange to produce coordinates)? That should speed up development time, as well as allowing us to suggest potential problems with your approach / potential options beyond pcolor.
Appreciate the time you've taken to raise this despite you having a workaround. Thanks again!
—
Reply to this email directly or view it on GitHub.

Here's one I threw together, along with example plots showing how
pcolor() does the right thing at -90 but pcolormesh does not.
Thanks!
On 10/2/15 3:52 AM, Phil Elson wrote:

Thanks @awarnock3 https://github.com/awarnock3.
Any chance you could provide a SSCCE example which allows us to see the
problem without needing to have access to your data (i.e. use np.arange
to produce coordinates)? That should speed up development time, as well
as allowing us to suggest potential problems with your approach /
potential options beyond pcolor.
Appreciate the time you've taken to raise this despite you having a
workaround. Thanks again!
—
Reply to this email directly or view it on GitHub
https://github.com/matplotlib/basemap/issues/207#issuecomment-144948647.

--
Archie
-- Archie Warnock<EMAIL_ADDRESS>-- A/WWW Enterprises                          www.awcubed.com
--       As a matter of fact, I do speak for my employer.

I forgot to include the dependencies that generated the example.
basemap==1.0.7
matplotlib==1.4.3
numpy==1.9.3
On 10/2/15 3:52 AM, Phil Elson wrote:

Thanks @awarnock3 https://github.com/awarnock3.
Any chance you could provide a SSCCE example which allows us to see the
problem without needing to have access to your data (i.e. use np.arange
to produce coordinates)? That should speed up development time, as well
as allowing us to suggest potential problems with your approach /
potential options beyond pcolor.
Appreciate the time you've taken to raise this despite you having a
workaround. Thanks again!
—
Reply to this email directly or view it on GitHub
https://github.com/matplotlib/basemap/issues/207#issuecomment-144948647.

--
Archie
-- Archie Warnock<EMAIL_ADDRESS>-- A/WWW Enterprises                          www.awcubed.com
--       As a matter of fact, I do speak for my employer.

Hi @awarnock3:
I am curious what happens  if you convert lats and lons to the projection coordinates yourself and plot without latlon=True ?
Thanks

Same thing.  That was actually my first iteration.  My naive guess is
that whatever offset is done internally to avoid the singularity at the
south pole isn't quite right.  It works if you center at +90 but not at -90.
Additionally, simply changing "pcolormesh" to "pcolor" also fixes the
issue.  In my case, the grid size isn't too large and the performance
isn't much different but I'll have other cases where the resolution is
higher and the images will be much larger.
On 10/3/15 10:27 AM, Huziy Oleksandr (Sasha) wrote:

Hi @awarnock3 https://github.com/awarnock3:
I am curious what happens if you convert lats and lons to the projection
coordinates yourself and plot without latlon=True ?
Thanks
—
Reply to this email directly or view it on GitHub
https://github.com/matplotlib/basemap/issues/207#issuecomment-145253259.

--
Archie
-- Archie Warnock<EMAIL_ADDRESS>-- A/WWW Enterprises                          www.awcubed.com
--       As a matter of fact, I do speak for my employer.

@awarnock3 Have you sent your example somewhere? I would like to play with it.
Cheers

Here you go.  I've attached the example code and sample outputs.
On 10/4/15 1:07 PM, Huziy Oleksandr (Sasha) wrote:

@awarnock3 https://github.com/awarnock3 Have you sent your example
somewhere? I would like to play with it.
Cheers
—
Reply to this email directly or view it on GitHub
https://github.com/matplotlib/basemap/issues/207#issuecomment-145366902.

--
Archie
-- Archie Warnock<EMAIL_ADDRESS>-- A/WWW Enterprises                          www.awcubed.com
--       As a matter of fact, I do speak for my employer.

Sorry @awarnock3, but I am still not able to lacate the script(s)...

Sorry - it appears that my attachments didn't get through.  Here's the sample code and two images.

from mpl_toolkits.basemap import Basemap
import numpy as np
import matplotlib.pyplot as plt

def meshtest(darray):
    """This demonstrates the bug in pcolormesh.
    Define bmap with lat_0 = +90 and both plots are the same.  Define it
    with lat_0 = -90 and pcolor creates the expected result but pcolormesh
    does not.
    """
    plt.gcf()
    dpi = 100
    x_pixels = 360
    y_pixels = 180

    fig_x_inches = x_pixels / float(dpi)
    fig_y_inches = y_pixels / float(dpi)

    # Create the default figure at the right dimensions
    fig = plt.figure(figsize=(fig_x_inches, fig_y_inches), dpi=dpi)

    bmap = Basemap(projection='ortho', lat_0=-90, lon_0=-90, resolution='c')
    this_cmap = plt.get_cmap('PiYG')
    lon_array = np.arange(-180., 180., 1.)
    lat_array = np.arange(-90, 90., 1.)

    lons, lats = np.meshgrid(lon_array, lat_array)
    bmap.pcolormesh(lons, lats, darray, vmin=1.0, vmax=14.0, cmap=this_cmap,
                    alpha=1.0, latlon=True)
    fig.savefig('pcolormesh.png', dpi=dpi, transparent=1.0)

    bmap.pcolor(lons, lats, darray, vmin=1.0, vmax=14.0, cmap=this_cmap,
                alpha=1.0, latlon=True)
    fig.savefig('pcolor.png', dpi=dpi, transparent=1.0)

    plt.clf()  # clear the plot in case anything is cached
    plt.close('all')

    return

def make_data():
    """Make a highly colorful 2D image.  I'm sure there's a more pythonic
    way to do this but it works."""
    nrows = 180
    ncols = 360
    square_size = 20
    square_len = square_size**2
    nsquares = (nrows * ncols) / square_len
    darray = np.zeros((nrows, ncols))

    for square in range(nsquares):
        k = np.random.randint(16)
        nrow = square_size * int((square_size * square) / nrows)
        ncol = (square_size * square) % nrows
        darray[ncol:ncol + square_size, nrow:nrow + square_size] = k
    return darray

def main():
    darray = make_data()
    meshtest(darray)
    return

if __name__ == '__main__':
    main()

Which version of matplotlib?
On Wed, Oct 7, 2015 at 6:33 AM, Archie Warnock<EMAIL_ADDRESS>wrote:

Sorry - it appears that my attachments didn't get through. Here's the
sample code and two images.
[image: pcolor]
https://cloud.githubusercontent.com/assets/6179594/10335072/a49ad210-6cbc-11e5-84a6-9205a1b19bb0.png
[image: pcolormesh]
https://cloud.githubusercontent.com/assets/6179594/10335073/a4a0187e-6cbc-11e5-9a61-fe4e6cd71b1d.png
from mpl_toolkits.basemap import Basemap
import numpy as np
import matplotlib.pyplot as plt
def meshtest(darray):
"""This demonstrates the bug in pcolormesh.
Define bmap with lat_0 = +90 and both plots are the same.  Define it
with lat_0 = -90 and pcolor creates the expected result but pcolormesh
does not.
"""
plt.gcf()
dpi = 100
x_pixels = 360
y_pixels = 180
fig_x_inches = x_pixels / float(dpi)
fig_y_inches = y_pixels / float(dpi)

# Create the default figure at the right dimensions
fig = plt.figure(figsize=(fig_x_inches, fig_y_inches), dpi=dpi)

bmap = Basemap(projection='ortho', lat_0=-90, lon_0=-90, resolution='c')
this_cmap = plt.get_cmap('PiYG')
lon_array = np.arange(-180., 180., 1.)
lat_array = np.arange(-90, 90., 1.)

lons, lats = np.meshgrid(lon_array, lat_array)
bmap.pcolormesh(lons, lats, darray, vmin=1.0, vmax=14.0, cmap=this_cmap,
                alpha=1.0, latlon=True)
fig.savefig('pcolormesh.png', dpi=dpi, transparent=1.0)

bmap.pcolor(lons, lats, darray, vmin=1.0, vmax=14.0, cmap=this_cmap,
            alpha=1.0, latlon=True)
fig.savefig('pcolor.png', dpi=dpi, transparent=1.0)

plt.clf()  # clear the plot in case anything is cached
plt.close('all')

return

def make_data():
"""Make a highly colorful 2D image.  I'm sure there's a more pythonic
way to do this but it works."""
nrows = 180
ncols = 360
square_size = 20
square_len = square_size**2
nsquares = (nrows * ncols) / square_len
darray = np.zeros((nrows, ncols))
for square in range(nsquares):
    k = np.random.randint(16)
    nrow = square_size * int((square_size * square) / nrows)
    ncol = (square_size * square) % nrows
    darray[ncol:ncol + square_size, nrow:nrow + square_size] = k
return darray

def main():
darray = make_data()
meshtest(darray)
return
if name == 'main':
main()
—
Reply to this email directly or view it on GitHub
https://github.com/matplotlib/basemap/issues/207#issuecomment-146147578.

Matplotlib 1.4.3
Basemap 1.0.7
Numpy 1.9.3
As a matter of fact, I do speak for my iPhone.

On Oct 7, 2015, at 9:27 AM, Benjamin Root<EMAIL_ADDRESS>wrote:
Which version of matplotlib?
On Wed, Oct 7, 2015 at 6:33 AM, Archie Warnock<EMAIL_ADDRESS>wrote:

Sorry - it appears that my attachments didn't get through. Here's the
sample code and two images.
[image: pcolor]
https://cloud.githubusercontent.com/assets/6179594/10335072/a49ad210-6cbc-11e5-84a6-9205a1b19bb0.png
[image: pcolormesh]
https://cloud.githubusercontent.com/assets/6179594/10335073/a4a0187e-6cbc-11e5-9a61-fe4e6cd71b1d.png
from mpl_toolkits.basemap import Basemap
import numpy as np
import matplotlib.pyplot as plt
def meshtest(darray):
"""This demonstrates the bug in pcolormesh.
Define bmap with lat_0 = +90 and both plots are the same. Define it
with lat_0 = -90 and pcolor creates the expected result but pcolormesh
does not.
"""
plt.gcf()
dpi = 100
x_pixels = 360
y_pixels = 180
fig_x_inches = x_pixels / float(dpi)
fig_y_inches = y_pixels / float(dpi)
Create the default figure at the right dimensions
fig = plt.figure(figsize=(fig_x_inches, fig_y_inches), dpi=dpi)
bmap = Basemap(projection='ortho', lat_0=-90, lon_0=-90, resolution='c')
this_cmap = plt.get_cmap('PiYG')
lon_array = np.arange(-180., 180., 1.)
lat_array = np.arange(-90, 90., 1.)
lons, lats = np.meshgrid(lon_array, lat_array)
bmap.pcolormesh(lons, lats, darray, vmin=1.0, vmax=14.0, cmap=this_cmap,
alpha=1.0, latlon=True)
fig.savefig('pcolormesh.png', dpi=dpi, transparent=1.0)
bmap.pcolor(lons, lats, darray, vmin=1.0, vmax=14.0, cmap=this_cmap,
alpha=1.0, latlon=True)
fig.savefig('pcolor.png', dpi=dpi, transparent=1.0)
plt.clf() # clear the plot in case anything is cached
plt.close('all')
return
def make_data():
"""Make a highly colorful 2D image. I'm sure there's a more pythonic
way to do this but it works."""
nrows = 180
ncols = 360
square_size = 20
square_len = square_size**2
nsquares = (nrows * ncols) / square_len
darray = np.zeros((nrows, ncols))
for square in range(nsquares):
k = np.random.randint(16)
nrow = square_size * int((square_size * square) / nrows)
ncol = (square_size * square) % nrows
darray[ncol:ncol + square_size, nrow:nrow + square_size] = k
return darray
def main():
darray = make_data()
meshtest(darray)
return
if name == 'main':
main()
—
Reply to this email directly or view it on GitHub
https://github.com/matplotlib/basemap/issues/207#issuecomment-146147578.

—
Reply to this email directly or view it on GitHub.


Implement alarm feature

Discussion about ChromeExtensionService
I didn't extract functions e.g. chrome.tabs.create, chrome.notifications.clear, and chrome.notifications.clearto ChromeExtensionService because I didn't add any new code/callback to them.
I assume the reason why only chrome.tabs.create is separated in ChromeExtensionService is, the callback window.close() is added. If the intention is to close popup.html after creating a new tab, then it's done without this callback function. I think we can remove ChromeExtensionService all together and directly use Chrome APIs. Using raw Chrome API is much more intuitive than using wrapping functions. What do you think?

I see clear needs for this feature from the community. I'll adapt the code to the latest code and re-send pull request.


doc: add link to glob::glob::Pattern

I was confused by the double-asterisk syntax in the glob. I figured it couldn't hurt to unobtrusively document what the format is.

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

@bors: r+ rollup

:pushpin: Commit ca6d379 has been approved by steveklabnik

:hourglass: Testing commit ca6d379 with merge 78f4080...

:sunny: Test successful - cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-gnu-32, cargo-win-gnu-64


Use include-hidden-files: true to upload coverage artifacts

Version v4.4.0 of actions/upload-artifact broke uploading (silently) and combining coverage files.

Wow great find, thank you! Would you mind doing this for Hatch? 😄

Sure!


clBuildProgram segv

The following change that only does code refectoring of the GROMACS OpenCL kernels causes the OpenCL compiler to crash:
https://gerrit.gromacs.org/#/c/7810/19/src/gromacs/mdlib/nbnxn_ocl/nbnxn_ocl_kernel_utils.clh
The culprit has been isolated to the linked changes on line 675-677, the local memory stores that have been moved from the collar into the reduction function in question. If these three lines are commented out, the compilation succeeds.

I am asking the team to look into this.
G

Where can I get the exact source, dependencies, and compilef options needed to reproduce the problem?

The source code is here:
https://gerrit.gromacs.org/changes/7810/revisions/f199e29cc958c00bd1481e710d9abdd0d36ae0f9/archive?format=tbz2
Warning: the review site serves a tar.bz2 which is a tarbomb (no root directory).
Extract, and from the build directory run:
cmake $SOURCE_DIR -DGMX_GPU=ON -DGMX_USE_OPENCL=ON &&\
make mdrun-test &&\
bin/mdrun-test

The mdrun-test unit test will segv as soon as it hits the compilation of the kernel(s) in src/gromacs/mdlib/nbnxn_ocl/nbnxn_ocl_kernel.clh.

As this code in question is about to pass code review and is about to be merged which will prevent me from testing with ROCm, I'd be thankful if you can suggest an easy work-around that I can use until the compiler issue is fixed.

I used ccmake to point precisely at the OpenCL_INCLUDE_DIR and OpenCL_LIBRARY that I want to use, and it tells me " OpenCL is not supported.  OpenCL version 1.2 or newer is required."
Is it true that the INCLUDE_DIR I point to should contain a directory named CL containing cl.h...  and that LIBRARY should be a file named libOpenCL.so?  If so, what else does it want?

Is it true that the INCLUDE_DIR I point to should contain a directory named CL containing cl.h... and that LIBRARY should be a file named libOpenCL.so?

That should be enough. It seems to get rid of the "sticky" error you need by starting over with a clean cache (pass -DOpenCL_INCLUDE_DIR and -DOpenCL_LIBRARY to cmake)

Thanks.  I am able to build and run.
What kind of device are you seeing the problem on?  I am running using a debug build of the tip compiler on gfx803 and it looks like it's going to pass.
What versiion of ROCm are you running?

What kind of device are you seeing the problem on?

gfx803 and gfx900.

I am running using a debug build of the tip compiler on gfx803 and it looks like it's going to pass.

OK, but not sure what does that tell us?
Wouldn't it still be useful to know if you can repro the issue. Is there a 1.8 patch release planned? Otherwise, ETA for 1.9?

What versiion of ROCm are you running?

$ dpkg -l | grep "rocm-"
ii  rocm-clang-ocl                         0.3.0-7997136                              amd64        OpenCL compilation with clang compiler.
ii  rocm-opencl                            1.2.0-2018082755                           amd64        OpenCL/ROCm
ii  rocm-opencl-dev                        1.2.0-2018082755                           amd64        OpenCL/ROCm
ii  rocm-smi                               1.0.0-46-g81ef66f                          amd64        System Management Interface for ROCm
ii  rocm-utils                             1.8.199                                    amd64        Radeon Open Compute (ROCm) Runtime software stack

https://github.com/RadeonOpenCompute/ROCm/issues/404#issuecomment-421399027 says 1.9 will be releasing very soon.  Since the problem is not showing up with the tip compiler, your issue was fixed sometime after 1.8 released.  Hopefully it was picked up in 1.9.

OK, looking forward to seeing the 1.9 not crash, but admittedly I'd be more relieved if somebody confirmed that the release branch is in fact fixed.
(Unrelated, but I'm hoping that 1.8 debs won't get pulled so I can down- and upgrade freely.)

OK, looking forward to seeing the 1.9 not crash, but admittedly I'd be more relieved if somebody confirmed that the release branch is in fact fixed.

Though if 1.9 is indeed dropping today, it won't be a long wait.

After updating the toolchain to ROCm 1.9, I am still getting a clBuildProgram() segfault, so unfortunately  this seems to have fallen through the cracks.
How long until the next patch release?

FWIW, I don't have a spare machine where I can fully install 1.9, but I pointed my LD_LIBRARY_PATH at a release build of the 1.9 OpenCL, HSA, and thunk shared objects and mdrun-test passed for me on gfx803.  It says "1 GPU auto-selected for this run." so I assume it is running on the GPU.

I still see it fail on my ROCm 1.9 system with a Vega (gfx900) and Fiji (gfx803) installed. OpenCL driver version 2679.0, so I believe this is a full 1.9 install.
Currently unable to build a debug release of the OpenCL runtime to get symbols, or I'd point where the issue is coming up for me.

Do you know if it is trying to build programs for both devices?  Maybe the build is faulting when trying to build for vega?

Just putting my commands down here so I don't need to arrow-up every time I want to run this test. :)
mkdir -p ~/gromacs_test/
cd ~/gromacs_test/
wget https://gerrit.gromacs.org/changes/7810/revisions/f199e29cc958c00bd1481e710d9abdd0d36ae0f9/archive?format=tbz2
mv archive\?format\=tbz2 gromacs.tar.bz2
tar -xf gromacs.tar.bz2
SOURCE_DIR=$(pwd)
mkdir build
cd build
cmake $SOURCE_DIR -DGMX_GPU=ON -DGMX_USE_OPENCL=ON -DGMX_BUILD_OWN_FFTW=ON
make -j `nproc` mdrun-test
cd bin
./mdrun-test

Re-tested on ROCm 1.9 on a system with only Polaris 10 (gfx803):
$ rocm_agent_enumerator
gfx000
gfx803

$ dkms status
amdgpu, 1.9-211, 4.15.0-34-generic, x86_64: installed

$ clinfo | grep Driver
  Driver version:                                2679.0 (HSA1.1,LC)

./mdrun-test
...
1 GPU auto-selected for this run.
Mapping of GPU IDs to the 1 GPU task in the 1 rank on this node:
  PP:0

NOTE: Thread affinity was not set.
Segmentation fault (core dumped)

gdb backtrace (no symbols in libamdocl64.so at the moment)
Thread 1 "mdrun-test" received signal SIGSEGV, Segmentation fault.
0x00007fffeead21ed in ?? () from /opt/rocm/opencl/lib/x86_64/libamdocl64.so
(gdb) bt
#0  0x00007fffeead21ed in ?? () from /opt/rocm/opencl/lib/x86_64/libamdocl64.so
#1  0x00007fffeead4b1a in ?? () from /opt/rocm/opencl/lib/x86_64/libamdocl64.so
#2  0x00007fffeebbb1cd in ?? () from /opt/rocm/opencl/lib/x86_64/libamdocl64.so
#3  0x00007fffeead3f35 in ?? () from /opt/rocm/opencl/lib/x86_64/libamdocl64.so
#4  0x00007fffeead61f8 in ?? () from /opt/rocm/opencl/lib/x86_64/libamdocl64.so
#5  0x00007fffeead8a1b in ?? () from /opt/rocm/opencl/lib/x86_64/libamdocl64.so
#6  0x00007fffeead9096 in ?? () from /opt/rocm/opencl/lib/x86_64/libamdocl64.so
#7  0x00007fffeec7b227 in ?? () from /opt/rocm/opencl/lib/x86_64/libamdocl64.so
#8  0x00007fffef5a506a in ?? () from /opt/rocm/opencl/lib/x86_64/libamdocl64.so
#9  0x00007fffef2a29df in ?? () from /opt/rocm/opencl/lib/x86_64/libamdocl64.so
#10 0x00007fffef5a5a7e in ?? () from /opt/rocm/opencl/lib/x86_64/libamdocl64.so
#11 0x00007fffed4fa465 in ?? () from /opt/rocm/opencl/lib/x86_64/libamdocl64.so
#12 0x00007fffed4fc94d in ?? () from /opt/rocm/opencl/lib/x86_64/libamdocl64.so
#13 0x00007fffed4f11ac in ?? () from /opt/rocm/opencl/lib/x86_64/libamdocl64.so
#14 0x00007fffed7f7f3e in ?? () from /opt/rocm/opencl/lib/x86_64/libamdocl64.so
#15 0x00007fffed8051dd in ?? () from /opt/rocm/opencl/lib/x86_64/libamdocl64.so
#16 0x00007fffed4e07da in ?? () from /opt/rocm/opencl/lib/x86_64/libamdocl64.so
#17 0x00007fffed4e9522 in ?? () from /opt/rocm/opencl/lib/x86_64/libamdocl64.so
#18 0x00007fffed4e9938 in ?? () from /opt/rocm/opencl/lib/x86_64/libamdocl64.so
#19 0x00007fffed3b5b0d in ?? () from /opt/rocm/opencl/lib/x86_64/libamdocl64.so
#20 0x00007fffed3e0051 in ?? () from /opt/rocm/opencl/lib/x86_64/libamdocl64.so
#21 0x00007fffed3b3ccf in ?? () from /opt/rocm/opencl/lib/x86_64/libamdocl64.so
#22 0x00007fffed3a5b3e in ?? () from /opt/rocm/opencl/lib/x86_64/libamdocl64.so
#23 0x00007fffed37bcb9 in clBuildProgram () from /opt/rocm/opencl/lib/x86_64/libamdocl64.so
#24 0x00007ffff6fb5714 in gmx::ocl::compileProgram(_IO_FILE*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, _cl_context*, _cl_device_id*, ocl_vendor_id_t) () from /home/jgreatho/gromacs/build/bin/../lib/libgromacs.so.4
#25 0x00007ffff6f5f2bb in nbnxn_gpu_compile_kernels(gmx_nbnxn_ocl_t*) () from /home/jgreatho/gromacs/build/bin/../lib/libgromacs.so.4
#26 0x00007ffff6f5cb8a in nbnxn_gpu_init(gmx_nbnxn_ocl_t**, gmx_device_info_t const*, interaction_const_t const*, NbnxnListParameters const*, nbnxn_atomdata_t const*, int, bool) ()
   from /home/jgreatho/gromacs/build/bin/../lib/libgromacs.so.4
#27 0x00007ffff6e9695c in init_forcerec(_IO_FILE*, gmx::MDLogger const&, t_forcerec*, t_fcdata*, t_inputrec const*, gmx_mtop_t const*, t_commrec const*, float (*) [3], char const*, char const*, gmx::ArrayRef<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const>, gmx_hw_info_t const&, gmx_device_info_t const*, bool, float) () from /home/jgreatho/gromacs/build/bin/../lib/libgromacs.so.4
#28 0x00007ffff6feade7 in gmx::Mdrunner::mdrunner() () from /home/jgreatho/gromacs/build/bin/../lib/libgromacs.so.4
#29 0x00005555555cb9e8 in gmx::Mdrunner::mainFunction(int, char**) ()
#30 0x00005555555cc8ef in gmx_mdrun(int, char**) ()
#31 0x00005555555be6ff in gmx::test::SimulationRunner::callMdrun(gmx::test::CommandLine const&) ()
#32 0x0000555555586a03 in gmx::test::ImdTest_ImdCanRun_Test::TestBody() ()
#33 0x000055555564bdba in void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) ()
#34 0x000055555563e761 in testing::Test::Run() [clone .part.533] ()
#35 0x000055555563f1f5 in testing::TestInfo::Run() [clone .part.534] ()
#36 0x000055555563f535 in testing::TestCase::Run() [clone .part.535] ()
#37 0x0000555555641d35 in testing::internal::UnitTestImpl::RunAllTests() [clone .part.549] ()
#38 0x0000555555642192 in testing::UnitTest::Run() ()
#39 0x0000555555573089 in main ()

Sigh.  I really do not like rpath.  My build of libgromacs.so.4.0.0 has an rpath pointing to the directory containing my internal opencl bits.  I see the segv now after hitting it with "chrpath -d".

So the good news and bad news for @pszi1ard:

Bad news: This bug isn't fixed in the public OpenCL release as of ROCm 1.9.
Good news: as our confusion may have demonstrated, we definitely have this bug fixed internally. So all hope is not lost. :)

I don't think we will be able to to give you a solid timeline for when this will make it into an external release, as we are still working out patches may enter into any bugfix point release in 1.9.x.

Thanks for the feedback @b-sumner and @jlgreathouse.
I appreciate that the planning for 1.9.x is ongoing. Is there a (reasonably straightforward!) way for me to build and replace the rocm-opencl packages so I can keep using ROCm?
Do you happen to have a suggestion for a non-invasive transformation on the code to tickle the compiler and avoid the segv?
Otherwise, the side-effect of putting aside any testing/dev with ROCm right now is that, no GROMACS development and testing can be done for the upcoming 2019 release (change freeze in about a month) on ROCm until fixes land. This poses the risk that our next release will not work at all on ROCm or at least we'l have to keep warning users against using ROCm at worst and untested / un-tuned code at best if a fix comes before the final release later this year.
Side-note:
@b-sumner Indeed gmx  (and libgromacs.so) produced relocatable binaries
  RPATH                $ORIGIN/../lib

but not much more. You can avoid this by passing -DCMAKE_SKIP_RPATH.

The 1.9 compiler was branched on June 21.  The failure being hit is in a "register coalescer" which was  subsequently updated after the branch.  I'm not really sure how to perturb the code to  affect something that deep.  One possibility might be to reduce each component separately instead of all 3 at once.

One possibility might be to reduce each component separately instead of all 3 at once.

Thanks for the tip. Unfortunately it did not work. Strange thing is that if I completely the 2nd, conditional atomic reduction (also concurrent of three values), the crash is gone. However, if I issue both the in-loop and outside-of-loop atomic ops sequentially, I still get the crash. Any other tips? :)
On a different note: Is it a reasonably straightforward thing (and workable idea) to build a rocm-opencl deb package from source and replace the current one? Where would I start -- is the bug fixed in the 1.9 release branch?

Hi @pszi1ard
IMO, it's pretty easy to build a custom install of the OpenCL runtime. See my post in this other issue which includes a shell script that will do basically everything for you. You might have to play around with it to build a .deb package -- to properly cpack the results, for example. You might also want to change the build to Release from ReleaseWithDebInfo.
You could pull the pre- and post-install files out of the existing ROCm OpenCL .deb file if you want to make things slightly easier.

I'll have to defer to @b-sumner about whether this bug is fixed in in the 1.9.0 source code release branch of the open source OpenCL runtime. I believe our original intent was that the source code release would match the source we used to build the .deb releases.
That said, I see that the roc-1.9.x branch of LLVM that the OpenCL build direction pulls from had some patches regarding register allocation brought into it last week. I don't know if this was meant to fix the issue being raised here or not.

It seems like this missed the 1.9.1 too, right? Any plans to release a new rocm-opencl?

There likely won't be a major update to rocm-opencl until ROCm 2.0.

That's very unfortunate. Is there an approx ETA for ROCm 2.0?

I apologize for the long delay on this. I believe the bugfix is part of a larger series of changes in the compiler. We didn't want to bring new functionality into a 1.9.x point release, but it also would have been difficult to cherry pick this individual fix back into the 1.9.x code base.
I believe that our target is for 2.0 to be out by the end of the year, but i'm not sure if AMD has made a public announcement on an official exact date.

We are getting close to our final release and at the moment 1.9 is still not working. I've seen some links to 2.0 beta rpms floating around on the Internet, but I'm not aware of a deb repo. Have your internal testing covered my bog report? Do you have 2.0 beta debs available?
With the latest 1.9.x, additionall to the previous 100% reproducible segv, I also see a clBuildProgram segv in ~0.1-0.2% of the compilations when building mostly (only?) when building clFFT. Do you know of such issues?

Hi @pszi1ard
Do you have a preferred contact mechanism? I can send you a link to our 2.0 beta repos, but I would prefer not to post it publicly.

Email<EMAIL_ADDRESS>debs would be much appreciated. Also a rough timeline if possible (even if under NDA, which I am covered by) so we know what deadlines to not miss.

PS: thanks. I'll also try to coordinate with the internal team that does GROMACS validation (although they seem to have focused on the previous release which works fine)


Allow downloads in referer links.

Describe the bug
Go to https://dl.twrp.me/guacamole/twrp-3.5.2_9-0-guacamole.img.html and try to download the .img file.
After download the file is 6,71KB instead 34,04MB, because the browser downloads the HTML instead of the .img file.

Hi, could you use the bug template to report any issue? It will be good to know app version, android version, etc.. and any screenshot/video will be very useful too.
I will close this one as invalid, please reach to us again.
Please use our GitHub templates so we can understand better your request. Thanks.


Automation with sandboxie

i want to make an auto login with sandboxie . i can open app with this code but how to handle with this process on box to press key ? thank

This is beyond the scope of this project.
These packages may help with your automation needs:

pywinauto
PyAutoGUI

ok


x/playground: "// GOEXPERIMENT=loopvar“ line often causes "timeout running go build”

What version of Go are you using (go version)?

$ go version
1.21

Does this issue reproduce with the latest release?
Yes
What did you do?

https://go.dev/play/p/VwcNVnozJlu
What did you expect to see?

Program exited.

What did you see instead?
timeout running go build

Go build failed.

Seeing this too. Does opting into the experimentneed rebuilding parts of the stdlib, such as fmt?

(attn @findleyr @golang/release)

This is probably due to recompilation of std archives (which are cached following https://go.dev/cl/460635).
Perhaps we should add a special case and build archives with GOEXPERIMENT=loopvar here:
(https://cs.opensource.google/go/x/playground/+/master:Dockerfile;l=90;drc=6821b5629810defb1ea68149e090b5b86576d7ca)
@bcmills can you confirm whether adding a second build of std would suffice? (I'm not familiar with GOEXPERIMENT handling in the Go command).
CC @rsc, who added support for GOEXPERIMENT in https://go.dev/cl/511640.

can you confirm whether adding a second build of std would suffice? (I'm not familiar with GOEXPERIMENT handling in the Go command).

Yes, adding GOCACHE=/gocache GOEXPERIMENT=loopvar ./bin/go install --tags=faketime std should suffice.
That said, I question whether the benefit of doing so would be worth the cost, given the need to deploy and maintain it. I hope that the revised loop variable semantics will soon be available without setting GOEXPERIMENT at all. 🙃

@fzipp that's a great point.  In that case, I don't think we should bother making this work better for 1.21. It would increase the disk space required for every build, and as @bcmills noted would require maintenance.

With 1.22 out, this seems to be even worse with GOEXPERIMENT=rangefunc. I'm getting timeouts 100% of the time now with this code.


ci(Release): fixed semantic release config

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 48.99%. Comparing base (9ef40b8) to head (bb561e4).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main      #37   +/-   ##
=======================================
  Coverage   48.99%   48.99%
=======================================
  Files          70       70
  Lines         949      949
  Branches      240      240
=======================================
  Hits          465      465
  Misses        467      467
  Partials       17       17

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Calling LRS .saveStatement with an object but not a TinCan.Statement doesn't cause error

Need to investigate but the following didn't result in an error in the callback:
lrs.saveStatement(
    {
        actor: {
            mbox<EMAIL_ADDRESS>        }
    },
    {
        callback: function (err) {
            console.log("Priming statement sent");
            if (err !== null) {
                console.log("Priming statement failed: ", err);
                process.exit(1);
            }

            // getting here and shouldn't
        }
    }
);

@brianjmiller would it make sense to try constructing a TinCan.Statement object from the object passed, or should we be strict on this and only accept TinCan.Statement objects?

Actually I now suspect this is because of the dumb default of allowFail. Unfortunately didn't record how the TinCan.LRS object was constructed, but it makes sense that there wouldn't be an error in the callback if allowFail is set to true (which is the dumb default, one of the items on the roadmap #110). Though in this case perhaps even for allowFail set to true we could fail because it isn't the communication with the LRS that is failing, it is an improper use of the library.
I've thought about auto-constructing a statement object, but I don't know that there is a reason to change it for this issue, the larger problem was that even in that case it should still fail.


fix: do not clear all notification from the Drawer when a notification is opened

Sorry, two last commits shouldn't be in PR


Does it support monitoring tasks in Hive On Yarn mode?

I expect to monitor the execution status of task thought compass.
Scene:
HiveSQL + dolphinscheduler + Yarn

I expect to monitor the execution status of task thought compass.
Scene: HiveSQL + dolphinscheduler + Yarn

@hoey94 Thanks for your feedback. Can you provide more detail about Execution status of task? such as memory usage, long task tail and so on.


Add support for events to the engine instance

To enable better tooling around the engine or integration with other systems, events will be need:
const engine = new Engine(...)
engine.on(EVENT_NAME, CALLBACK_FN)

Example events:

when an error is encountered
database update
producer/view mounted/unmounted
after/before init

This is handled at a basic level within the scope of Engine Modules


Create Staircase.java

Closing Issue/Referencing Issue
issue reference (#)
Changes Made In Pull Request

@5AbhishekSaxena please add your name and info in READE.md and push again to your patch-1 branch

done
On Fri, Oct 19, 2018 at 8:15 PM Owais Ali<EMAIL_ADDRESS>wrote:

@5AbhishekSaxena https://github.com/5AbhishekSaxena please add your
name and info in READE.md and push again to your patch-1 branch
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ows-ali/Hacktoberfest/pull/80#issuecomment-431387727,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATCJcjSwMXiYKiQFO3pCiX1_znO3Evz8ks5umeWTgaJpZM4XwDyz
.

done
…
On Fri, Oct 19, 2018 at 8:15 PM Owais Ali @.***> wrote: @5AbhishekSaxena https://github.com/5AbhishekSaxena please add your name and info in READE.md and push again to your patch-1 branch — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#80 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/ATCJcjSwMXiYKiQFO3pCiX1_znO3Evz8ks5umeWTgaJpZM4XwDyz .

If you are done please push it to 5AbhishekSaxena/Hacktoberfest. Thanks, feel free to ask if you face any issue :)


SCREEN_PIXEL_SIZE not working properly

Godot version:
Godot 3.0 Stable
OS/device including version:
Windows 10
Issue description:
When I try to use SCREEN_PIXEL_SIZE as opposed to hardcoding the resolution, my shader no longer works properly.
Steps to reproduce:
Add this vignette shader code to a TextureRect that covers the entire screen with a pure black texture and scaled. Replace the first resolution's initialization with your project's resolution. Run the scene that the shader is in. Afterwards, comment the first resolution initialization and uncomment the second one. Then play the scene again. Notice how the shader just flat out makes the screen darker, when behavior should be near identical.
shader_type canvas_item;

void fragment() {
        float radius = 0.75;
        float softness = 0.45;
        float intensity = 0.15;
	vec2 resolution = vec2(640.0, 360.0);
	//vec2 resolution = SCREEN_PIXEL_SIZE;

	vec4 pixel_color = texture(SCREEN_TEXTURE, SCREEN_UV);
	vec2 position = (FRAGCOORD.xy / resolution.xy) - vec2(0.5);
	float len = length(position);
	float vignette = smoothstep(radius, softness, len);
	pixel_color.rgb = mix(pixel_color.rgb, pixel_color.rgb * vignette, intensity);
	COLOR = pixel_color;
}

SCREEN_PIXEL_SIZE is the inverted resolution, i.e. vec2(1.0 / width, 1.0 / height).

It would be nice to improve its description in the docs then: http://docs.godotengine.org/en/latest/tutorials/shading/shading_language.html?highlight=SCREEN_PIXEL_SIZE#id4

This issue should be closed now.

Fixed by godotengine/godot-docs#1443.


Introducing Replicated Logs

Scope & Purpose
As part of the effort of introducing a new replication, this PR introduces replicated logs which shall be used in that context. It is the groundwork for the new replication, but note that this PR introduces no user-facing changes, nor touches the current replication protocol in any way.

[ ] :hankey: Bugfix (requires CHANGELOG entry)
[ ] :pizza: New feature (requires CHANGELOG entry, feature documentation and release notes)
[ ] :fire: Performance improvement
[X] :hammer: Refactoring/simplification
[ ] :book: CHANGELOG entry made

Backports:

[X] No backports required
[ ] Backports required for: (Please specify versions and link PRs)

Related Information

[ ] Docs PR:
[X] Enterprise PR: https://github.com/arangodb/enterprise/pull/705
[X] Oskar PR: https://github.com/arangodb/oskar/pull/327

3.7 PR: https://github.com/arangodb/arangodb/pull/14515
3.8 PR: https://github.com/arangodb/arangodb/pull/14514
3.6 PR: https://github.com/arangodb/arangodb/pull/14516

[X] GitHub issue / Jira ticket number: https://arangodb.atlassian.net/browse/GORDO-1025
[X] Design document:

Confluence: https://arangodb.atlassian.net/wiki/spaces/AP/pages/1677852697/Replicated+Logs
Initial design document: https://docs.google.com/document/d/1a7jx0dfFgtOFC6VSH572lN_HVamY24GoGIbMhcK-pio

Testing & Verification

[ ] This change is a trivial rework / code cleanup without any test coverage.
[X] The behavior in this PR was manually tested
[ ] This change is already covered by existing tests, such as (please describe tests).
[X] This PR adds tests that were used to verify all changes:

[X] Added new C++ Unit tests
[X] Added new integration tests (e.g. in shell_server / shell_server_aql)
[ ] Added new resilience tests (only if the feature is impacted by failovers)

[ ] There are tests in an external testing repository:
[ ] I ensured this code runs with ASan / TSan or other static verification tools

Documentation

All new features should be accompanied by corresponding documentation.
Bugs and features should furthermore be documented in the CHANGELOG so that
support, end users, and other developers have a concise overview.

[ ] Added entry to Release Notes
[ ] Added a new section in the Manual
[ ] Added a new section in the HTTP API
[ ] Added Swagger examples for the HTTP API
[ ] Updated license information in LICENSES-OTHER-COMPONENTS.md for 3rd party libraries

https://jenkins.arangodb.biz/job/arangodb-matrix-pr/16369/


Create file using Outstream and Instream

Hi,
how do i create file in extension, without changing target in app.json (because Extension cannot use FILE datatype) ? In some thread i have read that i need to use Outstream and InStream, but any example using outstream to create text file?
in issue #934 is an example of picture.
Thanks

This is an example that create a text file with 3 lines.
codeunit 50102 CreateFiles
{
trigger OnRun()
begin
end;

procedure CreateTxtFile(FileName: Text)
var

    InStr: InStream;
    OutStr: OutStream;
    tmpBlob: Record TempBlob temporary;
    CR: char;
    LF: char;

begin
    CR := 13;
    LF := 10;
    tmpBlob.Blob.CreateOutStream(OutStr);
    OutStr.WriteText('First line'+ CR + LF);
    OutStr.WriteText('Second line'+ CR + LF);
    OutStr.WriteText('Third line'+ CR + LF);
    tmpBlob.Blob.CreateInStream(InStr);
    DownloadFromStream(InStr, '', '', '', FileName);
end;

}

thanks  @ftornero9 , your code works well.
first i'm curious what for CR and LF, but looks like it is necessary for line breaking.
https://dynamicsuser.net/nav/f/developers/8258/carriage-return-crlf-into-a-text-variable

anyone asked before how to silently download file to specific folder using code @ftornero9 given?
in https://forum.mibuso.com/discussion/69837/downloadfromstream-function-question
we can use method BLOBExportToServerFile from codeunit 419, but in extension we couldn't use the method.
is there any other way?

@hydhart not at the moment.


Change http to https for security links

Signed-off-by: Nguyen Van Trung<EMAIL_ADDRESS>
What this PR does / why we need it:
For security, Should change into https links.
Special notes for your reviewer:
NONE
If applicable:
[x this PR contains documentation

@mattfarina Thank you for your review. I just updated new PR.


add DEFAULT_PROJECTIONS_RESOLVER

fix logger initialization

When merged the docs need to be updated.

@salvaom I think the current implementation might work fine, but I think we need a good variety of query tests before this should be merged.
Additionally, I will update the docs to include the information about the new resolver.


add active styles to anchors

Nuxtent would need access to the instance for every route change and 2) This can easily be added to computed property.

Whether to show anchors:
    menu () {
      return this.guide.map(lesson => {
        if (lesson.permalink === this.$route.path) lesson.showAnchors = true
        else lesson.showAnchors = false
        return lesson
      })
    },

And use nuxt-link-active class to style them.


Different pathname in runtime and static build

Same as #469
Pathname in static build and runtime is different, so if you have something what depends on pathname, it is different in generated html and React runtime.
Example: look at https://nozzle.io/features, on the first load there is no sign of active state in navigation, but if you change pages using navigation, drop shadow appears
@tannerlinsley

Hello,
I'm having the same issue. Pathnames in static build are not working.
Could you please look into it? @tannerlinsley


Channel support

Where can I find Channels in the Pushbullet interface?

In the website https://www.pushbullet.com/channels.
I dont know where you can see your created channels (maybe because is quite new). I use https://www.pushbullet.com/channel?tag=CHANNELTAG to see my channel and then suscribe.

You can find your created channels here:
https://www.pushbullet.com/my-channels
Or by clicking on your profile picture and going to "My Channels".

I'm looking forward to this one to be accepted! @isseu My only concern with your PR is that the documentation you've added says that one need to inform the "channel name", but you're using "channel tag" (and I really think that channel tag is the correct way to go, as it is a unique identifier on Pushbullet). Your variables are also named channel_name, even though it's channel_tag. This is inconsistent and may lead to user confusion. Anyway, great PR, that's what I needed :)

Looks good to me. @r-darwish, could you take a look at this?

Seems legit. @isseu - Did you check it on Python 3?

@r-darwish yes, working in Python 3.4.2.


Multiple CSE on a single VM not allowed

Please add the following line to the Tips and tricks section:
"You can have only one version of an extension applied to the VM. To run a second custom script, you can update the existing extension with a new configuration. Alternatively, you can remove the custom script extension and reapply it with the updated script."
This line already exists in the Linux CSE article and the same concept applies to Windows CSE, but since it isn't listed here people think its unique to a Linux VM
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 40aaccb8-19ba-168f-f5bf-65f1f5331541
Version Independent ID: 6cdfd166-633a-50a3-2b45-cde0e991e540
Content: Azure Custom Script Extension for Windows - Azure Virtual Machines
Content Source: articles/virtual-machines/extensions/custom-script-windows.md
Service: virtual-machines
Sub-service: extensions
GitHub Login: @MsGabsta
Microsoft Alias: gabsta

@kegregoi
Thanks for the feedback! I have assigned the issue to content author to check and update the document as appropriate.

@MsGabsta
Can you please check and add your comments on this doc update request as applicable.

Looks like some updates were made. Closing this out but if issues are still present just let me know.
#please-close


Emit a signal when a ticket is updated

I have a use case where I need to follow the modifications of the tickets.
I unfortunately cannot hook to the post_save signal of the FollowUp model because at this time, the TicketChange and Ticket models are not updated yet with new data.
Someone added the notify_followup_webhooks function to update_ticket for a similar purpose.
In this PR, I propose to have the update_ticket function emit a signal when its process is done.
This way, anyone can hook post processing workflows outside of helpdesk.
Not to have duplicate code logic, I move the notify_followup_webhooks outside of update_ticket and have it listen to the ticket_update_done signal the same way someone would do it outside of helpdesk.

Also added the signal to email.py, this way notify_followup_webhooks is only triggered through signal.

I already included tests for webhooks 🙂https://github.com/django-helpdesk/django-helpdesk/blob/main/helpdesk/tests/test_webhooks.py
There is a second webhook that is triggered on ticket creation. It would be nice to go all the way and wire that through the signals as well.

Yes, I used the test_webhooks to verify compliance, thanks Timothy!
I knew you were going to ask. ;)

The new ticket webhook is activated with a specific role, where a signal should be emitted no matter what.
And I don't really understand the relation between new_ticket_cc and the webhook activation, could you explain it?
        if "new_ticket_cc" in roles:
            send_new_ticket_webhook(self)

Anyway, what I would do is place the signal close to the new ticket creation, which I think is the forms.TicketForm.save() method before self._send_messages:
https://github.com/django-helpdesk/django-helpdesk/blob/main/helpdesk/forms.py#L421
And use ticket._state.adding to check whether the ticket was created or modified.
The signal would be emitted at every ticket modification but the webhook would be activated at ticket creation.
Does that sound OK to you?

Looks good to me.
Note that the send_new_ticket_webhook is now disconnected from the new_ticket_cc role.

I put it in the "new_ticket_cc" location because the tickets are not created with the form when they are processed in email.py if I recall correctly.

Thank you.
I had the same problem with email.py and fixed it by adding the signal to it.

@uhurusurfa I think this can be merged now.


Optimize history tables for query by id performance(claimable balance, accounts, liquidity pools and assets)

What version are you using?
Horizon 2.18.1
What did you do?
https://horizon.stellar.org/claimable_balances/0000000028b32c721976af53fa0419eba129f3da70168f1e39822a25886375abad9599da/transactions?limit=1&order=asc
What did you expect to see?
list of transactions related to entity returned in reasonably fast response time
list of tx's by entity covers a few types that can be vulnerable to this query path behavior, 'claimable balance', 'accounts', 'liquidity pool', 'assets', want to include optimization for each of these as they likely have same root cause in query performance.
What did you see instead?
503, timeout responses.

this issue was identified by @jcx120 and triaged in slack thread, @sydneynotthecity investigated the underlying sql query for the endpoint and mentioned in separate thread that successful IS NULL on tx table in where clause is highly likely to be cause, need to identify if that check on history_transactions.successful is necessary and if not remove, and verify performance improvement.

Another item I would propose: changing the LEFT JOIN clause to an INNER JOIN on history_ledgers table. My assumption is that the LEFT JOIN ensures if a transaction is written to the history_transactions table prior to history_ledgers closing the current ledger, the transaction would still appear. Is this a frequent edge case that happens for this route? Would we be able to accept the risk that a transaction submitted in <5 seconds from current time might not be in the return results?

Update: optimizing the query does not provide measurable benefit to query runtimes; I recommend we leave the query unchanged.
If we update the WHERE successful is NULL condition and accept the risk of dropping records by removing the LEFT JOIN, we only reduce the query runtime by 3000 ms (the query on average takes 184,000 ms to execute) which is a reduction of ~1.5%
@sreuland do you know if we can add another index to this table? The table only has the following indices:
"index_history_transaction_claimable_balances_on_ids" UNIQUE, btree (history_transaction_id, history_claimable_balance_id)
"index_history_transaction_claimable_balances_on_transaction_id" btree (history_transaction_id)

Since there is no index with history_claimable_balance_id only, the query you sent is performing a full table scan.

@sydneynotthecity , I'll try new recommended index on staging db, it has a full copy of the pubnet data set on it's postgres instance, should be able get decent estimate of the net effect to this query, thanks!

@sreuland the history_operation_claimable_balances has the same indices as the history_transaction_claimable_balances table:
"index_history_operation_claimable_balances_on_ids" UNIQUE, btree (history_operation_id, history_claimable_balance_id)
"index_history_operation_claimable_balances_on_operation_id" btree (history_operation_id)

I bet if we add a third index with history_claimable_balance_id only that the query cost would reduce for operations as well.
We're have to ensure this additional index wouldn't impact routes that search on operation/transaction only if that's a common access pattern for this API.

@sydneynotthecity @jcx120 , i tested on staging db the suggestion of new indexes from Syd, the staging db has full pubnet dataset, so it's comparable for measurement, the fix works great for ops and txs, the response time is now sub-second, can contrast the two here:
staging with indexing
prod without indexing
thanks Syd!

@sreuland do you know if any other Horizon route uses those two tables? Want to confirm that we're not impacting other existing traffic by adding the new indices to the tables. My assumption is this is the only route but want to be certain.

Also in addition, would be curious to see if adding these indices significantly impacts DB storage footprint.

@sydneynotthecity , it looks like usage of history_transaction_claimable_balances and history_transaction_claimable_balances limited to queries for just these endpoints here /claimamable_balances/{cb_id}/[operations|transactions].
@jcx120 , I pulled the size of these new indexes, each took about 5.7GB of space in the DB, so a combined total of 11GB, buty that is just based on todays ledger size, that would grow as more cb entries are created.

@2opremio , @jcx120
Per suggestion, I expanded the scope of acceptance criteria to include review and optimization of query-by-tx for a wider range of entity types beyond just cb's, such as accounts, liquidity pools and assets.


Updated url from get_cvss_score function

I approved another PR solving the same issue, thank you for being active member of the community and submitting this PR though, greatly appreciated!


feat: add mdx and about page

Created layout component to use for mdx page and added styles for the text.

@sarthaktexas should i get the text to overlap with the svg or move it down?

I think the design would look really cool if the text would overlap with the svg. Otherwise it just feels like a lot of blank space.

📝Changed routes:

/about
/

(view full size)
(view full size)

Commit b6cdeddbedbf04d2767383dbcf72d4346bc53af4 (https://open-kh7vhu5yb-thinkfiveable.vercel.app).

I'd like us to have a heading on top of https://github.com/ThinkFiveable/open/pull/36/files#diff-62560091290dc9edebbff8bb0ff6f88a3eacb7ef5fbec9e4b320ddd54b44d55cR5, otherwise the body text looks out of place.
Can we also make the mouse pointer change when people hover over Learn More? Right now the mouse pointer stays the same when hovering over the Learn More button.


Show current knife in use in shell prompt

Are there any plans to show the current knife configuration in use in the shell prompt? If not I can consider writing it, if you would like to pull it. Or would you consider such functionality better handled in a separate project/repo?
Thanks,
Benjamin

I'd happily accept a PR. Since i'm not really using chef with a server at Travis this project is kinda just on maintenance right now. I've been meaning to see about finding 1-2 people who'd want to help with possible future development

#52 PR created

@benvaljean I am no longer using knife-block and don't really have the time to steward it anymore :( Would you be interested in working on it? I'd be happy to get you access to GH and rubygems if so

Ok great. Ruby is not one of my primary languages though. Outside of chef I have not done much on it.

@benvaljean is that a yes? :) if so would you email me your rubygems account name and email, to<EMAIL_ADDRESS>Thanks!

@solarce Yes it is a yes :)  I emailed you my details, thanks!

https://github.com/knife-block/knife-block/pull/54 was merged and addresses this issue


Not remove bundle config file

If .bundle/config already exists, I don't want to remove it.
So bundle config file location specified.
BUNDLE_APP_CONFIG used bundle ~> 1.0.0.rc.4

released v0.4.4!

:+1:


Use custom markdown list indentation configuration (e.g. from markdown lint) over global editor.tabSize

It would be nice if vscode-markdown could use a markdown specific tab setting over the global editor.tabSize one, for instance the one from markdownlint.
I tried the per-file setting as per https://github.com/neilsustc/vscode-markdown/issues/77#ref-commit-fd60143, but clicking on the "spaces: 4" does not allow me to change that.

Problem
When installing, https://github.com/DavidAnson/vscode-markdownlint it will throw MD007

Reproduce
Install https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md007, edit some markdown with lists, indent part of the lists, observe the MD007 errors to appear.

Console error messages
None
Proposed solution
It would be really nice if vscode-markdown could use a markdown specific indentation setting over the editor.TabSize, for instance vscode-markdown.config/lists/indent:
    "vscode-markdown.config": {
        "lists": { "indent": 2 }
    }

Or even nicer: if markdownlint is installed, vscode-markdown could use the markdownlint.config/MD007/indent indentation setting for lists (and the global editor.tabSize for all other indentation).
Notes
Related: https://github.com/neilsustc/vscode-markdown/issues/77
markdownlint has a markdown specific tab setting for lists:
    "markdownlint.config": {
        "MD007": { "indent": 2 }
    }

Of course one could change this to 4, but the vast majority of online markdown is using an indentation of 2, hence different proposed solutions.

One of my motivations for this suggestion is that I am moving from atom.io to vscode (which is far more responsive than atom.io and is a lot easier for doing .NET and PowerShell based projects).
In atom.io, markdown editing lists feels a lot more natural than vscode, hence the suggestion (more might follow as I recently started to make the switch and it takes time to get a proper feel for the differences).
I know how hard it is to write editors and plugins, so I understand your hesitation. Being a n00b at atom plugins, but willing to learn, maybe you do have some energy to help me guide and understand possible approaches? That way I could try to come up with pull requests to get a better feel for how hard it actually is and maybe get a bit closer.
Markdown, reStructured text and plantUML are the text formats I write almost all my documentation in, so I am willing to put energy in making life as easy as possible for me editing them.
I am also aware that no tool is perfect (for instance atom.io has an issue with https://github.com/remarkjs/remark-lint/tree/master/packages/remark-lint-list-item-bullet-indent incorrectly flagging valid unordered lists), so I try to put in issue reports where appropriate and help where I can.

@neilsustc I was probably confused by this pop-up menu thinking it would convert all space indents to tabs or vice versa, or use spaces/tabs from now in stead of changing the number of characters to use for indentation:

Where is that setting persisted?

"Indent Using Spaces/Tabs" is "start use spaces/tabs from now"
"Convert Indentation to Spaces/Tabs" is "convert indentation to spaces/tabs in current doc"
And as it is a per-file setting, I guess it is cached by vscode just like "recently opened files".

And FYI, the indent guides issue I mentioned above

Even though you can config unordered list indentation to 2, ordered list to 3, the indent guides don't know this behavior.

An update, we can have a self-adaptive indentation scheme option. See #241-comment.

I guess we can close this issue 👍

Uh, PR#319 does solve the indentation problem of TOC. But the indentation on enter/tab keys are still not changed.
I will work on it soon.

You can now try out the dev build.


Longer Hand Reach Incompatible With Other Mods (Pehkui,Campanion)

I think Pehkui or Campanion is causing this issue. Pehkui changes your hand reach when you change size, and Campanion increases your hand reach with spears.
https://www.curseforge.com/minecraft/mc-mods/pehkui
https://www.curseforge.com/minecraft/mc-mods/campanion

The spear works even when the player is scaled, although it seems that the extended spear reach does not grow with the player size.

Campanion also has longer hand reach for entities, so you can borrow the code from there if needed.

The reach code has been removed


Confusing text about removing evil

These two things, written right next to one another in https://github.com/hlissner/doom-emacs/blob/develop/modules/editor/evil/README.org#removing-evil-mode, seem mutually contradictory.  Either when removing evil I need to reassign these variables, or I can ignore them, but I don't understand how to do both at once.  Also AFAICT they are bound to M-SPC and M-SPC m, not C-c and C-c l.  I'd suggest a fix if I had any idea what the right thing to say was…
You must do two things to remove Evil:
...
3. [OPTIONAL] You may want to assign new values to ~doom-leader-alt-key~ and
   ~doom-localleader-alt-key~. These are bound to =C-c= and =C-c l= by default.

#+begin_quote
Ignore ~doom-leader-key~ and ~doom-localleader-key~, they don't apply to
non-evil sessions.
#+end_quote

Also AFAICT they are bound to M-SPC and M-SPC m

They are bound to C-c and C-c l when evil is disabled.

These two things, written right next to one another in https://github.com/hlissner/doom-emacs/blob/develop/modules/editor/evil/README.org#removing-evil-mode, seem mutually contradictory

Sounds like you misread.

doom-leader-key != doom-leader-alt-key and doom-localleader-key != doom-localleader-alt-key.
doom-leader-key and doom-localleader-key are not used when evil is disabled, as the quote says.
You may want to change doom-leader-alt-key (default: C-c) and doom-localleader-alt-key (default: C-c l) if you don't like their defaults. If you don't mind the defaults, you don't have to. Seems clear to me.

As this seems like a misinterpretation, I'll close this. In any case, our docs are undergoing a rewrite, so this will likely resolve itself in time anyway.

I see. Yes, it's a misinterpretation, which points to the need to more clearly distinguish the different variables.  If, as you say, the “docs are undergoing a rewrite,” should I stop trying to submit improvements?  I'm trying to be helpful, not annoying ;-)


Make Kubelet Configuration customizable

[x] Design Review
[x] Create cluster with custom Kubelet configuration
[x] Upgrade cluster with custom Kubelet configuration
[x] Write and Test Docker
[x] Write and Test vSphere
[x] Write and Test Cloudstack
[x] Write and Test Tinkerbell
[x] Write and Test Nutanix
[x] Block setting cloud-provider and provider-id fields
[x] Bottlerocket support - add patch on the CAPI side to introduce all the fields exposed for BR
[x] e2e test

Can we close this issue?


fixes piece list command help text

fixes #43

@abhinayy0 this is the file Jayson is referring to https://github.com/pieces-app/cli-agent/blob/main/src/pieces/gui.py
Thank you for the contribution!

hey @abhinayy0 looks like there are some conflicts, please let me know if you want some help here

@mark-at-pieces Issue got resolved in other PR an can be marked as closed: https://github.com/pieces-app/cli-agent/pull/71


Similarity3DTransform::SetScale should recompute m_Offset

Description
When Similarity3DTransform::SetScale is called, it does not compute m_Offset, which appears to cause an incorrect result from similarity3DTransform.TransformPoint when  TransformPoint is called directly after SetScale.
https://github.com/InsightSoftwareConsortium/ITK/blob/895fc718e814527aa156f7ff63ca8d5e15761d26/Modules/Core/Transform/include/itkSimilarity3DTransform.hxx#L59-L65
The 2D version behaves differently: Similarity2DTransform::SetScale does compute m_Offset:
https://github.com/InsightSoftwareConsortium/ITK/blob/895fc718e814527aa156f7ff63ca8d5e15761d26/Modules/Core/Transform/include/itkSimilarity2DTransform.hxx#L112-L119
Steps to Reproduce
The 2D transform:
const auto transform2D = itk::Similarity2DTransform<double>::New();
transform2D->SetCenter(7.0);
transform2D->SetScale(3.0);
std::cout << transform2D->TransformPoint({}) << '\n';

Prints [-14, -14], which looks fine to me. However, the 3D version:
const auto transform3D = itk::Similarity3DTransform<double>::New();
transform3D->SetCenter(7.0);
transform3D->SetScale(3.0);
std::cout << transform3D->TransformPoint({}) << '\n';

Prints [0, 0, 0], which appears wrong!
Expected behavior
In general, PointType(center + (scale * (input - center)). When the input point is entirely zero ({}),  center = PointType(7.0) and scale = 3.0, I would expect PointType(7.0 + (3.0 * (0.0 - 7.0)) == PointType(-14.0).
Versions
ITK 5.2, as well as revision 895fc718e814527aa156f7ff63ca8d5e15761d26 (today July 2, 2021 at the master branch)
Additional Information
It looks like this inconsistency between the 2D and the 3D version of the similarity transform has been there for a long time already! Comparing the 2D and 3D version from commit 5d9e2fc59e94e0f8f9e862af10c423abcda8a144 by Luis Ibanez (@luisibanez), 29 April 2005:
https://github.com/InsightSoftwareConsortium/ITK/blob/5d9e2fc59e94e0f8f9e862af10c423abcda8a144/Code/Common/itkSimilarity2DTransform.txx#L121-L129
https://github.com/InsightSoftwareConsortium/ITK/blob/5d9e2fc59e94e0f8f9e862af10c423abcda8a144/Code/Common/itkSimilarity3DTransform.txx#L56-L64

Oh, I guess #2627 is testing this.


grub: Support 32bit EFI on 64bit platforms

Motivation for this change
With these changes it is possible to boot, install and run a 64bit NixOS on 64bit machines with a 32bit EFI. Example for such systems are the first few generations of Intel Apple Mac Pros or certain Intel Atom based systems.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Seems like we just missed the windows for 19.03. I assumed mixed (U)EFI support seems to be on the agenda of at least a few people.
@matthewbauer Did you have time to look at this yet? If targetPkgs hits to close to home, I can name it anything else.
@samueldr Anything else I can do to move this along?

@matthewbauer: Thank you for your feedback. I added the proposed changes.

@Infinisil Would you mind taking another look, so we can get this merged?

@GrahamcOfBorg test installer.simpleUefiGrub

Glad to hear that. What is missing to get this merged?

I think we should backport this to 19.03

Done,
[release-19.03 de621d4939d] grub: Support 32bit EFI on 64bit x86 platforms
Date: Mon Jan 28 12:00:58 2019 +0100
2 files changed, 29 insertions(+), 18 deletions(-)


Add a cubic Bezier signal

I found myself needing an equivalent of CSS ease-out, without the ease-in from curveS' S-curve. Why not just make it more general? :)
I'm still unfamiliar with the codebase, so I likely missed some necessary changes. I'd appreciate if a contributor took a second look! In particular, there are the *.golden files in the examples/ directory that I'm not sure what the purpose of is, or how to generate them.

The golden files contained the SVG output of each example and are automatically checked for correctness. You can generate a golden file by running: stack ./examples/doc_cubicBezierS.hs test > examples/doc_cubicBezierS.golden
To see if everything works, run this command: stack test --flag reanimate:test
I should really put all of this stuff in the README.

Oh, this test command is better: stack test --flag reanimate:test --test-arguments="-j8" where -jN should indicate how many cores you have available.


Toggle Drag Ruler on and Off

Low priority for an enhancement, but it would be helpful if we were able to toggle the drag ruler on and off.
For example, I would like to be able to turn this on in combat but have it off when there is free scene exploration

I'm thinking about an option that disables Drag Ruler by default and only activates it once the button that adds a waypoint is being clicked once. Would that feature sufficient to fulfill your request?

I think it's a great suggestion! Another idea would be an option that only activates the Drag Ruler when we click on the start button and then deactivates the module again when the combat is over.

v1.8.0 contains the feature I suggested earlier. With this feature being present, is this request resolved from your point of view @aceofknits?

Hi, this option it's a very good idea but it's seen to dont work.
When I select a token and use Ctrl + Left-Click Drag and Left-Click to add waypoint I have no color for walk, dash or unreachable. If automatically strat measuring is check the module work well.
Thanks

@CaosFR Ctrl+Drag is a foundry native function and doesn't have anything to do with Drag Ruler. When automatic measuring is disabled, press the button that adds a waypoint (spacebar or right click) while dragging to start measuring

@manuelVo Thanks for your help. With spacebar it's work very well.
May it's will be interessting to incoporate this mecanic to the native CTRL+Drag option.

I'm thinking about an option that disables Drag Ruler by default and only activates it once the button that adds a waypoint is being clicked once. Would that feature sufficient to fulfill your request?

I still think it would be nice to have an option to automatically turn the drag ruler off outside of combat, and fully turn it back on during combat.
There is rarely a need to measure movement distance outside of combat, and almost always a need for it during battle.

I'm agree, it's will be cool.

Closing, since from my point of view the original request is resolved.
The feature request to automatically enable Drag Ruler in combat and to automatically disable Drag Ruler out of combat is being tracked in #187


Just format some logs and notes in /daemon/networkdriver/bridge/driver.g...

Just format some logs and notes in /daemon/networkdriver/bridge/driver.go
Signed-off-by: Zen Lin(Zhinan Lin<EMAIL_ADDRESS>

LGTM

LGTM


When logging out of your account, the database is not cleared

How to reproduce:

Log in and load the list of articles.
Log out of your account.
Stop the Shiori server, delete (or rename) the database so that the next time it starts it will be empty.
Launch the Shiori server.
Log in to your account via PageKeeper.
We see that a cached list of articles remains.

This may have potential security issues if the application user decides to change servers.

Fixed, thanks!