[Haskell-cafe] Yi project proposal for GSOC 2014

Mon Mar 10 15:41:57 UTC 2014

Yes, absolutely. What I meant was that having Yi used in Leksah could provide more momentum for development. ‎I didn't mean to merge the two projects into one. 

Michal
  Original Message  
From: Kyle Marek-Spartz
Sent: Monday, March 10, 2014 11:29 AM
To: Mateusz Kowalczyk; Michal Antkiewicz
Cc: haskell-cafe
Subject: Re: [Haskell-cafe] Yi project proposal for GSOC 2014

Michal,

Yi is an extensible text editor, not an IDE. There’s room for both.

-- 
Kyle Marek-Spartz

On March 10, 2014 at 10:28:35 AM, Michal Antkiewicz (mantkiew at gsd.uwaterloo.ca) wrote:
> Hi Mateusz,
> 
> An interesting application is always what drives development. There's a
> need to have a good IDE with strong editing support for Haskell written in
> Haskell. There's Leksah and there's Yi. Perhaps they could be integrated?
> 
> Just an idea..
> 
> Cheers,
> Michal
> 
> 
> On Mon, Mar 10, 2014 at 11:09 AM, Mateusz Kowalczyk > > wrote:
> 
> > Greetings,
> >
> > GSOC 2014 proposal period opens in ~4 hours and I'm hoping to
> > participate this year as well. This time around I'd quite like to work
> > on Yi. As we did last year, I think it's worthwhile to put up the
> > proposals on café for people to comment on before they are submitted on
> > Google's site.
> >
> > I paste it in full below so that it is easier to respond to parts of it
> > (although I do ask that you don't quote the whole thing if it's not
> > necessary). In case any changes happen, the most up-to-date version
> > should be at https://gist.github.com/Fuuzetsu/9462709
> >
> > Please feel free to nitpick on anything, throw in suggestions and ask
> > for clarifications. I will give 5 days of discussion period on this
> > after which point I'll submit it on Google's site. I appreciate all
> > feedback.
> >
> > Thanks!
> >
> >
> > Yi concurrency, usability and hackability
> > ------------------------------------------
> >
> > * What is the goal of the project you propose to do?
> >
> > There are two main goals of the project: the first is to implement
> > concurrency in the Yi text editor. The second aim is to start
> > bringing Yi into the territory of usable and hackable editors.
> >
> > Dmitry Ivanov who's currently in charge of Yi has agreed to mentor
> > this project.
> >
> > * In what ways will this project benefit the wider Haskell community?
> >
> > While the project itself isn't one of the core ones (such as GHC,
> > Haddock and Cabal), I feel that there are a couple of benefits to the
> > community:
> >
> > 1. Work on Yi (now and in the future) will undoubtedly spawn new
> > Haskell libraries usable in other projects. My personal
> > experience with Yi shows that it's actually very comfortable to
> > write a generic library which does what we need and then having
> > a separate package which uses the library to actually interact
> > with Yi.
> >
> > 2. Haskellers come closer to escaping the ELisp/vimscript hell. We
> > can get a nicer programming environment, made and extensible in
> > the language of our choice and get to use all the libraries
> > that we're used to while we're at it.
> >
> > 3. We'll have more Real World™ Haskell applications. On a more
> > serious note, it can serve as a good example of how to do
> > certain things with Haskell: off the top of my head, it
> > demonstrates the use of dyre and gtk2hs in a real-world
> > scenario rather than a 5 line example on the Haskell wiki. If
> > the project is successful, we can add concurrency to this.
> >
> > Other than the Haskell community in general, this project should
> > benefit anyone with some interest in text editors. I think it's
> > safe to say that happens to be a large majority of Haskellers:
> > most of us want nicer integration with Haskell tools and
> > libraries[citation needed] and now it'll be possible through
> > direct, type-checked library access.
> >
> > * Can you give some more detailed design of what precisely you intend
> > to achieve?
> >
> > The concurrency goal will involve careful study of Yi's inner
> > workings in order to try and accommodate concurrency in Yi's
> > editor state. There are various ways to do concurrency and the
> > first part of the project will concentrate on settling for one. An
> > example of two different ways is to extend the existing Yi engine
> > with classical tools (MVars, channels) to accommodate for
> > concurrency that way. An alternative way would be to modify the
> > engine so that concurrency support is natural. Such experiment was
> > started [here](https://github.com/ethercrow/y) using the sodium
> > FRP package which would give us concurrency ‘for free’. The
> > experiment is not complete and this is the kind of thing that will
> > first be explored.
> >
> > Of course once we settle for a method, time will be spent
> > implementing it. In the end, this should allow us to do things
> > such as fire Yi events periodically or do network transfers
> > without having to halt the whole editor. Editors such as emacs
> > which are single-threaded effectively hop back-and-forth between
> > tasks on a single thread. We aim to provide the ability to simply
> > have tasks on different threads which allows us to take advantage
> > of system resources much better.
> >
> > The second part of the project is to make Yi more usable and
> > hackable. Usability here involves fixing bugs apparent to the user
> > and hackability involves bugs apparent to developers. Further,
> > as part of usability, I plan to implement as many editor modes as
> > I find time for.
> >
> > Specifically, here are some open bugs that I hope to either fix or
> > to make a considerate progress on: #445, #397, #517, #519, #515,
> > #516, #513 (concurrency), #512, #507, #504, #502, #501, #499,
> > #497, #493, #487, #478, #477, #468, #465, #399, #396, #391, #390,
> > #382, #322, #295, #172, #160, #106, #145, #112, #82, #509.
> >
> > All the bug numbers can be viewed on
> > [GitHub](https://github.com/yi-editor/yi/issues/). Please note
> > that some of these are documentation bugs: Yi suffers from poor
> > documentation and I believe that's what the main problems in
> > gaining developers and users has been. When time or area I'm
> > working on allows, missing documentation will be written.
> >
> > If I find any issue that have been fixed or are no longer
> > applicable, the reports will simply be closed. The issues are very
> > varied: unicode problems, keymap problems, highlighter problems,
> > reloading problems, testing problems, mode problems… There is
> > certainly enough work to entertain anyone for a longer amount of
> > time while making Yi visibly better.
> >
> > The list of issues is simply an indicator of which problems the
> > second goal of the project will concentrate on, rather than as a
> > promise of which bugs are guaranteed to be fixed by the end of it.
> >
> > Alongside this goal, I'll write any modes for Yi as I find time
> > for them. The completion of concurrency part of the project allows
> > us to write many of the modes frequently requested by people
> > wishing to use Yi which are currently impossible/unfeasible to
> > write.
> >
> > * What deliverables do you think are reasonable targets? Can you
> > outline an approximate schedule of milestones?
> >
> > The plan is based on the GSoC time line:
> > 20 April - 19 May – while this is a bonding period, I'm already a
> > part of the Yi community and have a fair grasp of it. I'd start to
> > look into this project as early as this period (and in fact I plan
> > to make steps towards it before this date which means some of the
> > outlined issues might get fixed early ;) ).
> >
> > 19 May - 23 June – coding period; by this point I expect to have
> > decided on which concurrency model we'll use and have a good idea
> > of how it'll be implemented. By the end of this period,
> > concurrency should either be completed or nearly done, depending
> > on any unexpected problems that might come up. The deliverable
> > would be Yi with (at least some) concurrency support.
> >
> > 24 June - 11 August – second part of the coding period; work on
> > any of the listed (or unlisted bugs) and finish up concurrency if
> > it is still not done. Write extra Yi modes, libraries and
> > documentation as time allows.
> >
> > 11 August - 18 August – post-coding period; write any missing
> > documentation, promote any cool new stuff we wrote ;) While I can
> > not think of a specific deliverable, many bugs should now be
> > fixed, Yi should have a lot more documentation, tests and modes.
> >
> > As a final note regarding the time line, it is not strictly
> > necessary that the project implements concurrency first: while
> > some bugs might need such support, many simply do not. If it's
> > convenient to fix something that I had originally planned to for
> > the second part of the project, I'll do so.
> >
> > * What relevant experience do you have? e.g. Have you coded anything
> > in Haskell? Have you contributed to any other open source software?
> > Been studying advanced courses in a related topic?
> >
> > Second year CS student. I program on regular basis using Haskell.
> > I contribute to a bunch of FOSS projects as it seems necessary
> > (see [my GitHub](https://github.com/Fuuzetsu)).
> > I have successfully completed GSOC in 2013 which involved working
> > on Haddock. To this day I help out with Haddock which often
> > involves looking at the large GHC code base.
> >
> > * In what ways do you envisage interacting with the wider Haskell
> > community during your project? e.g. How would you seek help on
> > something your mentor wasn't able to deal with? How will you get
> > others interested in what you are doing?
> >
> > I have a [blog](http://fuuzetsu.co.uk/blog) which gets propagated
> > onto Haskell Planet. I'm active on IRC and many Haskell-related
> > mailing lists. IRC, mailing lists and any relevant literature is
> > where I'd seek help were I to get stuck on something my mentor
> > can't help me with. I find that news about Yi are very popular and
> > get propagated by the community itself very easily so I doubt
> > there will be any problem getting people interested.
> >
> > I'm very easily reachable over e-mail and IRC and all the
> > development is done in public.
> >
> > * Why do you think you would be the best person to tackle this
> > project?
> >
> > I've been interested in Yi for a couple of months and have already
> > wrote some commits, closed quite a few issues and filed even more
> > issues on my own. I have access to the Yi repository and
> > I help anyone looking to get started with Yi. I have about 2 years of
> > Haskell experience and had my fair share of staring at library
> > code.
> >
> > As mentioned before, I'm active as a member of the community and
> > help out with one of the core Haskell projects (Haddock).
> >
> >
> > --
> > Mateusz K.
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> 
> 
> 
> --
> Michal Antkiewicz, M.Sc., Ph.D
> Research Engineer
> Network for the Engineering of Complex Software-Intensive Systems (NECSIS)
> 
> University of Waterloo
> http://gsd.uwaterloo.ca/mantkiew
> mantkiew at gsd.uwaterloo.ca
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 