uncaught error if swapper.buildTrade fails

Overview
uncaught error if swapper.buildTrade fails
References and additional details
uncaught error if swapper.buildTrade fails
Acceptance Criteria
uncaught error if swapper.buildTrade fails
Need By Date
No response
Screenshots/Mockups
No response
Estimated effort
No response

@elmutt is this still valid?

closing, ops can reopen once swapper UI changes are made and this is still valid


Add "expand all" (Cmd-Click or Ctrl-Click) and "collapse all" (Alt-Click) functionality

This resolves #629

Added collapse all in addition to expand all

@clbond LGTM but first let's create an issue for this with a description of the feature. I'll give it the approval after

https://github.com/rangle/augury/issues/629

:shipit:

:shipit:


Start deprecating previous CSI releases

Describe the bug
We dont have a clear policy on which ceph csi releases are supported and what are deprecated, I would like to propose below support policy and would like to get opinion on this :

Deprecate or mark all the N-1 major releases as deprecated

For ex:
Considering we have release 3.X now, mark all the releases <v2.0.0 as deprecated and remove from the support.
@nixpanic @Madhu-1 @agarwal-mudit  any thoughts on this ?

Sounds good to me to deprecate all releases less than N-1.

Describe the bug
We dont have a clear policy on which ceph csi releases are supported and what are deprecated, I would like to propose below support policy and would like to get opinion on this :

Deprecate or all the N-1 major releases as depreacted

For ex:
Considering we have release 3.X now, mark all the releases <v2.0.0 as deprecated and remove from the support.
@nixpanic @Madhu-1 @agarwal-mudit any thoughts on this ?

Sure, we can deprecate N-1 and suggest an upgrade for the same :+1:

Also what about minor releases? I think supporting last 2 or 3 minor releases are good enough , Isnt it ?
For example, on support major versions, last 2 minor releases are supported.
In that sense, with the release of 3.4.0 , we drop support for 3.1.0 ? and only support from 3.2.0?

Also what about minor releases? I think supporting last 2 or 3 minor releases are good enough , Isnt it ?
For example, on supported major versions, last 2 minor releases are supported.
In that sense, with the release of 3.4.0 , we drop support for 3.1.0 ? and only support from 3.2.0?

IMO Minor releases will always be backward compatible and no breaking changes and we should support all the minor releases for the supported major releases. the deprecation should be only for major releases.

also what about the patch releases?  considering patch releases are CVE fixes mostly, may be only last 2 patch releases in support?

The process to deprecate a release should be part of the process that is used for releasing a new version. This should also include adding/removing backport-to* labels, updating Mergify rules, ...

@humblec anything pending on this one or we can close it?

@humblec anything pending on this one or we can close it?

This has been addressed in both of the projects ( ceph-csi ) and rook https://github.com/rook/rook/pull/8756 , so closing it.


what happens?

if i meet the req's of having an empty repo and run through the guides, what is a actual output and what will i be able to do with it?

Updated readme with all that information.


Use ~/.kube/config for getting authentication information

Add a dedicated property like docker.kubernetesAuth which does the following when enabled:

Read ~/.kube/config as YAML file
Look for the default context (i.e. the active context)
Lookup the corresponding server and the credentials
Use user, password, email for authentication against a docker registry

This is a followup story to #147

fyi: i am using snakeyaml to handle #57...just in case you decide to tackle this before i get my PR in.

thanks for the heads up, we hereby settle on snakeyaml as the library for parsing yaml ;-)


insulin-like growth factor receptor activity (GO:0005010) is not always a tyrosine kinase

The IGF2R is not a tyrosine kinase. PMID:22710100, PMID:23257688. It appears that this receptor functions to scavenge IGF2, so I'm not sure we would even consider it a signaling receptor.

@ukemi could a NOT be used to block propagation from non-manual sources here?

That would be a solution for annotations, but this error exists in the ontology. It would be better to correct it there.

I think for the example that you cite, it's not a it a signaling receptor and so the annotation would be wrong. Perhaps a new term for this scavenge-like function - not sure if GO:0005044 would do?

Hi @ukemi
IGF2R is not a signaling receptor either then, is it?  Since it does not activate signaling upon ligand binding, it seems to  regulate insulin-like signaling rather than be involved in the signaling?

Works for me.


🐛 Bug Report: 'mkdocs' child process logs are not logged for TechDocs

📜 Description
During the build phase of TechDocs, users can see the build logs in the UX of Backstage. This is great.
However, for some reason the log output of the mkdocs child process is not displayed. So you can easily get an error saying that mkdocs exited with code 1, but the actual output of mkdocs itself is lost. For some very specific situations, the error can be found in previous places in the logs, but if mkdocs fails due to an unexpected reason you have to dig and dig to figure out why.
I have dug through the code and am not 100% sure why this happens, other than it does appear that the logStream provided to the child process is not the same as the logger that is used by TechDocs build process.
See techdocs-node/src/stages/generate/techdocs.ts file. For some reason the logStream passed in is never logged out during the build phase:
case 'local':
          await runCommand({
            command: 'mkdocs',
            args: ['build', '-d', outputDir, '-v'],
            options: {
              cwd: inputDir,
            },
            logStream,
          });
          childLogger.info(
            `Successfully generated docs from ${inputDir} into ${outputDir} using local mkdocs`,
          );
          break;

Ideally, what would be super cool is the following:

The ability to customize how the logger for child processes is used
Ability to turn on the mkdocs child process output during the build process
A log output of the exact full shell command that is run as a part of the child process so at least you could try to run the command yourself in the terminal.

👍 Expected behavior
You should at the very least be able to at least turn on the logger for the child process - and if that way exists I could not find it so it should exist in the docs if it is possible!
👎 Actual Behavior with Screenshots
The build output for mkdocs does not exist.
For example:

👟 Reproduction steps

Setup your 'local' docs build
Remove the 'mkdocs-techdocs-core
Run a docs build in the UI
Notice that the mkdocs fails but there since you cannot see the output of mkdocs child process in the UI and its hard to see why mkdocs failed and the console logs for mkdocs are lost

📃 Provide the context for the Bug.
Spent hours trying to figure out why mkdocs was failing. And was unable to see why.
🖥 Your Environment
Any environment.
👀 Have you spent some time to check if this bug has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
Yes I am willing to submit a PR!

Thanks for logging this @joshjung 👍


Documentation for getting around Excess Property Checks is Wrong(?old)

In interfaces chapter, at https://github.com/mani-mishra/TypeScript-Handbook/blob/master/pages/Interfaces.md#excess-property-checks
we have following,

One final way to get around these checks, which might be a bit surprising, is to assign the object to another variable: Since squareOptions won't undergo excess property checks, the compiler won't give you an error.

let squareOptions = { colour: "red", width: 100 };
let mySquare = createSquare(squareOptions);

But when I tried the same example in TS playground, I do get the squiggly red marker and tooltip  that even the above workaround is wrong(which is correct, as this is very common pattern).
So, maybe the docs need updating?
I'm happy to raise a PR if required.

We need to document weak type checking, which is a check for when an all-optional interface rejects anything that doesn't have any properties in common.

Check the code sample and added an exception to excess property check workaround 🙏


Version 1.4.1 broke update callback

Hello,
I tried updating your library from 1.4.0 to 1.4.1 and noticed the picker is no longer passed into events which causes issues if multiple pickers are used in the same page. We use it like this (sorry for CoffeeScript):
class Abc
  constructor: ->
    for input in @inputs
      $input = $(input)
      picker = new CP(input)
      $input.data('picker', picker)
      picker.on('change', this._handlePickerChange)

  _handlePickerChange: (color, picker) => # <-- picker is undefined in 1.4.1
    color  = "##{color}"
    $input = $(picker.source)
    # ... do other stuff

Is this fixable or should we do things differently?
Thank you,
Ollie

Hm, this is a problem because this in our case is not the context of the function but our class object/instance. I could work around that by doing var self = this black magic and passing it into an anonymous function that would call the appropriate method and passing in your this as an argument, pretty much recreating what you removed.
jQuery solves this by having this refer to the element and also providing a parameter just in case you decide to rebind the context.

Try something like myFunc.apply(this, [a, b, c]) or myFunc.call(this, a, b, c) to pass the this scope to the myFunc context.

If I rebind the method, I lose the picker object (because it was passed as argument before but now it is as this). I cannot call the method when initializing, it's called when an event is triggered. I tried this picker.on('change', $.proxy(this._handlePickerChange, this)) for reference.

class Abc
  constructor: ->
    self = this
    handlePickerChange = (color) ->
      self._handlePickerChange.apply(this, [color])

I already am doing a call in the anonymous function so doing apply is not going to change anything. What I'd like to do is get rid of the anonymous function completely but that would require that the library passes the picker as an argument as it was before.

Oh I forgot this:
  _handlePickerChange: (color) =>
    color  = "##{color}"
    $input = $(this.source)


what happend to gliz

@blooket500k his github got tooken down. althogh it is mostly becuse he hacked the blooket twiter, he is still probaly doing nothing to do with blooekt for quite a long time. the blooket team threntend gliz. the comunity is handling it, and will get this over with soon (i an not in this groop) but if you want blooket hacks just make shure to keep a eye out by serching on github blooket hacks! #freegliz


