GSoC2012

[Sega Able]

Hello, F# community!
My name is Igor and I am a Google Summer of Code 2012 student.
This summer I want to take some suggestions of fsharpbinding as my SoC project. I have been looking through the work items list (https://github.com/fsharp/fsharpbinding/wiki/Work-items) as well as talking to Tomas Petricek and here are some features that took my attention:
- Integrating F# into official MonoDevelop branch.
- Additional F# Templates
    I think it would be good to implement 'F# library' template.
- Debug Debugging
    MonoDevelop debugger must work with F# projects! But I am not familiar with how it works. I want to know it! Where I can read about this?
- Improve colorization
   
With that being said, what would you advise to choose? Primarily it must be integration to official branch.


Thank you in advance.

Regards, Igor. 

 

[Tomas Petricek]

[I already replied to Igor directly, but here are my thoughts, so that others can comment too]

 

The proposal looks promising! I think adding some new Mono-specific templates, fixing debugging and integrating the binding with official MonoDevelop distribution sounds like a good aim.

 

One thing that would be good to do is to figure out how exactly the integration should be done – I think you can ask about that on the MonoDevelop mailing list and they’ll send you suggestions on what exactly needs to be done (and you could then include that in your proposal). Another idea would be to spend some time on testing – again, ask on the MonoDevelop mailing list, but it would be good to have some tests that cover the stability of the F# binding. Perhaps MonoDevelop already has some infrastructure that you could use – if not, it might be an interesting and useful work item to include.

 

Tomas

--
You received this message because you are subscribed to the Google
Groups "FSharp Open Source Community" group.
To post to this group, send email to fsharp-o...@googlegroups.com
To unsubscribe from this group, send email to
fsharp-opensou...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fsharp-opensource?hl=en

[Sega Able]

Miguel de Icaza:"The latest version of the add-in needs to be updated to run with MonoDevelop from master, and once that is the case, we can get the code applied to master."

 

Is this means that md team will do that on their own so we just must improve f# binding addin itself?

2012/4/1 Tomas Petricek <to...@tomasp.net>

[Andreia Gaita]

On Mon, Apr 2, 2012 at 21:36, Sega Able <segam...@gmail.com> wrote:
>
> Miguel de Icaza:"The latest version of the add-in needs to be updated to run with MonoDevelop from master, and once that is the case, we can get the code applied to master."
>  
> Is this means that md team will do that on their own so we just must improve f# binding addin itself?

Usually, all students in Mono GSoC work in a separate repo on github during the summer, in forks of the respective projects (see http://github.com/mono-soc-2011 for last years projects). Once the summer is done, the code can be merged back into the main repo. We're looking for continued contributions to the community, and many of our soc students continue working on the projects and merge things by themselves after the program is done. How the code ends up back in the main repo is not that important, if a project is successfully completed it's usually straightforward to merge it.

 
> 2012/4/1 Tomas Petricek <to...@tomasp.net>

> One thing that would be good to do is to figure out how exactly the integration should be done – I 

> think you can ask about that on the MonoDevelop mailing list and 

> they’ll send you suggestions on what exactly needs to be done (and you could then include that in 

> your proposal). Another idea would be to spend some time on testing – again, ask on the 

> MonoDevelop mailing list, but it would be good to have some tests that cover the stability of the F# 

> binding. Perhaps MonoDevelop already has some infrastructure that you could use – if not, it might 

> be an interesting and useful work item to include.

Tests are good :D There's some nunit integration going on iirc, but even if there's no unit testing infrastructure integrated in MD right now, creating unit tests projects that run manually is also good.

WRT shipping the addin in MD, MD supports installing external addins from an addin repository, so that may be a good first step, and from there adding it to the default list of shipped addins is a simple step. We can cross that bridge when we get there :)


andreia gaita
--------------------
blog.worldofcoding.com
andreiagaita.net
github.com/andreiagaita

[rneatherway]

The proposal looks promising! I think adding some new Mono-specific templates, fixing debugging and integrating the binding with official MonoDevelop distribution sounds like a good aim.

It seems that there is some work along these lines in the many forks on github. For example, this commit (https://github.com/karthikvishnu/fsharpbinding/commit/1613da1b7808369f193cfa4a29369ad0820d29c8) adds a library template.

 

One thing that would be good to do is to figure out how exactly the integration should be done – I think you can ask about that on the MonoDevelop mailing list and they’ll send you suggestions on what exactly needs to be done (and you could then include that in your proposal). Another idea would be to spend some time on testing – again, ask on the MonoDevelop mailing list, but it would be good to have some tests that cover the stability of the F# binding. Perhaps MonoDevelop already has some infrastructure that you could use – if not, it might be an interesting and useful work item to include.

Something that bothers me about the current situation is that there are some hard-coded paths in the addin.xml and even in some source code files, particularly in some of the personal forks that are on github trying to bring the plugin up to date. FSHARP_COMPILER_BIN is one current approach to minimising this. I noticed that one suggestion was to bundle F# in the addin, which would avoid some of these problems. Would this bundled version be used just for code completion and FSI or for compiling as well? If it is used for compiling, how would it be possible to ensure binary compatibility with the F# dlls installed on the user's system?

I'm keen to see the plugin integrated with Monodevelop as well. Is this group the best place to stay in the loop?

Robin

[Sega Able]

Usually, all students in Mono GSoC work in a separate repo on github during the summer, in forks of the respective projects (see http://github.com/mono-soc-2011 for last years projects). Once the summer is done, the code can be merged back into the main repo. We're looking for continued contributions to the community, and many of our soc students continue working on the projects and merge things by themselves after the program is done. How the code ends up back in the main repo is not that important, if a project is successfully completed it's usually straightforward to merge it.

 

Luckily I have been already working on my forked one :)

 

 

Tests are good :D There's some nunit integration going on iirc, but even if there's no unit testing infrastructure integrated in MD right now, creating unit tests projects that run manually is also good.

 

Do you mean F# Unit Testing project template?

 

 

WRT shipping the addin in MD, MD supports installing external addins from an addin repository, so that may be a good first step, and from there adding it to the default list of shipped addins is a simple step. We can cross that bridge when we get there :)

 

 Could we use a http://functional-variations.net/addin repository? We need to update addin last version and include this repo to default one, right?

 

 

What about colorization? Should it stay in the proposal?

 

2012/4/3 Andreia Gaita <shana...@gmail.com>

[Sega Able]

It seems that there is some work along these lines in the many forks on github. For example, this commit (https://github.com/karthikvishnu/fsharpbinding/commit/1613da1b7808369f193cfa4a29369ad0820d29c8) adds a library template.

I know that and I want to implement gtk fsharp app template.

2012/4/3 Sega Able <segam...@gmail.com>

[Robin Neatherway]

On Wed, Apr 4, 2012 at 9:36 PM, Sega Able <segam...@gmail.com> wrote:

It seems that there is some work along these lines in the many forks on github. For example, this commit (https://github.com/karthikvishnu/fsharpbinding/commit/1613da1b7808369f193cfa4a29369ad0820d29c8) adds a library template.

I know that and I want to implement gtk fsharp app template.

Great, I think that would be a useful addition. I'll be happy to help test your changes (on Linux) over the summer.

[Sega Able]

Great, I think that would be a useful addition. I'll be happy to help test your changes (on Linux) over the summer. 

Thank you for your support! 

It been an hour when the submitting porposals ended and I have picked the following features: gtk f# project template, improving colorization, improvments of debugging, testing the addin and shipping it with MD. Every workitem requires researching (especially debugging) because I am new to Mono though. For now I have been loking through gtk# tutorials and c# binding implementation and asking everybody about debugging. I did search through stackoverflow and found out that there are two types of debuggers in Mono: soft and hard. I am not sure but in the future releases (or current) there is an sdb debugger( or smth like that). Generally guys, I need some guidance on this. Please, could point me to the resources dedicated to mono debugging? 

Thank you.

Igor.

2012/4/5 Robin Neatherway <neath...@gmail.com>

--

[Sega Able]

Hi guys. There are two overrided methods in src/Services/Parameters.fs in the class inherited from ConfigurationParameters() : AddDefineSymbol(symbol) and RemoveDefineSymbol(symbol) but when I had a look into ConfigurationParameters there were not these methods... What are we overriding then?

 

Thanks.

 

Igor.

2012/4/6 Sega Able <segam...@gmail.com>

[Tomas Petricek]

Hi,

the ConfigurationParameters class used to require these two methods (they were used to add/remove defined symbols and they were probably called by some other component). It looks like they are no longer needed – in general, the best approach is to check how this is done in other integrations (search the MonoDevelop source code for CSharpCompilerParameters, which is the C# equivalent of this type).

 

Regarding debugging (mentioned earlier), the F# compiler for Mono is able to generate MDB debug symbols and if you use the command line compiler (mdb) then it should work – see this guide: http://www.mono-project.com/Guide:Debugger.

 

In MonoDevelop, we’d like to use the soft debugger. This should work automatically when the compiler produces debug symbols, but for some reason it does not happen. I was not able to find the place in MonoDevelop where it launches the debugger (to find out why this does not happen for F#). The MonoDevelop developer mailing list/IRC should be a good palce to ask about this. You’ll need to build MonoDevelop from source to get some debug symbols and then you should be able to track this down.

 

I agree that getting the debugger to work should be one of the priorities! (Some Gtk# and other templates should be more fun and updating it to work with the latest release and integrating it with the main branch would be another priority...)

 

Hope this helps!

Tomas

[Sega Able]

I asked about it in IRC channel and found out that we need to use SoftDebuggerSession and SoftDebuggerEngine classes. Also, we need to check the execution handler for F# projects in order that they support debugging using Soft debugger. 

2012/4/12 Tomas Petricek <to...@tomasp.net>

[Sega Able]

Hi.
I have a question about gtk project template. I took a look at the similiar implementation for C# a while ago

(src\addins\CSharpBinding\templates\GtkSharp2Project.xpt) and wondering is there something else involved in implementation?

 

Igor.

2012/4/17 Sega Able <segam...@gmail.com>

[Tomas Petricek]

Hi,

I’m not familiar with the C# Gtk template, but I think MonoDevelop has some visual designer for Gtk that you can use with C#. As far as I know, this wouldn’t work out-of-the box with F#. I’m not sure if this is a key issue – perhaps improving F# Interactive would be more important for the typical F# uses – but if you’re interested in getting that to work, then try checking out how the designer works in C#.

 

T.