Rash thoughts about .NET, C#, F# and Dynamics NAV.


"Every solution will only lead to new problems."

Category Diverses

In dieser Kategorie sind Blogeinträge die nicht richtig in die anderen Kategorien einzuordnen sind.

Sunday, 14. August 2016


Fable |> React – Running a F# Sudoku solver everywhere

Filed under: Diverses — Steffen Forkmann at 13:47 Uhr

A couple of years ago I was flying to Canada and was bored enought to write a Sudoku solver console app in F#. For some reason I was thinking about that today and thought that I should try to put that into a F# React Native app (see this blog post for an introduction).

So the solver code is this:

Sudoku on React Native

It turned out porting this code to React Native was pretty easy. I just copied the F# React Native demo app, added my solver code and created a React View with the data points and got this:

Sudoku solver on android

I find it really amazing that you can just take fairly complex code that was written against .NET Framework collection APIs and run it as JavaScript apps. Fable is mapping the .NET API calls into similar JavaScript API calls behind the scenes.

You can find the full source code at https://github.com/forki/SudokuApp.

Sudoku in the browser (via React)

As a the next step I took the same code and ported it to a React web app that runs in the browser:

Sudoku solver in the browser

You can find the full source code at https://github.com/forki/react-sudoku.

Sudoku in the browser (via VirtualDOM)

[Update] Tomas Jansson ported the sample to fable-virtualdom. Here is how he creates the text boxes:

You can find the full source code at https://github.com/fable-compiler/fable-virtualdom/tree/master/samples/sudoku.

Sudoku on electron

In order to come full circle I tried to put the Sudoku solver into a React app on the Electron shell. This gives me a cross-platform desktop app:

Sudoku solver desktop on Electron

You can find the full source code at https://github.com/forki/sudoku-electron.

Summary

I’m really amazed how easy Fable + React makes it for me to put existing F# code into the JavaScript ecosystem.

The same code is now running

  • as Console App on .NET,
  • as React Native app on Android and iOS,
  • in the browser on React,
  • in the browser on VirtualDOM,
  • and with Electron as Desktop app on all operating systems.

Friday, 12. August 2016


Fable |> AsyncStorage – Data access with F# on React Native

Filed under: Diverses — Steffen Forkmann at 12:55 Uhr

I my last two articles I introduced React Native app development with F# and showed how we can do HTTP calls with the Fetch API. I also mentioned briefly how to access the local storage of your phone in order to cache information. In this article I want to look a small bit deeper into this.

React Native provides a basic abstraction called AsyncStorage that works on Android and iOS. With the help of a package called fable-react-native-simple-store we can use it from F#:

As you can see all JavaScript promises calls are mapped into F# async computations and everything is statically typed. This makes it easy to integrate the local storage with other F# code.

DataStore internals

AsyncStorage is a simple, unencrypted, asynchronous, persistent, key-value storage system that is global to the app. It should be used instead of LocalStorage. [project site]

AsyncStorage only provides a very basic key-value store. With the help of fable-react-native-simple-store we get something that allows us to store objects in arrays separated by type:

This is still a very low level data storage API, but as the sample app shows it’s already useful for caching specific app data.

Monday, 25. April 2016


“Make failure great again” – a small journey into the F# compiler

Filed under: Diverses,F#,Informatik — Steffen Forkmann at 13:44 Uhr

Giving good error messages is very important for modern compilers. The language Elm is famous for giving excellent user-friendly error messages. Parts of the F# community decided to improve the F# compiler messages as well. We want to make that a community effort and hope many people join us and help to make the compiler emit better error messages.  Isaac Abraham is mainatining a list with possible targets, so if you are interested in helping then take a look at this list.

Unfortunately working on compilers it’s not exactly the easiest task. In this post I want to show you how I tried to improve one compiler warning and hope this helps others to get started.

The task for this post is to improve the compiler warning for the following code:

Currently the compiler shows the following:

Original compiler warning

According to issue #1109 we want to turn it into:

New descriptive compiler warning

As you can see the new message is giving the user more details about the specific situation and also refers to a common error of newcomers.

Please notice that this is probably not the final wording for this warning, but once we have finished this it will be easy to iterate on the concrete warning.

Getting started