feat: add Breez Liquid SDK  funding source

A funding source that uses the liquid variant of breez sdk for lightning over liquid.
Running lnbits with this is the same as https://github.com/lnbits/lnbits/pull/2358 but without the need of any additional daemon, in fact,  it only needs a seed phrase, making it a very low barrier "non custodial" option (with the known liquid compromises).
Since there is a receiving fee when using boltz swaps, i had to add a field to InvoiceResponse to account for that.
I originally built this for my own use, but I thought it might be a valuable addition for others as well, so I submitted a PR, feel free to share your thoughts.
Also, i don't know how to write tests for this, but we can probably figure something out.

very cool!


Enhancement of http destination

handle status codes 200, 201 and 202 as success
remove upload files only on success
use result.close() to avoid memory issues

I've tested this on my Enviro Urban and can confirm the result.close() fixes the issue where (for me) only 3 readings could be sent at a time before memory issues prevented the rest going through.

If I'm being pedantic I'd say the if statement should be reversed so that not in becomes in. Otherwise this looks good, thank you! Just waiting on @lowfatcode to have a moment spare from EPIC FONT STUFF to review this.

Thanks all! I had been messing with the HTTP endpoint already so have manually added these fixes: https://github.com/pimoroni/enviro/commit/cafed0633d290945bcefeb4827051df16c860ac8


Add .code-workspace for API spec development

Fixes #169
Changelog

Define a multi-root VS Code workspace that includes only folders relevant to the development of the challenge registry API spec

I'm shelving this PR because we currently don't have a use case for using multi-root VS Code workspaces.


[in_app_purchase] Run queryPurchases callback on main thread

Billing 4.0 changes listener callbacks to execute on a background thread instead of the main thread. This makes code in the listener unable to communicate with the rest of the engine/embedding/framework.
This PR posts the listener callback to be executed on the main thread again.
https://github.com/flutter/flutter/issues/107454

@stuartmorgan @camsim99 This is ready for review :)


Using "world" instead of "board"

In my understanding, the top-most object, binding all quantum objects together is the [Quantum]World.
Based on this, I would call any (member)variable/parameter as "world", instead of "board".
E.g. member variable of QuantumObject.

See PR#39. As soon as it is merged, this issue can be closed.


Images In a row

Is it possible to put images in a row? i.e side by side- Can't seem to do this at the moment.

Yes this is absolutely possible, you can align images left of each other by dragging them over each other on the left hand edge which will display them in a row. However, by default the alignment will allow text to try and wrap around the images, so you'll end up with something akin to:

Though you could fill the row - a better solution would potentially be to add a CSS class designed specifically for this which you apply to each image you want to appear in a row and that has a :last-child style to add an puedso :after element that will clear the last item.
If you wanted to center the images then this would be slightly more tricky as you'd ideally want to use a parent element to implement the center alignment - this would mean splitting a single editable region potentially into 3 regions, e.g.

Upper content

Lower content


Problems with form-dialog property box

Expected behavior
There should be explicit confirm/cancel buttons of some kind instead of trusting a user to discover that clicking outside the box confirms it and the only way to "cancel" addition of a property is to confirm it, then find "Delete" in the kebab menu.
Screenshots

I think the current UX works pretty well for this iteration, we may or may not consider changing it in the future.
when you (as user) learn how to use it, it's pretty straightforward.


Interview partners for research about communication in GitHub projects wanted

Hi. My name is Verena Ebert, and I am a PhD student at the University of Stuttgart in Germany.
A few months ago, I have examined 90 GitHub projects to see what communication channels they use and how they write about them in the written documents, for example README or wiki. If you are interested in the previous results, you can find them here:
https://arxiv.org/abs/2205.01440
Your project was one of these 90 projects and, therefore, I am interested in further details about your communication setup.
To gather more data about your communication setup, I kindly ask one of the maintainers to do an interview with me. The interview will be about 30-35 minutes long and via Skype, WebEx or any other provider you prefer. The interviews should be done in November 2022, if possible.
In this interview, I would like to ask some questions about the reasons behind the channels, to understand the thoughts of the maintainers in addition to the written information.
The long goal of my PhD is to understand how communication works in GitHub projects and how a good set of communication channels and information for other maintainers and developers looks like. One possible outcome is a COMMUNICATION.md with instructions and tips about which channels could be useful and how these channels should be introduced to other projects participants. Of course, if you are interested, I will keep you up to date about any further results in my research.
If you are interested in doing an interview, please respond here or contact me via email (verena.ebert@iste.uni-stuttgart.de). We will then make an appointment for the interview at a time and date that suits you.
If you agree, I would like to record the interview and transcribe the spoken texts into anonymized written texts. In this case, I will send you the transcript for corrections afterwards. Only if you agree, the transcripts or parts of it would be part of a publication.

It's most likely out of date. Open source projects often lack free time to follow up such demands.
It's not that maintainers don't want to help, but rather that it is difficult to answer everyone. I suspect the owner receive a bunch of those via email[...].
regards,


Apparent react-router incompatibility

Re: https://github.com/pH200/cycle-react/issues/13, I could sorely do with a routing example.
Since cycle-react uses React to render, I figured I was limited to routers that specifically had React in mind. Specifically, I was looking for something that offered the usual nesting with children at each route component.
A minimal example with react, react-router, and cycle-react resulted in a strange rendering of the route string:

Is there a bug here, or am I just doing it wrong?

Sorry to say that but you're probably doing it wrong. You want the children from props. But, props.get will actually get you an Observable of that property. You need to combine that Observable into your view Observable to use it in JSX correctly.
// Wrong
return Observable.just(
props.get('foo')
);

// Do either this:
return props.get('foo').map(foo =>
{foo}
);
// Or this:
return props.map(({foo}) =>
{foo}
);

Here's the fix for your example:
https://gist.github.com/pH200/5e006b550f159a3af89d6d3f0d5cd8fd
Finally, I'll keep in mind that I need to write an example for react-router, too.

Thank you for that; I see what I was getting wrong. The gist you posted is already a pretty good example.


moan command should exit with correct exit code

Currently, moan is always exiting with exit code 0, even if there are errors. This means that if you're using npm scripts to invoke moan, then it will always pass where it should fail where appropriate.

This has been fixed and will be included in the v0.1.3 release.


Update meetings-policies-recording-and-transcription.md

https://github.com/MicrosoftDocs/OfficeDocs-SkypeForBusiness/issues/9100
Added link

@mkbond007 PR has been copyedited and is ready for final review, could you please check and merge? Thanks!

Docs Build status updates of commit 75f66a8:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

Teams/meetings-policies-recording-and-transcription.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Selfharm Linux deletes libpcre, so that find no longer works

Here is a screenshot
Selfharm Linux should not delete find and its libraries. Why? Because

skill issue
its doing what it's supposed to do

didn't ask


Bug: When inside of Tabs for react-native-router-flux, slides don't show until you begin to swipe

Is this a bug report or a feature request?
Bug report

Have you read the guidelines regarding bug report?
Yes.
Have you read the documentation in its entirety?
I'll be honest, probably not.
Have you made sure that your issue hasn't already been reported/solved?
I've done a very thorough check through the  issues with as many keyword searches as possible because putting together the reproduction steps for this was a PITA (though I completely appreciate why it has to be).
Is the bug specific to iOS or Android? Or can it be reproduced on both platforms?
I've only been testing on iOS.
Is the bug reproductible in a production environment (not a debug one)?
Yes, it still exists when the scheme for iOS is set to "Release".

Have you been able to reproduce the bug in the provided example?
I didn't try. I just created a fresh React Native project and installed the carousel (along with react-native-router-flux.
Environment
Environment:
React: 16.3.0-alpha.1
React native: 0.54.2
react-native-snap-carousel: 3.6.0
react-native-router-flux: 4.0.0-beta.28
Target Platform:
iOS (11.2)
Steps to Reproduce
When you put the carousel inside of <Tabs> for react-native-router-flux, the images don't show until you begin to swipe.

Clone out https://github.com/dwilt/react-native-snap-image-bug
Start the packager
Fire up a SIM for iOS (react-native run-ios)
Click on the Detail tab at the bottom

Expected Behavior

The images for the carousel would always be there - not just when I begin to swipe. This may be a react-native-router-flux problem but I wasn't sure so I'm posting here. Because it works on other pages in the app along with other components, I thought this really was probably a problem with this plugin. It seems like some sort of layout issue.
Notice below how you can see, when using the Inspector in the SIM, that the CellRenderer (flatlist-item-6) for the slide is visible in the SIM when I hover over the avatar.:

But when I hover over the next avatar CellRenderer (flatlist-item-7) that should be visible, notice where it is positioned invisible off the screen:

Actual Behavior

As described above, when you navigate to a <Tab> page, the carousel isn't displaying all of the slides correctly:

But, once you begin to swipe, they immediately pop back in:

Reproducible Demo
https://github.com/dwilt/react-native-snap-image-bug
I've put together a repo with the latest version of React Native, this plugin, and react-native-router-flux to demonstrate.

Hi @dwilt,
This looks like #238; I think you'll find some useful information there ;-)
To sum up: this is an unfortunate React Native bug. I've exposed two ways of dealing with:

