SolvedDevProblems

Ordering files in MonoDevelop's F# Plug-in

2011-03-27T11:19:00.000-07:00

I have been using Tomas Petricek's F# Plug-in for MonoDevelop a lot recently for some personal projects. The addition of code-completion and on-the-fly compilation has been a nice upgrade from XCode. Mostly it was working well until I added a new module and the main program file couldn't find it and just reported errors. It built fine using my Makefiles.

After looking at the compiler output I realized that the ordering of the files was wrong. The F# compiler enforces strict, non-cyclic dependencies between files (modules) and requires the order of the files on the command line reflect this. That is, the modules with no dependencies (except references) come first, and those dependent on the earlier ones come next.

For example, assume we are building a .DLL with files A.fs, B.fs, and C.fs. If files B and C are independent, but file A references both B and C then A must come after both B and C on the compile line:

mono fsc.exe [references] B.fs C.fs A.fs
I knew what the issue was but haven't been able to find a way in MonoDevelop to control this. Finally while watching the Australian Grand Prix this morning I found it. Experienced MonoDevelop users probably already know this, though it isn't necessary for C#, but I finally found the option to control the build order.

Under the Project Options menu item (either Project Menu or the right-click popup menu), find the heading 'Build' and click on the 'General' item. This brings up two tabs in the right-hand display both oddly named 'General' as well. The second one controls the build order. Once I fixed the build order to reflect the file dependencies I closed and re-openened the editor tabs and all is well again!

F# Futures

2010-02-17T11:45:00.000-08:00

I have been using F# a great deal lately. It's one of those languages that, once I got past the syntax and back into thinking "functional decomposition" (as opposed to object-oriented decomposition), I was consistently surprised by how little code was required to solve a problem. A lot like Python, but the runtime is considerably better. Running on Mono it won't keep up with C++ but I would guess my productivity to be 2-3x higher in F#, which makes it appropriate for a bulk of the code.

One issue I ran into early on is that async blocks are nice, but don't work well for computations that return a value. What I was looking for was a way to opportunistically spawn off particular chunks of code to the thread pool and then retrieve the result at some join point. I have not yet found a way to do this with async blocks -- please let me know if I am mistaken.

The Future type below works very much like the Lazy<> type, except that it queues the function to run in the thread pool immediately. Calling the Value method returns the results, blocking until complete if necessary. Exceptions in the function are trapped and re-raised when Value is called.

One example where this is useful is when several intermediate results need to be computed before a final synchronizing point:



let a = parseLogFile (setName + ".log")
    let b = loadGpxDataSet (setName + ".gpx")
    let c = loadElevationData areaBounds
    let model = ConstructModel a b c

In this trivial example, the intermediate results for a, b, and c could be done in parallel. The future type makes this straightforward:

let a = Future( fun () -> parseLogFile (setName + ".log") )
   let b = Future( fun () -> loadGpxDataSet (setName + ".gpx") )
   let c = Future( fun () -> loadElevationData areaBounds )
   let model = ConstructModel a.Value b.Value c.Value

Summary:
Platform: .Net / Mono
Language: F#




/// Provides basic functionality for parallelizing specific 
/// computations that produce a result to be used in the 
/// future.  Similar to async { } blocks but allows the main
/// thread to opportunistically spawn off computations 
/// instead of running the whole flow as an async block.
module Futures =
    open System.ComponentModel
    open System.Threading
    

    
    /// Executes a computation in a background worker and 
    /// synchronizes on the result return.  The computation 
    /// is started immediately and calling 'Value' blocks 
    /// until the result is ready.
    type Future<'t>(f : unit -> 't) =
        
        /// Result of the computation on normal exit.
        let mutable result :'t option = None
        
        
        /// Result if an exception was thrown.
        let mutable ext : Exception option = None
        
        let syncRoot = new Object()
        
        
        /// Pulse object used to wait until a result 
        /// is ready.  ensurePulse() is used so we don't 
        /// have to create the object if the result is 
        /// done before it's needed.
        let mutable pulse : ManualResetEvent = null
        let ensurePulse() = 
            lock syncRoot (fun () ->
                match pulse with 
                | null -> 
                    pulse <- new ManualResetEvent(false);
                | _ -> 
                    ()
                pulse)
            
        
        /// WARNING: Call once a lock on syncRoot is already 
        /// held.  Pulses the wait notifier.  Safe if
        /// called after 'pulse' is created but before 
        /// WaitOne is called.
        let notifyWaiters() = if pulse <> null then pulse.Set() |> ignore
        
        let work = new BackgroundWorker()
  
        
        /// On RunWorkerAsync(), run specified function and 
        /// store result.  All exceptions must be trapped.      
        do work.DoWork.Add( fun args ->
                                try 
                                    result <- Some( f() )
                                with e ->
                                    ext <- Some e
                                lock syncRoot ( fun () -> notifyWaiters()) )

        
        /// Start immediately / automatically.
        do work.RunWorkerAsync()
        
        
        /// Returns the value of the computation, blocking 
        /// if the result isn't ready yet.
        member t.Value =
            // If available, we can return it right away.
            match result with
            | Some x -> x
            | None when ext.IsSome -> raise (Option.get ext)
            | None ->
                let p = ensurePulse()
                
                
                // Check again in case it changed while 
                // we were gettting the wait object.
                match result with
                | Some x -> x
                | None ->
                    
                    // Lock-free is ok because if the pulse.Set() 
                    // method is called between when we
                    // checked 'result' and call WaitOne here, 
                    // WaitOne will return immediately.
                    p.WaitOne(1000000000) |> ignore
                    match result with
                    | Some x -> x
                    | None ->
                        if ext.IsSome then raise (Option.get ext)
                        else failwith "Future computation failed."
    
        
        /// Returns true if the computation is finished, false if not.
        member t.IsComplete =
            match result with
            | Some x -> true
            | None when Option.isSome ext -> true
            | None -> false

Introduction

2010-02-17T06:57:00.001-08:00

Welcome. This page is intended to be a simple recording of odd software development problems & solutions that I have run into. These are problems for which I was unable to find a solution posted anywhere else and am posting here in attempt to give back to the community. As such I don't plan to at any specific frequency, just as I run into odd problems.

Please feel free to comment publicly or email me privately with feedback, questions, whatever.

Any/all AdSense revenue will be donated to The Nature Conservancy or other registered not-for-profit organization. I just added to gain some experience with it.

Best Regards,
Jason

Auto SQL generation during update requires a valid SelectCommand

2010-02-17T06:57:00.000-08:00

While populating a Postgres DB, some updates (not all) updates failed with the following exception:

Auto SQL generation during Update requires a valid SelectCommand.
at System.Data.Common.DbDataAdapter.Update (System.Data.DataRow[] dataRows, System.Data.Common.DataTableMapping tableMapping) [0x00000]

At first I thought it was due to having several update threads running, but even with a single thread running it still occurred.

The error showed up under Mono 2.4.1 running on Ubuntu 9.10. I was not seeing it under Mac OS running Mono 2.6.1 or Ubuntu 9.10 also running Mono 2.6.1.

Upgrading to Mono 2.6.1 seems to have fixed it, but I have also seen other odd exceptions specifically on that VM. It's possible that the VM has other issues.

Summary:
Platform: Ubuntu Linux 9.10, Mac OS Snow Leopard running Mono 2.4.1 and 2.6.1
Language: F#
Solution: Switching from Mono 2.4 to 2.6.1 appears to have solved it.