Can't use prject from vs
hodzanassredin opened this issue · comments
My vs can't load project.
The imported project "C:\Program Files (x86)\Microsoft SDKs\F#\3.1\Framework\v4.0\Microsoft.FSharp.Targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
I undestand what I have to do to fix it, but better idea is to use ProjectScaffold it is free from that kind of problems.
Interesting. The Xamarin, which I happened to create the project with, and VS 2013 Community Edition (on a VM) installations that I happen to have on my laptop do load the project. Up to this point I've only compiled the project to get type checking while I've explored the idea. I want to first understand whether the idea actually makes sense. I'll look into the project scaffolding later if/when I start exploring the implementation or others can contribute it, but I personally would not recommend spending too much time on that at this point.
Problem occurs only in vs2015 because it doesnt have f# 3.1 After fsharp 3.1 installation everything is ok. Yes I saw that there are only stubs in JoinsCML project. But it is interesting for me to check examples. As far as I understand there are MVars and so on and it is possible to have a deadlock. Like in joinads https://gist.github.com/hodzanassredin/6979d9845bada2798fdc Am I right? Why not to use stm approach? I\m interested because after creation of my toy project https://github.com/hodzanassredin/TransAlt I'm trying to understand why immutablity and stm are not used for that kind of stuff. And seems that you also are not going to use it. I'm not an expert just trying to understand.
STM and CML/JoinCML/TE are quite different models for concurrent programming. As described in What Can We Not Do with STM?
In general, the class of operations that STM cannot express are those that involve multi-way communication between threads. The simplest example is a synchronous channel, in which both the reader and the writer must be present simultaneously for the operation to go ahead. We cannot implement this in STM, at least compositionally, for the same reason that we cannot implement TMVar with fairness: the operations need to block and have a visible effect—advertise that there is a blocked thread—simultaneously.
STM does not support multi-way synchronous communication between threads. CML (like CSP/Pi-calculus with synchronous message passing and nondeterministic choice) directly supports two-way synchronous communication with a single commit point. (I believe your TransAlt model is basically a variation of STM in that it does not address communication like CSP/Pi/CML, but I haven't studied the implementation in close enough detail - none of the examples require synchronous communication between threads and the channel implementation seems like an async queue rather than a synchronous rendezvous mechanism. I would recommend that you write a document that describes the model in more detail.) JoinCML supports n-way with a single commit point, and TE supports n-way transactional communication. TE is expressive enough to encode STM. All of these have some nice properties and some not so nice properties. For example, STM is particularly nice for prototyping as it is very easy to implement and understand and sort of lets you forget about threads altogether (this is also why it doesn't address communication - communication is not part of the STM model). You can easily implement a synchronous message passing model like CML with STM. However, you cannot use the resulting synchronous message passing operations within STM transactions (that is exactly the limitation that the above quote refers to). STM is also not very efficient without extensive (compiler) optimizations.
Thanks for detailed answer. Very helpful. TransAlt is not finished yet and probably will never be finished)) So it lacks documentation. I wrote some samples here. I'll try to read docs about TE. But one more question "none of the examples require synchronous communication between threads and the channel implementation seems like an async queue rather than a synchronous rendezvous mechanism."
Could you give me an example or link to this kind of task? I\ll try to implement it in TransAlt. Currently when we read from a channel in transalt it will be blocked while state keeper could not resolve state change request(reading from an empty channel ). If state keeper can resolve it (probably in future when someone adds a message to the queue) then continuation will be invoked. Or if there are no other running proccesses which could change state then continuation will be killed.
TransAlt was initially created as an atttempt to understand hopac alts. But after that I decided to add bind and merge combinators. But it was too easy to get a deadlock so it was compleely unusable. To fix that I decided to use some kind of isolated snapsot. Implementation is trivial.
Perhaps swap channels would be an illustrative enough example of two-way communication. See SwapCh.fsi and SwapCh.fs. The basic idea is that you can create a swap channel that allows a pair of threads to exchange values with each other. In other words, a single completed swap involves only two threads - even if more than two threads try to simultaneously swap values with other threads on the same swap channel. The swap operation can also be used in nondeterministic choice. For example, you could have two or more swap channels and a single thread could try to nondeterministically swap values on each of those channels or try to perform some other alternative. At most one of the swaps (or other alternative) will be performed.
This sort of communication cannot done within a single STM transaction - multiple transactions are needed.
Metaphors can sometimes be helpful, but not always, so if the following two do not help, just forget them. :)
STM is like a public toilet. You enter. You can perform your duties there or just leave. Perhaps write "... was here" on the wall. The next person who enters will find out what you left there, but only after you left and has no way to verify that it was you.
CML is like a wall with holes. You can watch several holes at once. If someone on the other side of the wall happens to watch one of the same holes you may exchange messages with each other through the hole.
Thanks.