triggerRenderingHack (offset) | Call this whenever needed to work around a random FlatList bug that keeps content hidden until the carousel is scrolled. Note that the offset parameter is not required and will default to either 1 or -1 depending on current scroll position.

useScrollView | Whether to use a ScrollView component instead of the default FlatList one. The advantages are to avoid rendering issues that can arise with FlatList and to provide compatibility with React Native pre- 0.43. The major drawback is that you won't benefit from any of FlatList's advanced optimizations. We recommend activating it only with a small set of slides and to test performance thoroughly in production mode.

Hello, one question. I have "snapToItem" to a high index, say 30, and it scrolls to the ninth position, and only after that loads the next items. Will triggerRenderingHack help in this case? If yes, when exactly should I call it? I'm calling before and after calling snapToItem, is there anything else I'm missing? :/


Unable to download flow from the Global Configurations

Tried launching via cloud formation in our us-east-1 region everything seems fine.
After trying it on the ap-southeast-1, I am unable to download the flow and are getting this error. Any advice as to how I can fix this?
2020-10-07T22:03:01.372+08:00Copy2020-10-07T14:03:01.371Z	b9b9-7288859b41c5	INFO	Error: { statusCode: 400,  body: '{"errorMessage":"Unable to build contact flow"}',  headers:   { 'Access-Control-Allow-Origin': '*',     'Access-Control-Allow-Credentials': true,     'Strict-Transport-Security': 'max-age=31536000; includeSubDomains',     'X-Frame-Options': 'DENY' } } | 2020-10-07T14:03:01.371Zb9-7288859b41c5 INFO Error: { statusCode: 400, body: '{"errorMessage":"Unable to build contact flow"}', headers: { 'Access-Control-Allow-Origin': '*', 'Access-Control-Allow-Credentials': true, 'Strict-Transport-Security': 'max-age=31536000; includeSubDomains', 'X-Frame-Options': 'DENY' } }
-- | --

Many Thanks!

After changing the fallback queue name to another one it downloads sporadically, However, I am seeing a failure in the media streaming from cloud watch.
{"ContactId":"643ba6c2-21fxxxxx","ContactFlowId":"xxxxxxee67de6","ContactFlowModuleType":"SetAttributes","Timestamp":"2020-10-07T14:57:59.044Z","Parameters":{"Value":"failure","Key":"startStreamingAudioStatus"}}
Any help would be much appreciated :)
Thanks

@RicoMokOR there are two things to check here. First, can you confirm that the name of the queue that is in the create contact flow modal exists in your instance? We do queue matching by name so if the queue doesnt exist it will fail. Second, can you look at the logs for the create contact flow lambda function and let us know what you see there?

@RicoMokOR were you able to check the name of the queue and the lambda function logs mentioned in the previous comment?


Is encryption planned?

AES-256/CHACHA20?

What part of the content needs to be encrypted? memo's content?

Yes, memo's content

Also not sure, why was this closed? See also #2161 #1480 which are closed without comments. @boojack could you please clarify the direction here?

I also wonder why this feature suggestion of all things is constantly being closed.


API Question/issue: How to close connection?

Hi,
Thanks again for a great plugin!
I'm struggling to find a proper way to close the connection in the APIs though after a stream is finished.
I've tried doing pClient->Shutdown() and assigning a nullptr to the pClient (pClient of course being the client received through the MakeClient call on the service). But I still get GOAWAY messages in the log after the stream is finished.
Here's an excerpt from the log showing the messages I get.
LogMYAPP: UgRPCDownloader::OnLiveStreamServiceContextChanged: State changed to Done. Closing connection. LogTurboLink: Destruct GrpcClient LogTurboLink: grpc:(E:\TurboLink\turbolink-libraries\Source\grpc\grpc-1.41.0\src\core\ext\transport\chttp2\transport\chttp2_transport.cc:1100)@xW:: Got goaway [11] err={"created":"@1685449280.543000000","description":"GOAWAY received","file":"E:\TurboLink\turbolink-libraries\Source\grpc\grpc-1.41.0\src\core\ext\transport\chttp2\transport\chttp2_transport.c c","file_line":1089,"grpc_status":14,"http2_error":11,"raw_bytes":"too_many_pings"} LogTurboLink: Error: grpc:(E:\TurboLink\turbolink-libraries\Source\grpc\grpc-1.41.0\src\core\ext\transport\chttp2\transport\chttp2_transport.cc:1111)Received a GOAWAY with error code ENHANCE_YOUR_CALM and debug data equal to "too_many_pings" LogMYAPP: UgRPCDownloader::OnLiveStreamServiceStateChanged: State changed to Idle.
Is the closing down of connections a missing feature, or have I missed something?

hmm...just found the ReleaseService function in the TurboLinkManager... maybe that was what I needed...? :)

Yes, calling UTurboLinkGrpcManager::ReleaseService will attempt to release the service and close the network connection.
But this process is not executed immediately. After calling ReleaseService, if the service is no longer used elsewhere, it will be set to PendingShutdown state, and this state will remain for 60 seconds. If there is no new use of this service within 60 seconds, the service will actually be closed. The closing of the socket link is more complicated, because grpc uses Channel to save the socket link with the grpc service, and there may be multiple different services sharing a channel. Only after all the services using this channel are closed, The channel will be destroyed and the socket connection will be closed.
But in most cases you don't need to care about these, just call that function。

Thanks for the answer. I guess the "bug" then is that maybe this should be mentioned in the README.md file how the proper procedure is for the closing or restart of services?

No problem, I'll update the docs when I have time. You can download another example project, which contains the code on how to close the service


Acme Integration

Add ACME into the integration for automatic cert renewal.

Come on guys. If Super Simple CA is supposed to be super simple, then it can't include an ACME monster with challenge support for HTTP-01, DNS-01, TLS-ALPN-01.

Come on guys. If Super Simple CA is supposed to be super simple, then it can't include an ACME monster with challenge types support for HTTP-01, DNS-01 and TLS-ALPN-01. But yeah, it can be a SPR-SMPL-01 challenge to simple integrated ACME 👍


What is the difference of the plugin compared to other plugins

I found another similar Maven Plugin that apparently does a similar thing.
Now I am not sure which one should I choose.
Is there some sort of comparison regarding this plugin and https://github.com/deviceinsight/helm-maven-plugin or https://fabric8.io/guide/mavenFabric8Helm.html?

https://github.com/deviceinsight/helm-maven-plugin/issues/75

https://github.com/deviceinsight/helm-maven-plugin/issues/75

Stale


Overwrite user agent (suffix included)