The first thing to is to get the compiler code on your machine. I’m using Windows and Visual Studio 2015 here. So what you want to do is the following:

  • Fork https://github.com/Microsoft/visualfsharp on github
  • Start a “Developer command prompt for Visual Studio 2015” in admin mode
  • Run `git clone [your clone url]` and change into the new directory
  • Run `git remote add upstream https://github.com/Microsoft/visualfsharp.git`
  • Optionally: If you want to follow the exact steps from this post, then it makes sense to set your clone to the same commit where I started. You can do that by executing “git reset –hard 8a2e393999f440ea93769a288c37172d98db455a”
  • Run `build.cmd`

This last step will download the internet for you, so don’t be too surprised when you find the lastest “Game of Thrones” episode somewhere inside your packages folder.

Anyways, if everything works then the output should look like the following:

Build works from command line

If the build doesn’t work for you then read the DEVGUIDE very very carefully. If that doesn’t help then please open an issue in the Visual F# issue tracker.

Reproducing the compiler warning

If the build works from command line we should try to reproduce the error with our own freshly built compiler. Let’s open the solution in Visual Studio 2015, set the startup project to “FsiAnyCPU” and hit F5 to start a debug session in Visual Studio. If everything works we will see a F# Interactive Window and Visual Studio is in Debug mode:

Debug works in Visual Studio

Now we paste our code into the command line window:

Original compiler warning

Using the F# Interactive in debug mode is an easy way to do compiler debugging. There are other possibilities (like using fsc.exe), but the F# Interactive allows you to debug the compilation of single lines in isolation from the code above. It’s really neat.

Where to start with hacking

Since we now know how to reproduce the compiler warning, we want to make actual code changes. But where!?

Where??

An easy way to get started is by using the old error message as a search string. When we use Visual Studio’s solution-wide search and look for “This expression should have type” we find exactly two locations inside a file called FSStrings.resx file.

Searching for original compiler warning

So this gives us a new search string “UnitTypeExpected1”.

Searching for UnitTypeExpected1

This looks actually like we found something interesting in CompileOps.fs. Let set a breakpoint and see if it stops when we reproduce our warning:

Debugging

Cool, so this seems to be the place where the warning gets emitted. Now we need to find the place where the discriminated union case “UnitTypeExpected” is created. After another little search we are in TypeChecker.fs:

Type checker

We can try to set another breakpoint and see what happens in that code. The interesting part is the inner else part.

Baby

The code in there looks scary and cryptic at first, but it actually shows the power of using a ML dialect for building compilers. Inside this code the compiler already knows that we want to emit a warning. By pattern matching on the abstract syntax tree (AST) we decide if the left side of the expression is a property. In that case the compiler seem to emit a different warning (see also that code above from CompileOps.fs).

So after hitting the breakpoint and looking in the value of exprOpt I’m pretty sure we are in the right place:

Inspect AST

So somewhere inside that AST we can actually find our name x. Now we have all we need.

Making the code changes

It’s good practice to never make code changes on the master branch. So let’s create a feature branch with “git checkout -b assignment-warning”.

Now let’s start by adding our new compiler warning to FSStrings.resx:

Now we go back to TypeChecker.fs and try to come up with some pattern matching on the AST that finds our special case. After playing around a bit I found:

This doesn’t look super nice, but it follows one of the important rules from the contributor guide – “use similar style to nearby existing code”. We probably want to tidy this up later when initial code review is done. But in the beginning we should stay as close to the original as possible.

Since we decided to store additional data, this already tells us we need to extent the UnitTypeExpected type in TypeChecker.fsi and TypeChecker.fs. After that we can go to CompileOps.fs and use that data:

That’s basically all we need to do. Let’s fix the the remaining errors (don’t worry the compiler will show you all the places) and then reproduce the warning again:

New descriptive compiler warning

Wow. We did it. We actually changed the compiler. And it didn’t even hurt that much.

Compiler changed

Unit tests

Compiler tests (especially if you want to tests negative results like warnings or exceptions) can’t be easily done in standard unit tests. The F# team came up with a different approach where the test runner compiles a .fs file and you can use regular expressions to match against the compiler output.

In order to run the existing test suite call “build.cmd all”.

Are you afraid?

This will take a while, but after all tests are done we should see:

Test results

So good news is we didn’t break anything, but the bad news is that we don’t have tests covering our case. So let’s add one.

We create tests/fsharpqa/Source/Warnings/WarnIfPossibleAssignment.fs:

Now we need to include the test in a test suite. Since there isn’t a good fitting existing suite we need to create tests/fsharpqa/Source/Warnings/env.lst:

