deviousasti

deviousasti

Functional | Rx | Hardware

Member Since 9 years ago

Experience Points
30
follower
Lessons Completed
11
follow
Lessons Completed
170
stars
Best Reply Awards
41
repos

129 contributions in the last year

Pinned
⚡ Minimalist statemachine library for F#
⚡ Easily create a shell for your existing .NET APIs
⚡ Visual Studio Linter for F#
⚡ Visual Studio Formatter for F#
⚡ A spreadsheet-like interactive evaluator for F#
⚡ A zero configuration continuous build bot
Activity
Dec
2
4 days ago
started
started time in 3 days ago
Nov
30
6 days ago
started
started time in 5 days ago
Nov
22
2 weeks ago
started
started time in 1 week ago
Activity icon
issue

deviousasti issue comment fsprojects/fantomas-for-vs

deviousasti
deviousasti

Migrate to Fantomas.Client

Hey @deviousasti,

I've released a first version of Fantomas.Client, this is the proposed solution for https://github.com/fsprojects/fantomas/issues/1844.

A first editor implementation was recently merged in FsAutocomplete.

The main idea is that you reference Fantomas.Client and create a new LSPFantomasService instance and use the API in FantomasService to handle formatting requests.

Each request will give you a FantomasResponse which contains a FantomasResponseCode. Based on that code, you will know how to process the response. The FantomasService will handle proxy each request to the right compatible version of fantomas-tool.

I've written a bit of documentation here, hopefully, that helps.

Let me know if you have any further questions.

deviousasti
deviousasti

I'm onboard with shipping the extension for VS2022 early. There are not too many users at this point. I'll use it continuously at work to find out any issues. VS19 should behave identically.

Some things for a minimum build:

  • I'm pretty sure we need to dedupe requests to the server. Is there a standard mechanism.
  • How do we plan to deal with the server process crashing?
  • How do I cancel an existing formatting request?
push

deviousasti push fsprojects/fantomas-for-vs

deviousasti
deviousasti