The problem
I'm currently using this library with GoogleMyBusiness. When my request is incorrect I get an error with status INVALID_ARGUMENT without the details.
{
  "error": {
    "code": 400,
    "message": "Request contains an invalid argument.",
    "status": "INVALID_ARGUMENT"
}

I investigated further and Google servers seems to skip the details if the user-agent include google-api-php-client. Here is the same request without the user agent
{
  "error": {
    "code": 400,
    "message": "Request contains an invalid argument.",
    "status": "INVALID_ARGUMENT",
    "details": [
      {
        "@type": "type.googleapis.com/google.mybusiness.v4.ValidationError",
        "errorDetails": [
          {
            "code": 10,
            "field": "photos.additional_photo_urls",
            "message": "Image too small. Got: 283px/200px (min: 250px/250px w/h).",
            "value": "XXXXXX",
            "subErrorCode": 21
          }
        ]
      }
    ]
  }
}

Much easier to debug ;)
Still this is a very odd move from Google to strip some information based on the user agent :(
The solution
Currently there is no way to completely overwrite the user agent set by the request.
Adding this to the config option would solve the problem.
https://github.com/googleapis/google-api-php-client/blob/master/src/Google/Client.php#L792
Alternative solution
Another solution is to create a new Class in the userland that extends Google_Client where we overwrite the execute() method.

Hi @Grafikart,
Thanks for bringing this to our attention. Could you share code which demonstrates the behavior you report? This will help us in making sure any changes we make address your specific concern.

Hi @Grafikart,
I think #1644 may help with this. Can you give it a shot, and if it doesn't address your concerns, feel free to reopen this and we'll investigate our options further.


Incorrect return type in api-brownie.rst for format_input

The docs currently state that format_input returns "Returns a list of values formatted for use by ContractTx or ContractCall."
However, it seems it actually returns an instance of brownie.convert.ReturnValue which inherits from tuple.
I have updated the docs in my PR #170 but was hoping to get a second set of eyes on this to make sure I'm not missing something.
For references, here's the output in my terminal.
>>> from brownie.convert import format_input
>>> abi = {'constant': False, 'inputs': [{'name': '_to', 'type': 'address'}, {'name': '_value', 'type': 'uint256'}], 'name': 'transfer', 'outputs': [{'name': '', 'type': 'bool'}], 'payable': False, 'stateMutability': 'nonpayable', 'type': 'function'}
>>> format_input(abi, ["0xB8c77482e45F1F44dE1745F52C74426C631bDD52","1 ether"])
('0xB8c77482e45F1F44dE1745F52C74426C631bDD52', 0)
>>> type(format_input(abi, ["0xB8c77482e45F1F44dE1745F52C74426C631bDD52","1 ether"]))
<class 'brownie.convert.ReturnValue'>

This all also applies to the format_output method.

I think it's a case of poor documentation, and maybe over-aggressive refactoring.

format_input performs type and bound checks, and standardizes formatting of user given data, before that data is encoded and used to call a contract.
format_output uses near identical logic to standardize the output from a contract call or transaction before returning it to the user.

Neither of these methods are intended to be called directly, they're used under the hood by _ContractMethod subclasses.  There is significant overlap in the logic of these functions, so to minimize duplicated code they are both returning a ReturnValue object.  I hadn't considered a user ever calling format_input directly and discovering the peculiar name of it's return type :astonished:
My thought here is that both of these methods (as well as format_event) should be made private.  Users can still convert data through the various to_xxx methods in brownie.convert if needed.  Alternatively, we could modify format_input to return a list or tuple so it's less confusing.
Thoughts?

I figured it was just a delay in updating the documentation. I think the code is fine exactly as is, the documentation just needs to be updated. PR #170 updates the documentation accordingly.
Sounds like the only advantage of making these private methods is just to be more explicit about the fact that these are not intended to be called directly? I'd be in support of that as a case could be made that the docs are a bit misleading on this by including an example to use the methods directly. Otherwise, I don't think it matters much. I like returning a ReturnValue object just fine.
Let's make a separate issue to make format_input format_output and format_event private methods. Otherwise, I think this issue can be closed once #170 gets merged.

I think this might be the start of a much broader discussion...  there is a lot of stuff in the docs that i mention as "you probably don't ever need to import or call this directly" - before taking the beta tag off, it would be good to add some underscores and explicitly make a lot of the API private.  Then the docs can include a new sub-section "private methods" or "internal methods" so the information is still there when people are hacking on brownie itself, but it's also more clear to casual users that here be dragons...

Okay good point I'll take another look at the docs in this context and see if I can think of a precise way to handle this.

I already do it a bit..  _config.py, _singleton.py - those are prepended to clearly tell people to stay out. There are probably a lot of other modules where none of the functionality is meant to face the user and rather than renaming a lot of methods we could just rename the whole file.


Bump cosmwasm dependency

please also update scripts/build_artifacts.sh workspace-optimizer to 0.15.1


Refactor WPF toggle visibility code

From an authoring side (constructing card programmatically using .NET library), the ToggleVisibility.TargetElements property was a list of objects, which is a bit confusing to a developer... they could place anything in there since it's just an object!

That's also tricky from a rendering side (how do you handle this non-strongly typed property).
I updated this to be strongly typed.

It still serializes and deserializes correctly (if there's only an ID specified, it serializes as a string). The unit tests verify this. And developers can use a string when authoring their card in C# too, thanks to implicit type conversion

Additionally, the code for actually toggling the visibility was contained within the renderer in a non-extensible way (meaning if a host wanted to use toggle visibility themselves, they would have to re-implment toggling the visibility themselves on the specified elements).

I updated this logic so that it's contained within the RenderContext, so that hosts can easily use this logic too.

Tested and verified by: All unit tests pass (and there's unit tests for both serialization and deserialization that validate both a string and object work correctly), and verified the sample payload in the WPF visualizer to confirm user functionality still works too.

So it looks like ToggleVisibility's effect is solely to change the Visibility property of the framework element associated with the specified Adaptive element Id. I just wanted to bring attention to a couple things:

Does the framework element include the target element's potentially visible separator? If not, then ToggleVisibility may result in an orphaned separator
Does setting the framework element's visibility trigger a re-layout of the card to make sure that bleeding elements bleed correctly? For instance, take the following payload:

{
    "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
    "type": "AdaptiveCard",
    "version": "1.0",
    "body": [
        {
            "type": "TextBlock",
            "id": "title",
            "text": "This is a TextBlock at the top of the card",
            "wrap": true
        },
        {
            "type": "Container",
            "style": "emphasis",
            "bleed": true,
            "items": [
                {
                    "type": "TextBlock",
                    "text": "This is a bleeding container",
                    "size": "extraLarge"
                },
                {
                    "type": "ActionSet",
                    "actions": [
                        {
                            "type": "Action.ToggleVisibility",
                            "title": "Click me",
                            "targetElements": [
                                "title"
                            ]
                        }
                    ]
                }
            ]
        }
    ]
}

Initially it renders like this:

Once the button is clicked, it should look like this:

Really excellent feedback David. I'll try that out. Note, however, that would be a separate issue (this code is already in master and I'm just trying to improve the API surface, so fixes to how the UI behaves would be a separate pull request).
We ought to make sure all these corner cases work in all our renderers, excellent attention to detail David :)

/AzureDevops run

Could you log an issue to track this feedback (it probably applies to UWP as well)?

In reply to: 475806958 [](ancestors = 475806958)

Thanks Becky, created the issue to track the separator/bleed concerns for all the renderers: https://github.com/Microsoft/AdaptiveCards/issues/2600


Created a Croatian translations

Hey @hdpero - thanks for contributing! Our translations (non English) are managed via Transifex and are pulled in periodically and these language files updated automatically.
I've created a Croatian (hr) language in the Transifex project. Would you mind entering your translations there instead? Thanks!
https://www.transifex.com/silverstripe/silverstripe-elemental/language/hr/

FYI I've just pushed an updated master file (English) which has a few new strings that were added recently.

Hi @robbieaverill I cannot "Join Team" and access Croatian language on Transifex. Could you please add me?

@hdpero I've accepted your join request - thanks :)


Missing tools (convert and etcpack)

I'm trying to build web samples but getting exception in toETC function in tools/texexport.py.
This is caused by missing convert and etcpack binaries in tools/linux folder.
UPD. I just commented to calls to the toETC function and started build again. Now I'm getting following error message:
IOError: [Errno 2] No such file or directory: '.../projects/fips_projects/fips-deploy/oryol-webpage/websamples.yml'

Probably it caused by problem with missing tools.

The websamples.yml file is created during a cmake. Try doing a './fips clean all' and then do another './fips webpage build'. I think this is a bug in oryol/fips-verbs/webpage.py, where the websamples.yml is deleted together with the oryol-webpage directory.
Looks like I forgot to add the precompiled ETC tools for Linux and Windows. I edited the ticket title accordingly.

'./fips clean all' helped, but:
/fips_projects/oryol$ ./fips webpage serve
[ERROR] FIXME: Linux not supported yet

:(

Ah I totally forgot about that. As a workaround you can start a local http server with 'python -m SimpleHTTPServer' in ../fips-deploy/oryol-webpage, and then in a webgl-capable browser, navigate to http://localhost:8000
I'll see if I can fix the not yet supported yet stuff right away.

I have added a fix for './fips webpage serve' for Linux (and Windows), let me know if it works for you. This uses xdg-open to open a http url in the default browser (tested on Linux Mint with Cinnamon desktop)


Return 0 if extension already installed

Fixes #6365

@joaomoreno just wanted to double check you're fine with it.

ping @joaomoreno


Release 5.0.0-RC1

Coverage remained the same at 95.455% when pulling dc321e014c7c5af2b5c4ae8441c61880a1a7fb5e on akkie:5.0.0-RC1 into eee87e682ce2b2ec29b61e1b91562525fceff960 on mohiva:master.


MBP 11,5 with Windows 10 - Blue screens on boot with Discrete enabled

No error, just big blue screen. Did any one get this setup working?

Looks like this project is dead. No updates, no fix to it being broken on Win 10 since 2016.

There's sadly not much we can do about that. All that gpu-switch does is enable some extra hardware by pretending to be osx, and in a way the project isn't dead but complete.
On certain hardware osx-mode might not be standards compliant or the Windows drivers might be buggy, causing bluescreens.


DebugInfo should have support for Components

Now that the components UI is being enabled by default we should enahnce DebugInfo to be able to support components as such information may be available in debug info files. Specifically, once those API changes are done, we should update the PDB Plugins and DWARF Plugins to leverage the updated API to create the appropriate components.

This is completed as of 3.6.4779-dev. We should open new issues to track PDB Import and DWARF Import support for components, if desired.


Referenced F# projects are not working

Simple repro:
dotnet new classlib --name f --language f# && \ dotnet new console --name c && \ dotnet add c/c.csproj reference f/f.fsproj && \ dotnet new sln && \ dotnet sln add f/f.fsproj && \ dotnet sln add c/c.csproj && \ dotnet build && \ code .
now add
f.Say.hello("foo");
into Main in Program.cs
dotnet run -p c/c.csproj
runs fine
However in vscode I get an intelisense error:
'The name 'f' does not exist in the current context [c]'

And the OmniSharp Log:
Starting OmniSharp server at 2017-11-8 15:22:25
Target: /mnt/code4/code4.sln
OmniSharp server started wth Mono
Path: /home/gleba/.vscode/extensions/ms-vscode.csharp-1.13.0/.omnisharp/run
PID: 3558
info: OmniSharp.MSBuild.Discovery.MSBuildLocator
Located 1 MSBuild instance(s)
1: StandAlone 15.0 - "/home/gleba/.vscode/extensions/ms-vscode.csharp-1.13.0/.omnisharp/omnisharp/msbuild/15.0/Bin"
info: OmniSharp.MSBuild.Discovery.MSBuildLocator
MSBUILD_EXE_PATH environment variable set to '/home/gleba/.vscode/extensions/ms-vscode.csharp-1.13.0/.omnisharp/omnisharp/msbuild/15.0/Bin/MSBuild.dll'
info: OmniSharp.MSBuild.Discovery.MSBuildLocator
Registered MSBuild instance: StandAlone 15.0 - "/home/gleba/.vscode/extensions/ms-vscode.csharp-1.13.0/.omnisharp/omnisharp/msbuild/15.0/Bin"
MSBuildExtensionsPath = /home/gleba/.vscode/extensions/ms-vscode.csharp-1.13.0/.omnisharp/omnisharp/msbuild
CscToolPath = /home/gleba/.vscode/extensions/ms-vscode.csharp-1.13.0/.omnisharp/omnisharp/msbuild/15.0/Bin/Roslyn
CscToolExe = csc.exe
MSBuildToolsPath = /home/gleba/.vscode/extensions/ms-vscode.csharp-1.13.0/.omnisharp/omnisharp/msbuild/15.0/Bin
TargetFrameworkRootPath = /usr/lib/mono/xbuild-frameworks
info: OmniSharp.Cake.CakeProjectSystem
Detecting Cake files in '/mnt/code4'.
info: OmniSharp.Cake.CakeProjectSystem
Could not find any Cake files
info: OmniSharp.DotNet.DotNetProjectSystem
Initializing in /mnt/code4
info: OmniSharp.DotNet.DotNetProjectSystem
Auto package restore: False
info: OmniSharp.DotNet.DotNetProjectSystem
Update workspace context
info: OmniSharp.DotNet.DotNetProjectSystem
Resolving projects references
info: OmniSharp.MSBuild.MSBuildProjectSystem
Detecting projects in '/mnt/code4/code4.sln'.
info: OmniSharp.MSBuild.MSBuildProjectSystem
Loading project: /mnt/code4/c/c.csproj
[fail]: OmniSharp.MSBuild.ProjectFile.ProjectFileInfo
The target "GetTargetPath" does not exist in the project.
/mnt/code4/c/c.csproj
    Update project: c

    Detecting CSX files in '/mnt/code4'.

    Could not find any CSX files

    Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.CSharpWorkspaceOptionsProvider

    Configuration finished.

    Omnisharp server running using Stdio at location '/mnt/code4' on host 3470.

@mrgleba : I cannot repro this on my Mac using your repro steps.

That said, I suspect that the problem you're running into is not related to this particular issue. Given the error in your project:
The target "GetTargetPath" does not exist in the project.
/mnt/code4/c/c.csproj

What Linux distro/version are you running?

I can repro on both Fedora 26 and Windows 10.

To be clear, this is a very different problem than this particular GitHub issue. :smile:

FWIW, I can repro the issue you're describing on OSX if I delete Mono. My theory is that additional MSBuild logic is required to process F# projects. The .NET Core SDK includes these MSBuild targets and tasks, but OmniSharp does not because OmniSharp is C#-only. So, in order to get this working, you should do one of the following:

On Fedora, upgrade to the latest Mono. OmniSharp will use Mono's MSBuild targets and tasks the version of Mono is 5.2.0 or greater. However, on Fedora 26, the available Mono is 4.8.0. You can install the latest CentOS 7 packages from http://www.mono-project.com/download/#download-lin-centos on Fedora 26.
On Windows 10, I'm guessing that you don't have any flavor of VS 2017 installed, correct? VS 2017 or the VS 2017 Build Tools would normally contain the F# support necessary. Try installing the VS 2017 Build Tools (https://www.visualstudio.com/downloads/#build-tools-for-visual-studio-2017) and be sure to check any boxes for F# when you do so.

I've done some digging on Linux.
After installing mono 5.4 Omnisharp throws an error complaining it's unable to load Microsoft.Build.Framework & Microsoft.Build. I've pulled those (tried 15.1 and newest) from nuget and now it throws
System.PlatformNotSupportedException: Operation is not supported on this platform.
at Microsoft.Build.Shared.BuildEnvironmentHelper.get_Instance () [0x00017] in <5452a999769d4e6a81de7a3aa0b8f9f1>:0
at Microsoft.Build.Shared.NativeMethodsShared.get_IsMono () [0x00033] in <5452a999769d4e6a81de7a3aa0b8f9f1>:0
at Microsoft.Build.BackEnd.Logging.LoggingService..ctor (Microsoft.Build.BackEnd.Logging.LoggerMode loggerMode, System.Int32 nodeId) [0x00039] in <5452a999769d4e6a81de7a3aa0b8f9f1>:0
at Microsoft.Build.BackEnd.Logging.LoggingService.CreateLoggingService (Microsoft.Build.BackEnd.Logging.LoggerMode mode, System.Int32 node) [0x00000] in <5452a999769d4e6a81de7a3aa0b8f9f1>:0
at Microsoft.Build.Evaluation.ProjectCollection.CreateLoggingService (System.Int32 maxCPUCount, System.Boolean onlyLogCriticalEvents) [0x00000] in <5452a999769d4e6a81de7a3aa0b8f9f1>:0
at Microsoft.Build.Evaluation.ProjectCollection..ctor (System.Collections.Generic.IDictionary2[TKey,TValue] globalProperties, System.Collections.Generic.IEnumerable1[T] loggers, System.Collections.Generic.IEnumerable1[T] remoteLoggers, Microsoft.Build.Evaluation.ToolsetDefinitionLocations toolsetDefinitionLocations, System.Int32 maxNodeCount, System.Boolean onlyLogCriticalEvents) [0x0011d] in <5452a999769d4e6a81de7a3aa0b8f9f1>:0    at Microsoft.Build.Evaluation.ProjectCollection..ctor (System.Collections.Generic.IDictionary2[TKey,TValue] globalProperties, System.Collections.Generic.IEnumerable1[T] loggers, Microsoft.Build.Evaluation.ToolsetDefinitionLocations toolsetDefinitionLocations) [0x00000] in <5452a999769d4e6a81de7a3aa0b8f9f1>:0    at Microsoft.Build.Evaluation.ProjectCollection..ctor (System.Collections.Generic.IDictionary2[TKey,TValue] globalProperties) [0x00000] in <5452a999769d4e6a81de7a3aa0b8f9f1>:0
at OmniSharp.MSBuild.ProjectFile.ProjectFileInfo.LoadProject (System.String filePath, System.String solutionDirectory, Microsoft.Extensions.Logging.ILogger logger, OmniSharp.MSBuild.Discovery.MSBuildInstance msbuildInstance, OmniSharp.Options.MSBuildOptions options, System.Collections.Generic.ICollection1[T] diagnostics, System.Collections.Immutable.ImmutableArray1[System.String]& targetFrameworks) [0x00017] in :0
at OmniSharp.MSBuild.ProjectFile.ProjectFileInfo.Create (System.String filePath, System.String solutionDirectory, Microsoft.Extensions.Logging.ILogger logger, OmniSharp.MSBuild.Discovery.MSBuildInstance msbuildInstance, OmniSharp.Options.MSBuildOptions options, System.Collections.Generic.ICollection`1[T] diagnostics) [0x0000a] in :0
at OmniSharp.MSBuild.MSBuildProjectSystem.LoadProject (System.String projectFilePath) [0x00038] in :0
My hunch is https://github.com/Microsoft/msbuild/commit/9654902b70e22eccc8105efdac5060c7d7adaa1a#diff-7dd0925e4fa31af6856e773c2c80a62c broke the IsMono on Linux.
What version of msbuild is shipped with omnisharp?

I've installed VS 2017 & build tools on Windows.
However omnisharpd doesn't seem to find them.
I've tried to set the MSBUILD_EXE_PATH variable but to no avail.

Linux:
It's not clear to me what you pulled from Linux and where you've put them. The NuGet version are not used on Linux because they are generally intended for Windows. Since you've got Mono 5.4 installed, I would have been interested to see your OmniSharp Log when it couldn't locate Microsoft.Build.dll.
Windows:
Setting MSBUILD_EXE_PATH variable won't be of help here. Instead, could your provide your OmniSharp Log on Windows?

Windows:
Starting OmniSharp server at 2017-11-9 14:33:55
Target: f:\code4\c
OmniSharp server started
Path: C:\Users\gleba.vscode\extensions\ms-vscode.csharp-1.13.0.omnisharp\OmniSharp.exe
PID: 10752
    Located 1 MSBuild instance(s)
        1: StandAlone 15.0 - "C:\Users\gleba\.vscode\extensions\ms-vscode.csharp-1.13.0\.omnisharp\msbuild\15.0\Bin"

    MSBUILD_EXE_PATH environment variable set to 'C:\Users\gleba\.vscode\extensions\ms-vscode.csharp-1.13.0\.omnisharp\msbuild\15.0\Bin\MSBuild.exe'

    Registered MSBuild instance: StandAlone 15.0 - "C:\Users\gleba\.vscode\extensions\ms-vscode.csharp-1.13.0\.omnisharp\msbuild\15.0\Bin"
        CscToolExe = csc.exe
        CscToolPath = C:\Users\gleba\.vscode\extensions\ms-vscode.csharp-1.13.0\.omnisharp\msbuild\15.0\Bin\Roslyn
        MSBuildExtensionsPath = C:\Users\gleba\.vscode\extensions\ms-vscode.csharp-1.13.0\.omnisharp\msbuild
        MSBuildToolsPath = C:\Users\gleba\.vscode\extensions\ms-vscode.csharp-1.13.0\.omnisharp\msbuild\15.0\Bin

    Detecting Cake files in 'f:\code4\c'.

    Could not find any Cake files

    Initializing in f:\code4\c

    Auto package restore: False

    Update workspace context

    Resolving projects references

    No solution files found in 'f:\code4\c'

    Loading project: f:\code4\c\c.csproj

    The target "GetTargetPath" does not exist in the project.

f:\code4\c\c.csproj
    Update project: c

    Detecting CSX files in 'f:\code4\c'.

    Could not find any CSX files

    Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.CSharpWorkspaceOptionsProvider

    Configuration finished.

    Omnisharp server running using Stdio at location 'f:\code4\c' on host 10132.

That's with the VS 2017 Build Tools installed?

Both VS 2017 and build tools (latest ver)

Hmmm.... IIRC, F# support is not installed by default. I believe that's a separate checkbox in the installer under "Individual Components". Did you install F# support with them?

Note: I've re-titled this issue and re-filed the original backlog item since the issue is pretty thoroughly hijacked by now.

C# and F# installed in both VS2017 and build tools

and MSBuild installed in VS2017

FWIW, I'm spinning up clean Windows 10 VM right now so I can try it with the build tools.

I was finnaly able to resolve on Linux.
After installing missing msbuild the assemlby load error was gone and the "GetTargetPath" error was back.
I was also missing the fsharp package.
After installing them everything is fine.
So perhaps on Windows the "GetTargetPath" message is also related to finding f# path?

I found the msbuild package as well and didn't realize that fsharp was different. Thanks for spotting that!
For Windows, yes, the problem is that it can't locate the MSBuild targets and tasks necessary for F#. Could you provide the OmniSharp Log on Windows for me now that you've installed the VS 2017 build tools?

The previous log was after everything was installed

Ah OK. Well, in that case, it looks like it isn't finding the install of the VS 2017 build tools at all. Hmmm...

I don't know if I understand the current solution. I'm on a mac. I just need to install standalone mono?

@mikehaas763 : Ensure that you install the full Mono MDK. You can do this using Homebrew using brew install cask mono-mdk or by downloading the latest installer from http://www.mono-project.com/download/#download-mac.

@DustinCampbell
Still have a problem with the f#. Is there any update on this issue?


Clean Xcode warning

Previous configuration produces the warning Run script build phase 'Compile Kotlin' will be run during every build because it does not specify any outputs. To address this warning, either add output dependencies to the script phase, or configure it to run in every build by unchecking "Based on dependency analysis" in the script phase., so the solution was to uncheck the proper box in Xcode UI.
The warning is visible on the presented screenshot and was visible in Report navigator tab in Xcode.

It's obviously a good idea to get rid of warnings, but I'm wondering whether essentially suppressing them is the desired way to go. Question to the team: Are there any technical limitations preventing us from correctly specifying the outputs for the "Compile Kotlin" build phase?


Autogenerating port names

if multiple ports are specified in a single service they have to be named. see https://kubernetes.io/docs/concepts/services-networking/service/#multi-port-services
We can make names optional and autogenerate them if no name is specified.
name: test

containers:
- name: nginx
  image: quay.io/tomkral/nonroot-nginx
- name: nginx2
  image: nginx

services:
  - name: test
    type: LoadBalancer
    ports:
      - port: 8080
        # default name: port-8080
      - ports: 80
        # default name: port-80

@kadel is this necessary?

@kadel is this necessary?

yes! Port name is required by kubernetes once you specify more that on port

@kadel TIL :+1:

Encountered this while trying out - https://raw.githubusercontent.com/containscafeine/fabric8-analytics-data-model/master/local-setup/docker-compose.yaml

picking this up

[bump] Encountered this while converting out - https://raw.githubusercontent.com/containscafeine/fabric8-analytics-data-model/master/local-setup/docker-compose.yaml

you can still convert that, it's not a blocker, you just have to explicitly set port names

@kadel yep, not a blocker, just bumped because I faced this :P


Add ordinal things

Please let me know if there are any issues

dude i dont see your folder pull

Please see request #381 as I had to merge to main branch on my fork to push. Thank you


cmd/gofmt: not supported by windows

What version of Go are you using (go version)?
go version devel +50c4dbc Wed Nov 23 00:44:01 2016 +0000 windows/386
What operating system and processor architecture are you using (go env)?
set GOARCH=386
set GOBIN=
set GOEXE=.exe
set GOHOSTARCH=386
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=c:\dev
set GORACE=
set GOROOT=c:\dev\go
set GOTOOLDIR=c:\dev\go\pkg\tool\windows_386
set GCCGO=gccgo
set GO386=
set CC=gcc
set GOGCCFLAGS=-m32 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\DOCUME~1\brainman\LOCALS~1\Temp\go-build246447175=/tmp/go-build -gno-record-gcc-switches
set CXX=g++
set CGO_ENABLED=1
set PKG_CONFIG=pkg-config
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
What did you do?
C:\dev\src\a>dir /b
foo.go

C:\dev\src\a>type foo.go
package main

import (
    "log"
    "os"
)

func main() {
    _, err := os.Stdin.Stat()
    if err != nil {
        log.Fatalln(err)
    }
}
C:\dev\src\a>go fmt
foo.go
chmod foo.go.662713035: not supported by windows
exit status 2

C:\dev\src\a>

What did you expect to see?
I expect to see no output from gofmt
What did you see instead?
gofmt failed with error message. Chmod is not implemented on Windows, so it is failing.
Alex

@griesemer, this is a regression from your #8984 fix (b188b4cc110261a004674df5a4e209cc4894d314).

Actually, just sent https://go-review.googlesource.com/33477


UpdateVersion help

Hello, I've been learning how to use GPOs recently. I'm trying to manually add policies for startup/shutdown and user login/logout. I manually created the startup directory and scripts.ini file, among other things. However, I'm facing difficulties in updating the version number and enabling script settings. Can I accomplish this step using pyGPOAbuse?

Hello,
You can use code from this project, but the project itself won't help you, as it updates lots of other stuff you don't want.
https://github.com/Hackndo/pyGPOAbuse/blob/63db4a415dad189c5762e6aff2d7bad2ac65039c/pygpoabuse/gpo.py#L79-L135


Release with lsp-types 0.94.0

Hello!
Thank you for your library!
lsp-types 0.94 provides position_encodings in GeneralClientCapabilities.
I was wondering if it would be possible to have a  new tower-lsp release.

Yes! I added support for position encodings to lsp-types 0.94 myself (see upstream PR), among other things, with the intention of updating tower-lsp to support LSP 3.17. A new release of tower-lsp is forthcoming; thank you for your patience!

Thank you!:)


Cannot see npm install progress

When I use within VS Code, the extension works but it does not show the npm install progress that happens. Is this a known issue? I tested this with multiple generators and got the same.
Thanks!

You should see a spinner in the bottom left corner.

I meant textual output like how you would get in a console/terminal with the npm progress bar.

I will have to check. But the issue with the npm progress bar is that it uses ANSI escape codes to update the progress. The output channels in VS Code don't support these so I think it won't look nice if I'm able to forward to output to the channel. Not sure about this though because I forward everything from console.log to that screen...


Remove case that caused external PR's CI to fail.

Perhaps, we can try fixing the underlying issue when external users try to commit code.
The ci-auto-commit-linux.yml fails in Commit requirement changes step as follows, due to permission denied to github-actions[bot] to make an auto-commit.
For example, see: https://github.com/huawei-noah/SMARTS/actions/runs/3524433333/jobs/5910631705Warning: Couldn't fetch author email, filling with github_actor.
> Using 'Changhe Chen<EMAIL_ADDRESS>as author.
> Using "GitHub Actions: Update requirements.txt" as commit message.
> Running for a PR, the action will use 'develop' as ref.
Internal logs
Outputs
Error: Error: Pushing to https://github.com/huawei-noah/SMARTS
remote: Permission to huawei-noah/SMARTS.git denied to github-actions[bot].
fatal: unable to access 'https://github.com/huawei-noah/SMARTS/': The requested URL returned error: 403


imp: represent unlimited approvals with a nil value

Description
This PR implements the changes proposed in https://github.com/cosmos/ibc-go/issues/3452

closes: #3452
Commit Message / Changelog Entry
imp(statemachine)!: represent unlimited approvals with a nil value

see the guidelines for commit messages. (view raw markdown for examples)

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against correct branch (see CONTRIBUTING.md).
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Code follows the module structure standards and Go style guide.
[ ] Wrote unit and integration tests.
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/).
[ ] Added relevant godoc comments.
[ ] Provide a commit message to be used for the changelog entry in the PR description for review.
[ ] Re-reviewed Files changed in the Github PR explorer.
[ ] Review Codecov Report in the comment section below once CI passes.

I agree with the risk described above by @chatton.
And besides that, and after discussing also with @womensrights, we think that it is risky to not specify the unlimited spending for a particular denomination. With the approach of using nil (or even the sentinel value) the authorisation would grant the grantee the possibility to spend without any limits any denomination. We think that it would be safer to follow an approach closer to what Ethereum does and use the maximum Int value for Amount in sdk.Coin to indicate unlimited spending for a particular denomination. What do you think?

Codecov Report

Merging #3454 (87daf70) into main (7987251) will increase coverage by 0.01%.
The diff coverage is 100.00%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3454      +/-   ##
==========================================
+ Coverage   78.78%   78.79%   +0.01%
==========================================
  Files         182      182
  Lines       12687    12693       +6
==========================================
+ Hits         9995    10001       +6
  Misses       2261     2261
  Partials      431      431

Impacted Files
Coverage Δ

...ules/apps/transfer/types/transfer_authorization.go
92.13% <100.00%> (+0.56%)
:arrow_up:

Looks like some unit test is failing 👀 Will take a closer look later today

Thanks for all the work on this one, @Vvaradinov! I opened a PR with an idea suggested by @damiannolan and @colin-axner (making maxUint256 un-exported and adding an exported function to retrieve it) and updating the documentation.


Bug Icon functions should be split up

Originally filed by @abuehrle in service repo:
The bug icon contains a number of functions, which might be more easily found by users, if they are split up and some of them added to a new download icon.
For example, the bug icon could contain these items:

Reset your local view state and reload the page (I could argue that this could go right on the toolbar)
Report a bug (and this could actually go on a support type page with a field for user input -maybe on settings)

Add a download icon

to include these items:

Save raw data as JSON
Save canvas as SVG (does not include search highlighting)

In my mind a JSON file or an SVG may not be about troubleshooting.  Perhaps a user wants to pipe his JSON to another app or maybe he wants to just send the SVG to another user without inviting them to the instance.

Duplicate of #2475


Implement solution for standalone ooth, api, next.js

The current next.js solution uses ooth, api and next.js server all in one. This means that only one cookie-session is needed. But if ooth and api are separate, 3 cookie-sessions are needed, + the server needs to be able to communicate with ooth and api (on the server side probably JWTs are better). Both ooth and the next.js implementation need to be extended to support that.

of course, it would be ideal if an ooth standalone was dockerized, obviously related to pr #26

Hey @chase-moskal I think the most complex part of this (and the main reason why I haven't implemented this) is configuration. How do you configure your own version of ooth with your own plugins with their own configs, but pack it in a standardized docker image? I don't really know a good strategy to do this.

@nmaro — i think it's a really interesting topic.. bear with me as i'm not highly experienced with docker but i think i grasp the principal — here's some of my thinking about it

i believe we could create an ooth-standalone base docker image

devs could then make their own my-ooth-app docker image, which extends the ooth-standalone base image

my-ooth-app can then copy in various configurations and plugins
COPY ooth-config.json /ooth/           # copy in project ooth config
COPY ooth-plugins/ /ooth/ooth-plugins/ # copy in project ooth plugins
CMD ["ooth-standalone"]                # start running the ooth app

i'm imagining that there'd be a standard ooth-standalone docker-compose file which lays out the other containers which are networked together with the ooth-standalone container, such as a mongodb container for the database, etc

i'm guessing the dev would copy this docker-compose file and modify it, to use my-ooth-app as the docker image in place of ooth-standalone — then they are free to replace other images like the one for mongodb or add other ones that work with their plugins, etc

for those who are not using docker

ooth-standalone could also be distributed as an npm package which acts as a cli tool, allowing the user to pass a config file and plugins directory

ooth-standalone --config="ooth-config.json" --plugins="ooth-plugins/"

Hey @chase-moskal I pushed my own dockerized examples:
https://github.com/nmaro/ooth/tree/master/examples/standalone
https://github.com/nmaro/ooth/tree/master/examples/integrated
(read the readme in ooth-standalone). For now there are no published standard images (the builds are all local), but it's a start. To a certain degree it could be argued that a standard ooth image is not needed because it's basically just about importing the library and configuring it.
If you have ideas for where to go from there create a new issue, since this is about next.js.


Add a code action to initialize or set structure fields in C

First of all, thanks for this good extension. 👍
I'm using Vscode + vscode-clangd + EIDE to write the C for STM32, It works very well.
I want a feature, but I don't know where to look for the answer, so try my luck here. :)
The feature:
There is a struct type:
typedef struct {
  uint8_t as;
  uint8_t tb;
  uint8_t kk;
  uint8_t la;
  // .... more members
} Gtid_t;

There is a variable:
Gtid_t Gg;

Is there a way to quickly generate the following code, to "expand" struct members to fill:
Gg.as = as;
Gg.tb = tb;
Gg.kk = kk;
Gg.la = la;
// .... more

I found some information here for vim.
Any help for vscode, please tell me, thanks! :)

Moved to clangd repo since support for a code action like this would have to be implemented on the server side.
For C++, a somewhat similar code action that exists is to generate a memberwise-constructor (you can then use code completion to get clangd to help you write a call to that constructor, with placeholders for the arguments).
For C, as an alternative to assignment, a code action could generate designated initializers, something like this:
Gtid_t Gg {
  .as = <placeholder>,
  .tb = <placeholder>,
  .kk = <placeholder>
};

Hello, I just had to fill a lot of structures from one to another, for H.264, and it was very annoying that clangd doesn't help with this.
rust-analyzer has such code action to fill struct fields, which generates:
Foo {
   [perform code action: fill struct fields]
}

Foo {
   a: todo!(),
   b: todo!(),
}

It would be great of clangd supported similar for the designated initialisers in both C and C++
My suggestion is to do the following:
Foo foo = {
   [perform code action: fill struct fields]
}

Foo foo = {
   .a = {},
   .b = {},
}

Using {} as a placeholder should work in both C and C++ for pretty much all types? It is also easy to regex replace in the editor.
Although for C it was added only recently in C23, but should work okay if compiler is new enough, it will just produce a warning on older standards.


Use document.title and ⏳ emoji to indicate when work is being done

Solution for #644
Listens to changes in the loading status within the Compress component. If a change in loading status is detected and something is loading, append a ⏳ emoji to the document.title
GIFs
Classic example w/ the famous Lenna  test image. See that the document.title updates as the image compresses

Another example w/ the provided photo.jpg. Notice that at a point, both sides are loading/doing work (apologies, had to resize GIF to meet Github's size requirements and Squoosh doesn't support animations 😉)

Starting  to get into open source and thought this was a neat issue. Also think it would be neat to explore using the document.title to output an error emoji in the title like 🚨

@googlebot I signed it!

This has ben reviewed, but the review has not been addressed. @WilhelmWillie, do you still want to work on this or should we close it out?

@surma Hi! I apologize, got busy over the past year and never got around back to this. I'm still down to work on this, I can try over the weekend and address those previous comments


Renaming NetworkRequest protocol?

I've been thinking about this for a while and wanted to open up discussion. I've personally never really been a fan of the Any...<T> convention used for type-erased structs. Instead of AnyNetworkRequest<T>, I think it would be nicer to be able to just write NetworkRequest<T>. To accomplish this, we would need to rename the NetworkRequest protocol to something else. Some ideas I have are:

RequestRepresentable
NetworkRequestRepresentable
NetworkRequestProtocol

This would of course be a breaking change so it'd likely go into a 2.0.0 release. See the examples below for a peak of how this might look.
Defining something that conforms to RequestRepresentable:
struct CreatePostRequest: RequestRepresentable {
    // Define the model we want to get back
    typealias ResponseType = Post
    typealias ErrorType = AnyError

    // Define NetworkRequest property values
    var method: HTTP.Method = .post
    var url = URL(string: "https://jsonplaceholder.typicode.com/posts")!
    var queryParameters: [URLQueryItem]?
    var headers: [HTTP.HeaderKey: HTTP.HeaderValue]? = [.contentType: .applicationJSON]
    var body: Data? {
        let encoder = JSONEncoder()
        return try? encoder.encode(newPost)
    }

    // Define any custom properties needed
    private let newPost: NewPost

    // Initializer
    init(newPost: NewPost) {
        self.newPost = newPost
    }
}

Using NetworkRequest<T>:
let createPostRequest = NetworkRequest<Post>(method: .post,
                                             url: URL(string: "http://jsonplaceholder.typicode.com/posts")!,
                                             headers: [.contentType: .applicationJSON],
                                             body: postBody)

I like the idea a lot, my only reservation is moving away from the example of the standard library with AnyHashable.
I can be convinced either way.

Yeah, I've thought about that too. Apple has kind of made "Any" the standard here. Maybe even shortening to AnyRequest<T> instead of AnyNetworkRequest<T> (change NetworkRequest protocol to just Request as well) would be somewhat of an improvement.

Is this something we want to try and include for 2.0?

I think so. I'd like more people to weigh-in with their thoughts though.

I could get onboard with dropping the "Any".

So far I'm leaning towards:

NetworkRequest protocol --> RequestRepresentable
AnyNetworkRequest<T> struct --> Request<T>

Anyone else have any opinions? @BottleRocketStudios/ios-developers

To provide a bit of pushback, I believe the intended purpose is to differentiate naming a specific, concrete implementation of a protocol from the general idea of the protocol. I do agree that seeing Any as a prefix all over the place is ugly, so maybe there's some other way to convey the desired semantic meaning without resorting to a prefix.
It seems like above we're moving towards calling out the protocols instead of the concrete implementations. Could make a lot of sense.

I'm going to play devil's advocate here and suggest the following (taking the API naming guidelines into account strictly):
NetworkRequest -> Request
AnyNetworkRequest<T> -> AnyRequest<T>

I like the idea of:
NetworkRequest ->Request
AnyNetworkRequest<T> ->AnyRequest<T>
Apple seems pretty consistent with their naming of type-erased values and I think retaining that consistency is a good idea.

Under review in #52

Merged in #52


async_hooks-based tracing doesn't work for gRPC server

From #656
@mrene wrote:

I have a similar issue (node 8.9.4, async/await with GCLOUD_TRACE_NEW_CONTEXT, grpc 1.7.3 server) - I get valid traces for the first call and then I start seeing grpc: Cannot create nested root spans.
I then added some more tracing inside my own methods and I started seeing Custom Span API: creating child for an already closed span ... grpc:/.... After a while, when the traces get pushed, I get another valid trace then the same errors repeat themselves.
The errors relating to the custom spans are reported because cls.getRootContext() returns a span that is closed (the span from the last call). Debugging this into cls-ah revealed some weird behaviour between grpc-native-core and async_hooks. Every root span gets created while both the executionAsyncId and triggerAsyncId are 0; the before callback also does not execute before handling a new call and therefore the context variable within cls-ah points to the last used context.
cls-ah seems to do the following:

maintain a global context object which is used as cls
maintain a hash of context objects, indexed by executionAsyncId
whenever an init event occurs:

copy the current global context object into the hash (regardless of the parent id specified by the callback)

whenever an enter event occurs:

if the hash contains the entered id, set the global context object to its content

In this scenario, because we're lacking an enter, the first grpc call trace is valid because the context object is initially initialized to {} and we process to creating a root span because the context doesn't contain any previous root span. Upon the 2nd call, the context still contains the previous root span (in a closed state), only errors arise. When the traces get flushed, an enter event occurs and sets the global context object back to its initial value (because the trace writer context was created before the first grpc call, so it copied the initial value).
At this point this looks more like a grpc bug although it could either be handled in the plugin (using the AsyncResource API or within grpc-native-core - I'm sure there's a param to carry over execution context ids when switching from native->js).

It seems the AsyncHooks embedder's api hasn't landed in NAN yet (nodejs/node#13254) so a JS fix is the only possible option.
I've got a hacked up version of the plugin to validate the entire hypothesis and it patches the problem.
I'd like to get some of your opinions before opening a PR, got some comments/questions here:

Copying the current context from init might not be the right thing, since init can happen on its own without enter

Part of the problem is that contexts created after the first span directly inherit it even if they don't share a parent context
Every async context will probably point to the same object

context is set back to its original value in runAndReturn but as soon as more get created, they will be set back (through before and init) and the original value will not be restored.
This could be mitigated by implementing after() and resetting values accordingly.

This feels like it emitDestroy() could be called by span#endSpan() since it basically knows whenever it's done
runAndReturn() should probably set contexts[uid] as well as context

What do you think?

@kjin wrote:

@mrene Thanks for investigating the async_hooks-based tracing issue! Please go ahead and open the PR.
I've been thinking through the observations you had, here are my thoughts so far:

Copying the current context from init might not be the right thing, since init can happen on its own without enter

Copying the current context in init is necessary to preserve it across asynchronous boundaries. Maybe I'm misunderstanding what you're saying?

Part of the problem is that contexts created after the first span directly inherit it even if they don't share a parent context
Every async context will probably point to the same object

I think you were correct in creating a new AsyncResource for each request being handled, so that subsequent requests after the first one don't point to the same object.

context is set back to its original value in runAndReturn but as soon as more get created, they will be set back (through before and init) and the original value will not be restored.
This could be mitigated by implementing after() and resetting values accordingly.

I believe implementing after() to reset context would effectively be a no-op, since before() will run anyway for the next async resource. Would you be able to further articulate what the potential problem could be here? EDIT: See new comment.

This feels like it emitDestroy() could be called by span#endSpan() since it basically knows whenever it's done

I'm open to (and for this and other reasons, actively thinking about) the idea of creating our own AsyncResource object for root spans and emitting the lifecycle events correspondingly. Let's talk about it in a separate issue (please feel free to open it if I haven't already).

runAndReturn() should probably set contexts[uid] as well as context

What should contexts[uid] be set to?

@mrene After looking into it more, I believe your reasoning is correct that after should be implemented to reset the previous context.
I'll open a PR to implement after soon-ish, probably tomorrow, and gRPC server tracing should just work (with NEW_CONTEXT-based tracing, at least) without need for additional changes to the plugin. That being said, it might still make sense for you to open a PR against gRPC to add async_hooks embedder support. (if you feel motivated; I can do it as well 😄 )

@mrene wrote:

Copying the current context in init is necessary to preserve it across asynchronous boundaries. Maybe I'm misunderstanding what you're saying?

I mean init shouldn't be constructed as before - the runtime isn't switching to it yet. one of its argument is the triggerAsyncId. I agree that the context should be copied, just that it should be copied from contexts[triggerAsyncId] rather than the context global var being set at that moment. (In most cases those will be the same but it's possible to pass another parent in the async_hooks API)

What should contexts[uid] be set to?

The same thing, basically context = contexts[uid] = {}; whenever it is being initialized. This would make sure that the context is preserved if an enter event to the same context occurs afterwards. It'll give that context its own object, which it doesn't have now (only context initialized while this one is active will be correctly linked).
Thinking about this more makes me realize that running this without creating another AsyncResource could cause the same id to be re-used twice, so it might not be advisable until this is implemented.
I noticed a small difference in behaviour with continuation-local-storage, it does not store any data unless the current context has been activated, whereas cls-ah initializes an empty object so things can technically be saved/fetched even if runAndReturn hasn't been called. Nothing critical but it might hide subtle bugs.

Are you also looking at creating a new async resource id for every span or is this another topic?

Adding a new async resource ID is only necessary in lieu of async_hooks integration for modules like gRPC which bypass networking within Node.js. Given that async_hooks support lands for gRPC (see: https://github.com/grpc/grpc-node/pull/169) I don't think this is necessary at the moment, given that it potentially adds significant overhead/ code complexity.
You also mentioned using triggerID by default instead of the ID of the context in which the init hook is running -- this makes sense to me now, and as I said before I've been experimenting with async_hooks to make sure this behavior doesn't break anything and is what we want. I should have a PR for this soon unless something goes awry (however, I don't believe it will affect the gRPC server tracing use case)

@mrene We've made some changes to async_hooks-based tracing, including your suggestion about using triggerId. I expect gRPC server tracing to work for the following triplet of versions:

@google-cloud/trace-agent 2.9.0+ made the changes as noted above.
grpc 1.11.0+ contains patches to preserve execution ID across native boundaries.
node 9/10 (not sure which minor version, the newest one probably to be safe) is required for the changes in grpc to be apparent, so that the execution ID of 0 isn't observed anymore.

Support for Async Resource propagation in Nan works for Node 9.0+

@kjin what's the status for this?

I am working on a monkeypatch for Node 8 or gRPC <1.11.

After the recent investigation, I found that #734 already fixed this bug. This means that v2.9.0 should work for gRPC server tracing for all versions of Node.
The reason for this is because:

There are two continuations of interest in gRPC servers: call handlers and stream event handlers.
Both of these run with an async execution ID of 0 in Node 8, which used to cause problems.
The reason this caused problems originally was because we relied on the before hook to switch contexts. As @mrene pointed out in an earlier post, this hook wouldn't be triggered for gRPC, so the last-used context would be used instead for either of these handlers.
This behavior was changed in #734, as we stopped relying on the before callback entirely. Now, even though call handlers and stream event handlers still run with an async execution ID of 0, tracing should now work properly because:

for call handlers, the value of the root span context stored under 0 will never be stale, so it will never appear as if can't start a new root span because one already exists.
for stream event handlers, we already use TraceAgent#wrapEmitter to propagate context correctly.

Our tests used to circumvent the problem by clearing root context, but this was changed in #753 (see changes made to test-trace-grpc.ts), so we now have some measure in place for ensuring that no future regression occurs.


Some small preparation towards eliminating the SDoc field from ParseError

In this PR, we lift a new function failOpParseModuleEx, lifted out of parseModuleEx. The intent is to then split this function into two cases, preferring to construct ParseError values from GHC ParseFailed _ values when they exist else fall back on the standard HSE implementation. Doing that will no doubt involve updating test results (error strings will change). In any case, at that point we'll then eliminate the SDoc field from ParseError (which will remain unused up to its elimination). Tests pass and no new behaviors are introduced.

Thanks! I did a clean up pass after, let me know if I screwed up anything you were hoping for.


Set NO_COLOR and NO_TTY for TF cli

Tested and it resolved issues when running newa in Gitlab CI pipelines.

Thank you. Merging so that we won't block users.