And we need to register this new suite in /tests/fsharpqa/Source/test.lst:

Now we can run the test with “src\RunTests.cmd release fsharpqa Misc01” (more details can be found in the TESTGUIDE):

Test failed

So at least we now know that our test gets executed 😉
The concrete test results can be found in a file called 258,259FSharpQA_Failures.log alongside our WarnIfPossibleAssignment.fs:

So it seems we cannot match the same line twice. For simplicitly of this blog post we will go with a reduced test:

Wrapping it up

After we ran “build.cmd all” again it’s now time for the final phase. Commit the changes locally and use “git push origin assignment-warning” to publish your code.
Now go to the Visual F# GitHub repo and create a pull request with an explanation of what you did and what you intended to fix. Often it’s also useful to include one or two screenshots.

Your PR will then go through code review process. Usually you will get a lot of questions and probably you need to change some things in your proposal. This process can take a while so bring a bit of patience.

Anyways, here is my PR for this change – wish me

Good luck!

Monday, 30. November 2015


F# advent calendar: Using Async.Choice in Paket

Filed under: .NET,C#,Diverses,F#,PLINQ — Steffen Forkmann at 0:50 Uhr

[This post is part of the F# advent calendar 2015 series.]

Prologue: What is Paket?

Paket is a dependency manager for .NET with support for NuGet packages and GitHub repositories. It enables precise and predictable control over what packages the projects within your application reference. If you want to learn how to use Paket then read the “Getting started” tutorial and take a look at the FAQs.

Paket file structure

Async computations in F#

Asynchronous Workflows are a very old F# feature (they already shipped in 2007) and they are used in many places in Paket. In this article I want to highlight one of the nice applications that F#’s async model allows you.

Many readers are probably familiar with C#’s async and await keywords (IIRC released with C# in 2012), but F#’s async feature works a little different. You can read more about some of “Asynchronous gotchas in C#” in Tomas Petricek’s excellent blog post. Most of these gotchas come from the fact that C# is starting all async tasks automatically while F# wraps the logic in data and allows you to run it explicitly. For a really good introduction to asynchronous programming with F# I can recommend Scott Wlaschin’s blog post.

The issue: retrieving version numbers from NuGet feeds

Paket’s package resolution algorithm (if you are interested in algorithms then read more) needs to know which versions are avalaible for a given package. Usually users specify more than one NuGet feed and different NuGet feeds support different protocols. The following code shows how older Paket versions retrieved all version numbers for a given package across all configured NuGet feeds:

As you can see getAllVersions tries 4 different NuGet protocols per source and returns the first result that is not None. Every getVersionsViaProtocol call performs async web request. In GetAllVersions we run this function for every NuGet source in parallel and combine the results. This code is very similar to the “async web downloader” sample in Scott Wlaschin’s async blog post and basically the “hello world” of asynchronous programming. 

Code cleanup

The getAllVersions is deeply nested and it’s hard to understand what’s going on. With the help of List.tryPick we can rewrite the code as:

List.tryPick returns the first result that is not None. So instead of nesting multiple match and let! expressions we use a higher-order-function to encapsulate the same pattern.

Introducing Async.Choice

After using this code for a while in Paket we noticed that different NuGet server implementations each implement a different subset of the 4 protocols and differ very much in the response times. So there was no order of the protocols that would work good for all server implementations. But what if we could query all 4 protocols in parallel and just take the fastest response?

The change is relatively easy and we can rewrite the GetAllVersions as:Instead of running the web requests synchronously and in order we run the four web request per NuGet feed in parallel and take the first response that is not None.

Implementation of Async.Choice

Unfortunately Async.Choice is not part of the standard FSharp.Core library and it turns out it is not easy to implement. There are many different implementations floating around on the internet. The one we use in Paket is by Eirik Tsarpalis and taken from fssnip. One of the advantages of this version is that the automatic cancellation of tasks works nicely. Since we are running lots and lots of web requests in parallel and always take the first response we want to cancel all the other pending web requests. Otherwise we would basically DDOS the feeds with useless requests (and yes that happened to us ;-)). Since Async.Choice is very useful we sent a pull request to the Visual F# project and hope that one day it will be in the box. 

Epilogue

Treating computations as data has even more advantages. The m-brace project created a new version of computation workflows called “cloud”:

cloud is a computation workflow builder and allows you to run your computations in the cloud. In contrast to async we don’t only control when something gets executed but also where. They even have a Cloud.Choice, which allows you to run tasks asynchronous in the cloud and take the first succeeding result.

