TaskBuilder update breaks my tasks

[forki]

• TaskBuilder.fs (1.0.1)

• TaskBuilder.fs (1.1)

any ideas? It breaks everything for me

[gusty]

Is this after applying my PR #14 ?

[forki]

That's not merged yet, right? So I assume no. This is with the official nuget package. Am 19.02.2018 13:40 schrieb "Gustavo Leon" <notifications@github.com>:

…

Is this after applying my PR #14 <#14> ? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#15 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNJzIo5G0zXWyjZgjYtOt1ZhzlXdZks5tWWuggaJpZM4SKdyH> .

[gusty]

Ah ok, since you posted in the other issue I though it was related to my fix.
Anyway I can have a look, can you manage to get a minimal repro? If I find a solution we can add it as a test.

[forki]

I posted it there because I hoped to get wider attention to the issue. Will try to reduce it Am 19.02.2018 13:43 schrieb "Gustavo Leon" <notifications@github.com>:

…

Ah ok, since you posted in the other issue I though it was related to my fix. Anyway I can have a look, can you manage to get a minimal repro? If I find a solution we can add it as a test. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#15 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNHo1RPFueYNnx_iezP-6Ava02Ie8ks5tWWx6gaJpZM4SKdyH> .

[forki]

let t = task { return Some "x" }

let getX  = task {
    let! r = t
    if r = None then
        return! failwithf "Could not find x" 
    else
        return r
}

[gusty]

I found a way to solve it in my PR but good luck with the original code ;)

If you want I can include another commit with this test and its fix.

[forki]

yes please. it's a regression and hurts us badly.

[rspeele]

I will be checking out Gustavo's PR this week to get F# 4.0 compat back. Sounds like it should be possible to fix with that code.

In the meantime here is a quick fix for this regression applied to the existing codebase:

https://www.nuget.org/packages/TaskBuilder.fs/1.1.1

Just out of curiosity, is there any reason you use return! instead of return here?

[forki]

Yes the reason is @dsyme teached me that this is the correct way to do it Am 19.02.2018 16:45 schrieb "Robert Peele" <notifications@github.com>: I will be checking out Gustavo's PR this week to get F# 4.0 compat back. Sounds like it should be possible to fix with that code. In the meantime here is a quick fix for this regression applied to the existing codebase: https://www.nuget.org/packages/TaskBuilder.fs/1.1.1 Just out of curiosity, is there any reason you use return! instead of return here? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#15 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNBf3e2feXSpxJ_cbbirsXOkoFVtZks5tWZcRgaJpZM4SKdyH> .

[gusty]

I also think return makes more sense and am curious to hear @dsyme explanations.

Anyway I updated my PR with the fix. If you can pull it and test your code please let me know.

[forki]

I think it's value vs. continuation or something. Am 19.02.2018 20:02 schrieb "Gustavo Leon" <notifications@github.com>:

…

I also think return makes more sense and am curious to hear @dsyme <https://github.com/dsyme> explanations. Anyway I updated my PR with the fix. If you can pull it and test your code please let me know. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#15 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNAWwBFK94s_CekHOH0bNTFTE1jnWks5tWcVcgaJpZM4SKdyH> .

[dsyme]

Just out of curiosity, is there any reason you use return! instead of return here?

You can do either - either way the failwith will fail to return either "return" type unit or Task<unit> or whatever.

[forki]

Good. Thanks for clarification! Am 20.02.2018 19:25 schrieb "Don Syme" <notifications@github.com>:

…

Just out of curiosity, is there any reason you use return! instead of return here? You can do either - either way the failwith will fail to return either "return" type unit or Task<unit> or whatever. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#15 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNN7XZXrwEv6K0E3JOfJk0z-3toeRks5tWw4hgaJpZM4SKdyH> .

[rspeele]

Just FYI, 1.2.0 rc is available now.
This has Gustavo's changes for 4.0 compability. It should behave the same way both in terms of type inference and runtime performance, and seems to from my testing, but I don't have a big codebase to check against.

@forki would you be willing to try it out and see how it works with your code?

[forki]

 The module/namespace 'FSharp.Control.Tasks.TaskBuilder' from compilation unit 'TaskBuilder.fs' did not contain the namespace, module or type 'ContextInsensitiveTaskBuilder'

[forki]

so basically whole projet breaks again. what do I need to do? and can you please write that into release notes

[gusty]

Yes, this is a minor issue, easy to fix, there were some refactoring in the namespaces/modules.

Looking at the code the way it is right now you won't find ContextInsensitiveTaskBuilder anywhere, you will find that builder like this:

FSharp.Control.Tasks.ContextInsensitive.TaskBuilder