Finish migration to Fantomas.Client (#25)

  • Initialize Fantomas.Client on package initialization

  • Remove Fantomas options that Fantomas.Client loads from .editorconfig

  • Remove warm up logic (was unused, not compatible with Fantomas.Client)

  • Use Fantomas.Client for formatting

commit sha: 7cd79ae07df46419f9b801e902ac529d9a94920d

push time in 1 week ago
pull request

deviousasti merge to fsprojects/fantomas-for-vs

deviousasti
deviousasti

Finish migration to Fantomas.Client

deviousasti
deviousasti

Thank you! This is great. Merging!

Activity icon
created tag
createdAt 1 week ago
Nov
21
2 weeks ago
pull request

deviousasti merge to fsprojects/fantomas-for-vs

deviousasti
deviousasti

Finish migration to Fantomas.Client

deviousasti
deviousasti
open pull request

deviousasti wants to merge fsprojects/fantomas-for-vs

deviousasti
deviousasti

Finish migration to Fantomas.Client

deviousasti
deviousasti

Add braces for block level scope.

open pull request

deviousasti wants to merge fsprojects/fantomas-for-vs

deviousasti
deviousasti

Finish migration to Fantomas.Client

deviousasti
deviousasti

Will this ever throw? Should we add a try-catch?

open pull request

deviousasti wants to merge fsprojects/fantomas-for-vs

deviousasti
deviousasti

Finish migration to Fantomas.Client

deviousasti
deviousasti

Can we add named arguments here everything is an int - debugging issues when contracts change is hard. 😅

open pull request

deviousasti wants to merge fsprojects/fantomas-for-vs

deviousasti
deviousasti

Finish migration to Fantomas.Client

deviousasti
deviousasti

LSPFantomasServiceTypes.FantomasResponseCode could use a type alias.

pull request

deviousasti merge to fsprojects/fantomas-for-vs

deviousasti
deviousasti

Finish migration to Fantomas.Client

deviousasti
deviousasti
Activity icon
issue

deviousasti issue comment fsprojects/fantomas-for-vs

deviousasti
deviousasti

Finish migration to Fantomas.Client

deviousasti
deviousasti

Thank you! It's very hard to quantify the impact of a big PR. Let me review.

Activity icon
issue

deviousasti issue comment fsprojects/fantomas-for-vs

deviousasti
deviousasti

Finish migration to Fantomas.Client

deviousasti
deviousasti

Hi @bddckr, thank you for starting work on this migration. It's peak season for me at work, leaving me with little time to spare now. Things should definitely ease up the week after Thanksgiving.

I'd like to scope this PR to be migration to Fantomas Client - changing the UX should be a separate PR. The present scope should replacing the current in-process stable backend with Fantomas Client.

Nov
18
2 weeks ago
pull request

deviousasti merge to jet/equinox

deviousasti
deviousasti

Cosmos: Refactor init logic

Long overdue cleanup in CosmosStore - initial logic was intentionally matching V2 init logic, but it can be clarified now based on:

  • support for Autoscale from @belcher-rok
  • the V3 SDK has Database and Container objects where V2 did not
open pull request

deviousasti wants to merge jet/equinox

deviousasti
deviousasti

Cosmos: Refactor init logic

Long overdue cleanup in CosmosStore - initial logic was intentionally matching V2 init logic, but it can be clarified now based on:

  • support for Autoscale from @belcher-rok
  • the V3 SDK has Database and Container objects where V2 did not
deviousasti
deviousasti

Do we need this async block at all?

Nov
17
2 weeks ago
push

deviousasti push jet/equinox

deviousasti
deviousasti

Equinox.Tool: Add support for Cosmos Autoscaling (#302)

Adds an --autoscale/-A switch to the eqx tool to enable support for the Autoscaling feature of Cosmos Containers and Databases. Specifying this flag causes the --rus parameter to be interpreted as "Maximum RU/s" and changes the default value to 4000 RU/s, the minimum value allowed by Cosmos.

commit sha: abb33668c78e566b10f14a686938c3c3ff248598

push time in 2 weeks ago
pull request

deviousasti pull request jet/equinox

deviousasti
deviousasti

Equinox.Tool: Add support for Cosmos Autoscaling

Adds an --autoscale/-A switch to the eqx tool to support autoscaling throughput of Cosmos containers and databases. Specifying this flag causes the --rus parameter to be interpreted as "Maximum RU/s" and changes the default value to 4000 RU/s (the minimum MaxRUs value allowed by Cosmos).

There are no changes to existing behavior. The Propulsion tool is also unaffected.

There are breaking changes in the Equinox.CosmosStore.Core.Initialization.init function, specifically the mode parameter's Provisioning type had its rus members changed to Throughput type. The initAux function remains unchanged.

There is no plan to update the Propulsion tool since the minimum RU/s in both Manual and Autoscale mode is 400 which should be fine for the vast majority of 'aux' containers.

pull request

deviousasti merge to jet/equinox

deviousasti
deviousasti

Equinox.Tool: Add support for Cosmos Autoscaling

Adds an --autoscale/-A switch to the eqx tool to support autoscaling throughput of Cosmos containers and databases. Specifying this flag causes the --rus parameter to be interpreted as "Maximum RU/s" and changes the default value to 4000 RU/s (the minimum MaxRUs value allowed by Cosmos).

There are no changes to existing behavior. The Propulsion tool is also unaffected.

There are breaking changes in the Equinox.CosmosStore.Core.Initialization.init function, specifically the mode parameter's Provisioning type had its rus members changed to Throughput type. The initAux function remains unchanged.

There is no plan to update the Propulsion tool since the minimum RU/s in both Manual and Autoscale mode is 400 which should be fine for the vast majority of 'aux' containers.

deviousasti
deviousasti

Looks good. Will merge after you force-push.

pull request

deviousasti merge to jet/equinox

deviousasti
deviousasti

Equinox.Tool: Add support for Cosmos Autoscaling

Adds an --autoscale/-A switch to the eqx tool to support autoscaling throughput of Cosmos containers and databases. Specifying this flag causes the --rus parameter to be interpreted as "Maximum RU/s" and changes the default value to 4000 RU/s (the minimum MaxRUs value allowed by Cosmos).

There are no changes to existing behavior. The Propulsion tool is also unaffected.

There are breaking changes in the Equinox.CosmosStore.Core.Initialization.init function, specifically the mode parameter's Provisioning type had its rus members changed to Throughput type. The initAux function remains unchanged.

There is no plan to update the Propulsion tool since the minimum RU/s in both Manual and Autoscale mode is 400 which should be fine for the vast majority of 'aux' containers.

pull request

deviousasti pull request fsprojects/fantomas-for-vs

deviousasti
deviousasti

Fantomas Client Migration Epic

Finishing up #21

open pull request

deviousasti wants to merge jet/equinox

deviousasti
deviousasti

Equinox.Tool: Add support for Cosmos Autoscaling

Adds an --autoscale/-A switch to the eqx tool to support autoscaling throughput of Cosmos containers and databases. Specifying this flag causes the --rus parameter to be interpreted as "Maximum RU/s" and changes the default value to 4000 RU/s (the minimum MaxRUs value allowed by Cosmos).

There are no changes to existing behavior. The Propulsion tool is also unaffected.

There are breaking changes in the Equinox.CosmosStore.Core.Initialization.init function, specifically the mode parameter's Provisioning type had its rus members changed to Throughput type. The initAux function remains unchanged.

There is no plan to update the Propulsion tool since the minimum RU/s in both Manual and Autoscale mode is 400 which should be fine for the vast majority of 'aux' containers.

deviousasti
deviousasti
        let! c = d.CreateContainerIfNotExistsAsync(cp, throughput = tp, cancellationToken = ct) |> Async.AwaitTaskCorrect
open pull request

deviousasti wants to merge jet/equinox

deviousasti
deviousasti

Equinox.Tool: Add support for Cosmos Autoscaling

Adds an --autoscale/-A switch to the eqx tool to support autoscaling throughput of Cosmos containers and databases. Specifying this flag causes the --rus parameter to be interpreted as "Maximum RU/s" and changes the default value to 4000 RU/s (the minimum MaxRUs value allowed by Cosmos).

There are no changes to existing behavior. The Propulsion tool is also unaffected.

There are breaking changes in the Equinox.CosmosStore.Core.Initialization.init function, specifically the mode parameter's Provisioning type had its rus members changed to Throughput type. The initAux function remains unchanged.

There is no plan to update the Propulsion tool since the minimum RU/s in both Manual and Autoscale mode is 400 which should be fine for the vast majority of 'aux' containers.

deviousasti
deviousasti
        let tp = maybeThroughput |> Option.map toThroughputProperties |> Option.toObj
open pull request

deviousasti wants to merge jet/equinox

deviousasti
deviousasti

Equinox.Tool: Add support for Cosmos Autoscaling

Adds an --autoscale/-A switch to the eqx tool to support autoscaling throughput of Cosmos containers and databases. Specifying this flag causes the --rus parameter to be interpreted as "Maximum RU/s" and changes the default value to 4000 RU/s (the minimum MaxRUs value allowed by Cosmos).

There are no changes to existing behavior. The Propulsion tool is also unaffected.

There are breaking changes in the Equinox.CosmosStore.Core.Initialization.init function, specifically the mode parameter's Provisioning type had its rus members changed to Throughput type. The initAux function remains unchanged.

There is no plan to update the Propulsion tool since the minimum RU/s in both Manual and Autoscale mode is 400 which should be fine for the vast majority of 'aux' containers.

deviousasti
deviousasti

Does this need to be a function?

open pull request

deviousasti wants to merge jet/equinox

deviousasti
deviousasti

Equinox.Tool: Add support for Cosmos Autoscaling

Adds an --autoscale/-A switch to the eqx tool to support autoscaling throughput of Cosmos containers and databases. Specifying this flag causes the --rus parameter to be interpreted as "Maximum RU/s" and changes the default value to 4000 RU/s (the minimum MaxRUs value allowed by Cosmos).

There are no changes to existing behavior. The Propulsion tool is also unaffected.

There are breaking changes in the Equinox.CosmosStore.Core.Initialization.init function, specifically the mode parameter's Provisioning type had its rus members changed to Throughput type. The initAux function remains unchanged.

There is no plan to update the Propulsion tool since the minimum RU/s in both Manual and Autoscale mode is 400 which should be fine for the vast majority of 'aux' containers.

deviousasti
deviousasti
        let! dbr = client.CreateDatabaseIfNotExistsAsync(dName, throughput = tp, cancellationToken = ct) |> Async.AwaitTaskCorrect
open pull request

deviousasti wants to merge jet/equinox

deviousasti
deviousasti

Equinox.Tool: Add support for Cosmos Autoscaling

Adds an --autoscale/-A switch to the eqx tool to support autoscaling throughput of Cosmos containers and databases. Specifying this flag causes the --rus parameter to be interpreted as "Maximum RU/s" and changes the default value to 4000 RU/s (the minimum MaxRUs value allowed by Cosmos).

There are no changes to existing behavior. The Propulsion tool is also unaffected.

There are breaking changes in the Equinox.CosmosStore.Core.Initialization.init function, specifically the mode parameter's Provisioning type had its rus members changed to Throughput type. The initAux function remains unchanged.

There is no plan to update the Propulsion tool since the minimum RU/s in both Manual and Autoscale mode is 400 which should be fine for the vast majority of 'aux' containers.

deviousasti
deviousasti
        let tp = toThroughputProperties throughput
open pull request

deviousasti wants to merge jet/equinox

deviousasti
deviousasti

Equinox.Tool: Add support for Cosmos Autoscaling

Adds an --autoscale/-A switch to the eqx tool to support autoscaling throughput of Cosmos containers and databases. Specifying this flag causes the --rus parameter to be interpreted as "Maximum RU/s" and changes the default value to 4000 RU/s (the minimum MaxRUs value allowed by Cosmos).

There are no changes to existing behavior. The Propulsion tool is also unaffected.

There are breaking changes in the Equinox.CosmosStore.Core.Initialization.init function, specifically the mode parameter's Provisioning type had its rus members changed to Throughput type. The initAux function remains unchanged.

There is no plan to update the Propulsion tool since the minimum RU/s in both Manual and Autoscale mode is 400 which should be fine for the vast majority of 'aux' containers.

deviousasti
deviousasti
        let tp = toThroughputProperties throughput
Previous