Btw: async and cloud aren’t language keywords like C#’s async and await, but implemented as normal F# code in libraries. If you want to define your own computation expression builders, then the MSDN docs are a good starting point.

Tags: , , ,

Monday, 12. October 2015


Developer Open Space 2015

Filed under: Diverses — Steffen Forkmann at 13:08 Uhr

 

Vor acht Jahren gab es die erste Ausgabe der (Un-)Konferenz mit dem Namen Developer Open Space und sie findet dieses Jahr vom 16.–18. Oktober 2015 in Leipzig statt.

Für mich nach wie vor die beste technische Konferenz in Deutschland. Die Fotos von der Konferenz sprechen für sich.

Anmeldung

Die Anmeldung ist seit einiger Zeit möglich. Die Plätze sind begrenzt. Nimm teil!

Tuesday, 13. January 2015


SlideShow: Paket Introduction

Filed under: Diverses — Steffen Forkmann at 11:17 Uhr

I created a short presentation for our new .NET dependency manager Paket.
It’s created with FsReveal and MIT licensed. Please feel free to use/modify it for your own presentations.

http://forki.github.io/PaketIntro

Wednesday, 12. November 2014


Introducing FsReveal – Beautiful, version controlled presentations in the browser

Filed under: Diverses — Steffen Forkmann at 13:14 Uhr

This FsReveal tool stack allows you to write beautiful slides in Markdown and brings F# to the wonderful reveal.js web presentation framework.

You write your slides in Markdown like the following and the rest is magic*:

will turn into:

FsReveal slide 1

FsReveal slide 2

FsReveal slide 3

Features
  • Syntax highlighting for most programming languages including C#, F# and LaTeX
  • Speaker notes – shows the current slide, next slide, elapsed time and current time
  • Built in themes
  • Built in slide transitions using CSS 3D transforms
  • Slide overview
  • Works on Windows, Linux and Mac
  • Slides work on mobile browsers. Swipe your way through the presentation.
Getting Started

Just follow the getting started guide at http://fsprojects.github.io/FsReveal/.

Examples

Check out what others have created:

The magic
  • reveal.js – Framework for easily creating beautiful presentations using HTML and JavaScript.
  • Paket – Dependency manager which retrieves the referenced NuGet packages and reveal.js.
  • FAKE – Build tool which allows to orchestrate the slide building process.
  • FSharp.Formatting – Used to render markdown slides and for F# syntax highlighting.
  • Suave.io – Simple web development framework/ webserver which allows to host the slides.
  • git – Allows you to bring your slides under version control.

All of this is bundled in FsReveal, which was originally created by the amazing @kimsk (Karlkim Suwanmongkol) and is now part of fsprojects.

Tuesday, 14. October 2014


Retrieving GitHub download counts

Filed under: Diverses — Steffen Forkmann at 13:41 Uhr

A couple of weeks ago we started the Paket project which is released on GitHub. Unfortunately GitHub doesn’t provide any download stats in the UI.

A quick look at the REST API docs shows that we can retrieve the numbers via JSON.

So let’s open Visual Studio reference FSharp.Data and FSharp.Charting and hack a bit with the JSON type provider:

and voilà:

 

Paket download stats Paket download stats

Saturday, 5. July 2014


Microsoft, Open Source development and Codeplex

Filed under: .NET,C#,Diverses,F# — Steffen Forkmann at 12:37 Uhr

Recently Microsoft released all their major programming languages as open source and even started to accept pull requests. I didn’t think this would ever be possible at Microsoft, but they opened up and people like me started to contribute:

Personally I sent 29 (mostly small) pull requests to the Visual F# project. 5 pull requests already got accepted and 15 are still under evaluation.  In principle the development process seems to be working very well. Especially in the Visual F# project Don Syme and the Visual F# team are doing an excellent job to encourage the community. They are marking user voice issues as “approved in principle” and even provide detailed documents for implementation tasks (See CoreLibraryFunctions). This makes it very easy to get started and to hack a bit on the F# compiler. A big thanks to you guys.

A very important part of the open source is the review process. The F# community is awesome in this regards. On issues like a new “compareWith” function I got comments with remarks about coding style, test cases, documentation and lots of new ideas about possible performance improvements. It’s really exciting to be part of such an active and welcoming community. There is only one “but” and this “but” is the choice of the development platform. I really think CodePlex is hindering these projects to become even more successful. In this post I want to show some of my experiences with Codeplex. Remember I already sent 29 pull requests so I think it’s fair to say I tried!