Now, there are 2 ways to fix it, either you fix your code, or we can have a look at the taksbuilder and see if we can fix the taskbuilder code.

But I wonder why are you referencing that builder class? The only thing you need to reference is the builder instance:

FSharp.Control.Tasks.ContextInsensitive.task

or ideally:

open FSharp.Control.Tasks.ContextInsensitive

let x = task { ...

[rspeele]

In the RC, there is no longer a separate class for ContextInsensitiveTaskBuilder. There's just one TaskBuilder type and different extension methods on that type depending which module you open.

In what context are you referring to the task builder type by name? You could "fix" it by referring to FSharp.Control.Tasks.TaskBuilder.TaskBuilder but right now that isn't a great option as that module is marked obsolete (just to hide it from intellisense while still being able to use it from inline code). We might have to refactor and add type aliases to keep code that referred to the type name ContextInsensitiveTaskBuilder working.

[forki]

I'm lost. What namespace do I need to open to get old behavior?

[gusty]

@forki. See the last snippet in my previous comment.

[forki]

I still get that error everywhere. Is it related to giraffe? Do they need to update first?

[gusty]

I'm not sure if this is your case but if you are using TaskBuilder.fs in your project and at the same time your project uses another project that uses TaskBuilder (like Giraffe) you might run into problems, since the namespaces are the same.

I think ideally libraries using TaskBuilder shouldn't re-export TaskBuilder to avoid this.

[forki]

/cc @dustinmoris

[dustinmoris]

@gusty Could you elaborate what you mean? How can I not expose the task CE after referencing TaskBuilder.fs?

[gusty]

Honestly I don't know, I just said "ideally", but I know that in some scenarios this is problematic, it happened to me with other libraries.

To answer your question I need to know more details, specifically how it is included in Giraffe, I haven't look at it.

But if you are copying the code, you can simply change the namespaces or mark it as internal, this will allow the users of Giraffe to use their own taskbuilders at possible different versions.

In the readme it states:

This is public domain code. I encourage you to simply copy TaskBuilder.fs into your own project and use it as you see fit. It is not necessary to credit me or include any legal notice with your copy of the code.

I guess it's also fine to change the namespaces, but I know it's not an elegant solution.

[ForNeVeR]

I think newer versions of Giraffe use TaskBuilder from NuGet, right?

https://github.com/giraffe-fsharp/Giraffe/blob/4b5852e80e49c11e11bb66a4065afd79b6ad778b/src/Giraffe/Giraffe.fsproj#L35

[forki]

Yes. Including it via copy of the file worked excellent, but now we have a bit of a stability issue. I hope we get that worked out soon. I think the best way forward is for Giraffe to push a prerelease that is compiled against beta TaskBuilder.fs. I could then paket update all of it in my production apps and verify that everything plays well together. And then we do a coordinated release of TaskBuilder.fs and giraffe so that others do experience that issue. Am 27.02.2018 04:56 schrieb "Friedrich von Never" <notifications@github.com

…

: I think newer versions of Giraffe use TaskBuilder from NuGet, right? https://github.com/giraffe-fsharp/Giraffe/blob/ 4b5852e80e49c11e11bb66a4065afd79b6ad778b/src/Giraffe/Giraffe.fsproj#L35 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#15 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNF1ZziNAg0Pv54xybV7uVDzvbEi6ks5tY3z3gaJpZM4SKdyH> .

[forki]

@rspeele not sure why you closed it, but I can now confirm that a simultaneous update of taskbuilder and giraffe indeed works. so can you and @dustinmoris please somehow sync?

[dustinmoris]

Hi, just to reiterate everything:

• In theory there were breaking changes between TaskBuilder.fs 1.0.1 and the versions after (1.1 and now 1.2-rc).
• Giraffe has a dependency on the the TaskBuilder.fs NuGet package.
• Updating Giraffe to the latest 1.2-rc build of TaskBuilder.fs fixes the errors for @forki because there is no conflict between the old and the new namespaces of TaskBuilder.fs.
• However, a project which references Giraffe doesn't require an explicit reference to TaskBuilder.fs anymore, unless it wants to use a higher version and do some assembly redirects.

As @forki suggested if we coordinate the release of TaskBuilder.fs and Giraffe in the future then such breaking conflicts can be avoided for end users, but I also believe that perhaps it would have been better to version TaskBuilder.fs accordingly to the breaking changes (e.g. from 1.x.x to 2.x.x) and then it would have been more obvious (and expected) that an additional reference to a higher major version of TaskBuilder.fs might have caused issues with Giraffe if Giraffe hasn't been updated yet.

Am I missing something?

So my final question is what is the ETA for TaskBuilder.fs 1.2 stable?

[rspeele]

I opened a new issue for planning the release. #18