Overall usability

The first impression on the Codeplex site is that every click feels so frustrating slow. Waiting 4s and more for a site to load doesn’t exactly feel like 2014.

If you want to comment on something then there is an “interesting” distinction between issues and pull requests. On issues you get a preview box and some buttons to make formatting easier, but you can’t edit your comments later:

Issue comment editor

On pull request you can edit your comments later but your don’t have the formatting buttons:

Pull request comment editor

 

E-Mail notifications

Like most online portals you can enable E-Mail notifications on Codeplex. Unfortunately it doesn’t really work. I tried to set all notification sliders I found to the max. and still don’t get notifcations if someone sends a new pull request to the Visual F# projects. Instead I’m getting annoying E-Mail notifications on my own activities:

E-Mail notifications on own comments

 

Things like this make you wonder if they actually dogfood their own stuff.

Code reviews on pull requests

As described above good code reviews are a very important part of any software development project, for open source programming language projects even more so. Unfortunately Codeplex has a really bad code review tool. I mean it is possible to comment on diffs:

Comments on diff

But if you update the pull request with a fix then the comment is displayed on the new fixed code and makes no sense any more:

Wrong code comments on diff

The whole code review is broken when you add commits to a pull request and it get’s even messier when you rebase your pull request on the current master. Rebasing pull requests is a very common operation in open source projects since it allows to move the merge effort from the project maintainer to the contributor. But unfortunately Codeplex gets confused by the rebase and now shows a wrong diff:

Wrong diff on rebased pull requests

A code platform shows a wrong diff – yep I couldn’t believe it myself so I tried again. #7040, #7045#7060, always the same.

Finding the needle in the hashstack

A couple of days ago I wanted to tweet a link to a cool performance trick and knew it was the last commit on a pull request. Now try to find the url:

Alphabetical order by hash

Yes that’s right – the commits are ordered in alphabetical order BY HASH or as I call it in “least useful order”.

Reporting Codeplex issues

Of course you may ask: “Steffen why didn’t you report these issues to the Codeplex team?” and that’s a valid question. Actually I went to codeplex.codeplex.com, which I believe is the home of the Codeplex project, and looked at their issue list. This is what I got:

Codeplex has quite some issues

 

Not a single issue on the first page is related to Codeplex and it seems they don’t even care to close this spam. So why should I care to log issues there?

What now?

It’s more than obvious – use the “move source code to github” strategy and people already created an issue on the TypeScript project. Unfortunately it got closed:

Business needs

After reading this I really doubt it was the decision of the teams to use Codeplex. Fortunately the ASP.NET team seems to be an exception to this. Somehow they managed to move to github.com/aspnet.

There are also other ways. Microsoft could really invest in Codeplex and make it a usable platform. But I don’t see this happing, because it will cost A LOT of money. Even if they would open source Codeplex I don’t see a community which is willing to improve this site.

So I appeal to the people in charge at Microsoft please answer the following questions:

  • What are the reasons for putting the Visual F# project on Codeplex, especially when the majority of the existing F# projects and community already operate on Github?
  • Do you think it’s more important to support Codeplex or to grow a community around the programming language projects?
  • If the F# community voted for the project to be moved, would you consider moving it?
  • If you insist on Codeplex how and when do you plan to fix these usability issues?

So please let your OSS teams and their community pick the open source platform they want!

Monday, 16. June 2014


FAKE 2.18 released – RoundhousE kick edition

Filed under: Diverses — Steffen Forkmann at 14:08 Uhr

With the FAKE 2.18.1 we now have 80 contributors. A big thanks to all of you.

Here are the most important changes since my last blog post about FAKE 2.14.

What’s new?

  • New (backwards compatible) CLI #455 – see new docs
  • Visual Basic support to AssemblyFileInfo task #471
  • Small fixes for OctoTools support #468#469#470
  • Support for Project RoundhousE #456
  • Support for NuGet source packages without a NuGet project file #450
  • Support for MSTest settings #428
  • Support for BuildFailureTargets #407
  • Fake.Deploy agent requires user authentication – see docs

More details about minor bug fixes can be found in the release notes.

Getting started

If you new to FAKE you should read the getting started guide or clone the F# ProjectScaffold.

Go and grab the bits

Feel free to contact me if you need help for the upgrade.