Mateusz Kowalczyk | 10 Mar 16:09 2014
Picon

Yi project proposal for GSOC 2014

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
(Continue reading)

Michal Antkiewicz | 10 Mar 16:28 2014
Picon
Picon

Re: Yi project proposal for GSOC 2014

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 <fuuzetsu <at> fuuzetsu.co.uk> 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
Kyle Marek-Spartz | 10 Mar 16:29 2014
Picon

Re: 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
>  

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
mantkiew | 10 Mar 16:41 2014
Picon
Picon

Re: Yi project proposal for GSOC 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
> 

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Daniel Trstenjak | 10 Mar 16:53 2014
Picon

Re: Yi project proposal for GSOC 2014


On Mon, Mar 10, 2014 at 11:41:57AM -0400, mantkiew <at> gsd.uwaterloo.ca wrote:
> 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
> > 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Daniel Trstenjak | 10 Mar 16:58 2014
Picon

Re: Yi project proposal for GSOC 2014


On Mon, Mar 10, 2014 at 11:41:57AM -0400, mantkiew <at> gsd.uwaterloo.ca wrote:
> 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. 

But then you would have to write an interface between Yi and Leksah
and these kind of big interfaces IMHO never really work that well.

I think it makes more sense to have libraries which are shared
by Yi and Leksah, which could also be used by other applications
and therefore are a bigger win for the whole Haskell ecosystem.

Greetings,
Daniel
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Mateusz Kowalczyk | 10 Mar 17:05 2014
Picon

Re: Yi project proposal for GSOC 2014

On 10/03/14 15:58, Daniel Trstenjak wrote:
> 
> On Mon, Mar 10, 2014 at 11:41:57AM -0400, mantkiew <at> gsd.uwaterloo.ca wrote:
>> 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. 
> 
> But then you would have to write an interface between Yi and Leksah
> and these kind of big interfaces IMHO never really work that well.
> 
> I think it makes more sense to have libraries which are shared
> by Yi and Leksah, which could also be used by other applications
> and therefore are a bigger win for the whole Haskell ecosystem.
> 
> 
> Greetings,
> Daniel
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 

Actually, I hear that it's possible to embed Yi inside of Leksah. I have
never tried Leksah out but perhaps that's more of what you're after.

But yes, generic libraries (that can be used by Yi and Leksah) are
certainly a thing that gets written while implementing something (at
least from my experience). It is listed as one of the benefits. It's a
nice side effect I suppose.

--

-- 
Mateusz K.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Vagif Verdi | 10 Mar 17:04 2014
Picon

Re: Yi project proposal for GSOC 2014

I do not think we need more haskell aware editors and IDEs. There's more than enough already: emacs, vim, Eclipse, Leksah, Yi. What we need though is a IDE backend so any editor can use it to provide hakell IDE features. As it stands right now all haskell IDEs reinvent the wheel in some incompatible manner. EclipseFp has scion, some emacs modes develop ghc-mod backend. Leksah lives in its own world. ghci added  some IDE support features recently. This fragmentation hurts us.

I would say making ghci a full-blown IDE backend akin lisps slime-swank or clojure nrepl would be the best approach.


On Monday, March 10, 2014 8:09:49 AM UTC-7, 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
Haskel... <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Michal Antkiewicz | 10 Mar 17:22 2014
Picon
Picon

Re: Yi project proposal for GSOC 2014



I would say making ghci a full-blown IDE backend akin lisps slime-swank or clojure nrepl would be the best approach.
there's already hdevtools which plays that role - it provides all sorts of information to an IDE, like types, location of declarations, etc.  It's a background process and it's quite responsive (tries to be incremental). I don't know how it is implemented and whether it is a wrapper around GHCi.

But I agree that all IDEs should simply use GHCi as the official IDE backend. Maybe some parts from scion/hdevtools/ghc-mod/etc. could be pulled back into GHCi?

Michal
 



On Monday, March 10, 2014 8:09:49 AM UTC-7, 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
Haskel... <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
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
Vagif Verdi | 10 Mar 17:28 2014
Picon

Re: Yi project proposal for GSOC 2014

>there's already hdevtools

There you go. Another one! See what i'm saying? So much wasted effort and a dozen of half baked programs all of which implement low hanging fruit of the same set of basic features and have no resources left to deliver truly powerful and polished capabilities.


On Monday, March 10, 2014 9:22:16 AM UTC-7, Michal Antkiewicz wrote:


I would say making ghci a full-blown IDE backend akin lisps slime-swank or clojure nrepl would be the best approach.
there's already hdevtools which plays that role - it provides all sorts of information to an IDE, like types, location of declarations, etc.  It's a background process and it's quite responsive (tries to be incremental). I don't know how it is implemented and whether it is a wrapper around GHCi.

But I agree that all IDEs should simply use GHCi as the official IDE backend. Maybe some parts from scion/hdevtools/ghc-mod/etc. could be pulled back into GHCi?

Michal
 



On Monday, March 10, 2014 8:09:49 AM UTC-7, 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
Haskel... <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskel... <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
mant... <at> gsd.uwaterloo.ca
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Mateusz Kowalczyk | 10 Mar 17:40 2014
Picon

Re: Yi project proposal for GSOC 2014

On 10/03/14 16:28, Vagif Verdi wrote:
>> there's already hdevtools 
> 
> There you go. Another one! See what i'm saying? So much wasted effort and a 
> dozen of half baked programs all of which implement low hanging fruit of 
> the same set of basic features and have no resources left to deliver truly 
> powerful and polished capabilities. 
> 
> 

FYI, Yi doesn't aim to be an editor for Haskell (although we certainly
strive to support it for obvious reasons). It aims to be written and
‘scriptable’ in Haskell but in the end that's more or less where it
ends. Yi certainly doesn't aim to be a Haskell IDE! We have in fact some
support for variety of things. Here are the just the lexers that Yi
currently has.

-rw-r--r-- 1 shana shana  3135 Dec 23 23:53 Abella.x
-rw-r--r-- 1 shana shana  6192 Mar 10 12:19 Alex.hs
-rw-r--r-- 1 shana shana   460 Dec 13 04:29 BasicTemplate.x
-rw-r--r-- 1 shana shana  4396 Mar 10 12:19 Cabal.x
-rw-r--r-- 1 shana shana  3804 Jan  7 18:51 common.hsinc
-rw-r--r-- 1 shana shana  1172 Mar 10 12:19 Compilation.x
-rw-r--r-- 1 shana shana  4294 Mar 10 12:19 Cplusplus.x
-rw-r--r-- 1 shana shana  4294 Mar 10 12:19 C.x
-rw-r--r-- 1 shana shana  3360 Dec 13 04:29 GitCommit.x
-rw-r--r-- 1 shana shana  5995 Mar 10 12:19 GNUMake.x
-rw-r--r-- 1 shana shana 10378 Mar 10 12:19 Haskell.x
-rw-r--r-- 1 shana shana  9664 Dec 23 23:53 JavaScript.x
-rw-r--r-- 1 shana shana  4229 Mar 10 12:19 Java.x
-rw-r--r-- 1 shana shana  1806 Mar 10 12:19 JSON.x
-rw-r--r-- 1 shana shana 16615 Mar 10 12:19 Latex.x
-rw-r--r-- 1 shana shana  9427 Dec 13 04:29 LiterateHaskell.x
-rw-r--r-- 1 shana shana  4466 Mar 10 12:19 ObjectiveC.x
-rw-r--r-- 1 shana shana  4263 Dec 23 23:53 OCaml.x
-rw-r--r-- 1 shana shana  3438 Mar 10 12:19 Ott.x
-rw-r--r-- 1 shana shana 15750 Mar 10 12:19 Perl.x
-rw-r--r-- 1 shana shana  3520 Mar 10 12:19 Python.x
-rw-r--r-- 1 shana shana  4179 Mar 10 12:19 Ruby.x
-rw-r--r-- 1 shana shana  3191 Mar 10 12:19 Srmc.x
-rw-r--r-- 1 shana shana   914 Mar 10 12:19 SVNCommit.x
-rw-r--r-- 1 shana shana   648 Jan 15 10:16 Whitespace.x

To further reinforce what I'm trying to say, if we ever needed some
IDE-like features for Haskell, we could certainly use hdevtools: they
are 2 completely different projects, without any real overlap.

I hope this clears it up.

--

-- 
Mateusz K.
Brandon Allbery | 10 Mar 18:05 2014
Picon

Re: Yi project proposal for GSOC 2014

On Mon, Mar 10, 2014 at 12:28 PM, Vagif Verdi <vagif.verdi <at> gmail.com> wrote:
>there's already hdevtools

There you go. Another one! See what i'm saying? So much wasted effort and a dozen of half baked programs all of which implement low hanging fruit of the same set of basic features and have no resources left to deliver truly powerful and polished capabilities. 

And what exactly stops your one-to-rule-them-all from just becoming yet another one? (Or: what exactly means that the world will flock to your proposal instead of continuing to do what it already does?) As far as I can see, it is based on wishful thinking alone.

Build a consensus *first* and make sure you're serving everyone else's needs and that everyone else is interested. Otherwise you end up with https://xkcd.com/927/.

--
brandon s allbery kf8nh                               sine nomine associates
allbery.b <at> gmail.com                                  ballbery <at> sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Vagif Verdi | 10 Mar 18:19 2014
Picon

Re: Yi project proposal for GSOC 2014

>And what exactly stops your one-to-rule-them-all from just becoming yet another one?

We are not discussing here what tool is the best and try to mandate everyone to use it. We are discussing how to efficiently use the scarce development resources (time, money) for the benefit of haskell community.

It does not matter if the specific tool will succeed in adoption or not. Trying to create one is still the best course of action.

>Build a consensus *first*

The consensus is already there. It is obvious the demand for such tool is high, hence many (failed) attempts. Failed because of the lack of resources and coordination.

>As far as I can see, it is based on wishful thinking alone.

I already pointed at existing successful implementations (clojure's nrepl and lisps slime-swank). If they can do it, so can we.


On Monday, March 10, 2014 10:05:41 AM UTC-7, Brandon Allbery wrote:
On Mon, Mar 10, 2014 at 12:28 PM, Vagif Verdi <vagif... <at> gmail.com> wrote:
>there's already hdevtools

There you go. Another one! See what i'm saying? So much wasted effort and a dozen of half baked programs all of which implement low hanging fruit of the same set of basic features and have no resources left to deliver truly powerful and polished capabilities. 

And what exactly stops your one-to-rule-them-all from just becoming yet another one? (Or: what exactly means that the world will flock to your proposal instead of continuing to do what it already does?) As far as I can see, it is based on wishful thinking alone.

Build a consensus *first* and make sure you're serving everyone else's needs and that everyone else is interested. Otherwise you end up with https://xkcd.com/927/.

--
brandon s allbery kf8nh                               sine nomine associates
allb... <at> gmail.com                                  ball... <at> sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Ketil Malde | 17 Mar 22:10 2014

Re: Yi project proposal for GSOC 2014


> We are not discussing here what tool is the best and try to mandate 
> everyone to use it. We are discussing how to efficiently use the scarce 
> development resources (time, money) for the benefit of haskell community.

Well, in the end the proposals will be voted over.  Less general
proposals are likely to get fewer votes.

> The consensus is already there. It is obvious the demand for such tool is 
> high, hence many (failed) attempts. Failed because of the lack of resources 
> and coordination.

Say what?  I'm not familiar with the others, but Emacs and haskell-mode
and ghc-mode and darcsum works pretty well for me - I'd certainly not
call them failures.

(Of course, I would rather see somebody spending GSoC working on them,
but I accept that other people prefer other systems.  But while I'm at
it, some things I might like to see would be:

  - quickcheck/flymake support, so that funcitons with failing unit
    tests are highlighted automatically
  - code coverage highlighting in buffer
  - org-mode-like folding and refiling 
  - automatic import/export list management
  - perhaps easy navigation between source and core?
)

-k
--

-- 
If I haven't seen further, it is by standing in the footprints of giants
Mateusz Kowalczyk | 17 Mar 23:31 2014
Picon

Re: Yi project proposal for GSOC 2014

On 17/03/14 21:10, Ketil Malde wrote:
> 
>> We are not discussing here what tool is the best and try to mandate 
>> everyone to use it. We are discussing how to efficiently use the scarce 
>> development resources (time, money) for the benefit of haskell community.
> 
> Well, in the end the proposals will be voted over.  Less general
> proposals are likely to get fewer votes.
> 
>> The consensus is already there. It is obvious the demand for such tool is 
>> high, hence many (failed) attempts. Failed because of the lack of resources 
>> and coordination.
> 
> Say what?  I'm not familiar with the others, but Emacs and haskell-mode
> and ghc-mode and darcsum works pretty well for me - I'd certainly not
> call them failures.
> 
> (Of course, I would rather see somebody spending GSoC working on them,
> but I accept that other people prefer other systems.  But while I'm at
> it, some things I might like to see would be:
> 
>   - quickcheck/flymake support, so that funcitons with failing unit
>     tests are highlighted automatically
>   - code coverage highlighting in buffer
>   - org-mode-like folding and refiling 
>   - automatic import/export list management
>   - perhaps easy navigation between source and core?
> )
> 
> -k
> 

As I pointed out, Yi is not one of these attempts. The people in this
sub-thread made their own thread (Haskell IDEs or something) so you
might want to reply there.

--

-- 
Mateusz K.
Daniel Trstenjak | 10 Mar 18:27 2014
Picon

Re: Yi project proposal for GSOC 2014


On Mon, Mar 10, 2014 at 09:28:50AM -0700, Vagif Verdi wrote:
> There you go. Another one! See what i'm saying? So much wasted effort and a
> dozen of half baked programs all of which implement low hanging fruit of the
> same set of basic features and have no resources left to deliver truly powerful
> and polished capabilities.

Sorry, but I don't like this kind of attitude.

Wasted effort? People having fun hacking around and perhaps don't want
to coordinate with several people to get something done, because that's
what they already have to do at their day job.

It's a lot of work to get something powerful and polished, and in a lot
of cases this doesn't even happen in a commercial setting and even
fewer people will do it in their spare time.

> 
> 
> On Monday, March 10, 2014 9:22:16 AM UTC-7, Michal Antkiewicz wrote:
> 
> 
> 
> 
>         I would say making ghci a full-blown IDE backend akin lisps slime-swank
>         or clojure nrepl would be the best approach.
> 
>     there's already hdevtools which plays that role - it provides all sorts of
>     information to an IDE, like types, location of declarations, etc.  It's a
>     background process and it's quite responsive (tries to be incremental). I
>     don't know how it is implemented and whether it is a wrapper around GHCi.
> 
>     But I agree that all IDEs should simply use GHCi as the official IDE
>     backend. Maybe some parts from scion/hdevtools/ghc-mod/etc. could be pulled
>     back into GHCi?
> 
>     Michal
>      
> 
> 
> 
> 
>         On Monday, March 10, 2014 8:09:49 AM UTC-7, 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
>             Haskel... <at> haskell.org
>             http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
> 
>         _______________________________________________
>         Haskell-Cafe mailing list
>         Haskel... <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
>     mant... <at> gsd.uwaterloo.ca
> 

> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Carter Schonwald | 10 Mar 20:20 2014
Picon

Re: Yi project proposal for GSOC 2014

guys, move the yak shaving / shedding to another thread please, 

lets Help give Mateusz feedback for his proposal on contributing to a haskell editor.

What are some ancillary sub tasks you can do independent of the concurrency piece? Concurrency is hard and evil and tricky. It'd be great if you work that out, but *IF* that blows up into a thorny mess, what are some other sub projects you plan to do either way?

-Carter


On Mon, Mar 10, 2014 at 1:27 PM, Daniel Trstenjak <daniel.trstenjak <at> gmail.com> wrote:

On Mon, Mar 10, 2014 at 09:28:50AM -0700, Vagif Verdi wrote:
> There you go. Another one! See what i'm saying? So much wasted effort and a
> dozen of half baked programs all of which implement low hanging fruit of the
> same set of basic features and have no resources left to deliver truly powerful
> and polished capabilities.

Sorry, but I don't like this kind of attitude.

Wasted effort? People having fun hacking around and perhaps don't want
to coordinate with several people to get something done, because that's
what they already have to do at their day job.

It's a lot of work to get something powerful and polished, and in a lot
of cases this doesn't even happen in a commercial setting and even
fewer people will do it in their spare time.









>
>
> On Monday, March 10, 2014 9:22:16 AM UTC-7, Michal Antkiewicz wrote:
>
>
>
>
>         I would say making ghci a full-blown IDE backend akin lisps slime-swank
>         or clojure nrepl would be the best approach.
>
>     there's already hdevtools which plays that role - it provides all sorts of
>     information to an IDE, like types, location of declarations, etc.  It's a
>     background process and it's quite responsive (tries to be incremental). I
>     don't know how it is implemented and whether it is a wrapper around GHCi.
>
>     But I agree that all IDEs should simply use GHCi as the official IDE
>     backend. Maybe some parts from scion/hdevtools/ghc-mod/etc. could be pulled
>     back into GHCi?
>
>     Michal
>
>
>
>
>
>         On Monday, March 10, 2014 8:09:49 AM UTC-7, 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
>             Haskel... <at> haskell.org
>             http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>         _______________________________________________
>         Haskell-Cafe mailing list
>         Haskel... <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
>     mant... <at> gsd.uwaterloo.ca
>

> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Mateusz Kowalczyk | 11 Mar 07:22 2014
Picon

Re: Yi project proposal for GSOC 2014

On 10/03/14 19:20, Carter Schonwald wrote:
> guys, move the yak shaving / shedding to another thread please,
> 
> lets Help give Mateusz feedback for his proposal on contributing to a
> haskell editor.
> 
> What are some ancillary sub tasks you can do independent of the concurrency
> piece? Concurrency is hard and evil and tricky. It'd be great if you work
> that out, but *IF* that blows up into a thorny mess, what are some other
> sub projects you plan to do either way?
> 
> -Carter
> 

There are a lot. Nearly all of the other part (see the mentioned
tickets) can be done without concurrency being in place which is I
mention that the project isn't linear. The concurrency is not a blocker
for everything else.

The only thing that the concurrency blocks are editor modes that I'd
like to write iff there is time, however if I do find time that means
concurrency is done ;).

--

-- 
Mateusz K.
Edward Kmett | 10 Mar 23:18 2014
Picon

Re: Yi project proposal for GSOC 2014

Yi isn't a tool designed solely to edit Haskell source code any more than vim is designed solely to edit vim-script.

As far as I'm aware the only editor to swallow its tail to that point where editing other file types is largly a side-goal is emacs. ;)

Leksah and Yi have very different goals. 

Yi could profitably exist without any integration with ghci for editing other languages, as its stated goal is to be an editor scriptable with Haskell, much like emacs is an editor scriptable with elisp.

Leksah aspires to be an IDE.

Lashing out at the existence of Yi, because it might be used by someone some day to edit Haskell seems misguided and rather off topic to the subject of working on the concurrency aspects of a text editor.

-Edward



On Mon, Mar 10, 2014 at 12:04 PM, Vagif Verdi <vagif.verdi <at> gmail.com> wrote:
I do not think we need more haskell aware editors and IDEs. There's more than enough already: emacs, vim, Eclipse, Leksah, Yi. What we need though is a IDE backend so any editor can use it to provide hakell IDE features. As it stands right now all haskell IDEs reinvent the wheel in some incompatible manner. EclipseFp has scion, some emacs modes develop ghc-mod backend. Leksah lives in its own world. ghci added  some IDE support features recently. This fragmentation hurts us.

I would say making ghci a full-blown IDE backend akin lisps slime-swank or clojure nrepl would be the best approach.



On Monday, March 10, 2014 8:09:49 AM UTC-7, 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
Haskel... <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Roman Cheplyaka | 10 Mar 17:13 2014

Re: Yi project proposal for GSOC 2014

* Mateusz Kowalczyk <fuuzetsu <at> fuuzetsu.co.uk> [2014-03-10 15:09:49+0000]
> 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.

From what I've seen, the less uncertainty there is in a GSoC project, the better
it works. For example, the situation in your past GSoC project where it was
decided in the middle that instead of implementing markdown syntax you're going
to do other things is undesirable, IMO.

3 months is a very short time for a research project. (By research I mean not
academic research, but finding a way (or the best way) to do something.)
And here you're basically saying "there are several ways to do that, we'll
figure out what to do as we go".

If, on the other hand, it was already decided what the right architecture for
concurrency in Yi should be, and it was just a matter of someone doing the work,
it would be a good project.

Roman
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Mateusz Kowalczyk | 10 Mar 17:27 2014
Picon

Re: Yi project proposal for GSOC 2014

On 10/03/14 16:13, Roman Cheplyaka wrote:
> * Mateusz Kowalczyk <fuuzetsu <at> fuuzetsu.co.uk> [2014-03-10 15:09:49+0000]
>> 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.
> 
> From what I've seen, the less uncertainty there is in a GSoC project, the better
> it works. For example, the situation in your past GSoC project where it was
> decided in the middle that instead of implementing markdown syntax you're going
> to do other things is undesirable, IMO.

That was indeed unfortunate. Well, technically Markdown was only part of
the project and ‘the other things’ were the other part of the project. I
do understand where you're coming from however.

> 3 months is a very short time for a research project. (By research I mean not
> academic research, but finding a way (or the best way) to do something.)
> And here you're basically saying "there are several ways to do that, we'll
> figure out what to do as we go".

We're aware of this. The problem is that if I were to conduct this
research starting today and it takes a week to settle on which approach
we'll take, we end up with close to no discussion period as the proposal
submissions are open for 10 days. I left it open like this because it's
an implementation detail: after playing with it for a few days, it might
turn out that the FRP approach is actually amazing and we should do
that. I'd rather not tie myself to a specific implementation before even
considering other options. If I state today that we'll use STM, I'm
stuck with STM even if it turns out a terrible idea. In the end the goal
is to allow for concurrency in the editor state, and that much should be
clear.

> If, on the other hand, it was already decided what the right architecture for
> concurrency in Yi should be, and it was just a matter of someone doing the work,
> it would be a good project.

In this case, deciding on the right architecture is part of doing the work.

> Roman
> 

--

-- 
Mateusz K.
John Lato | 11 Mar 00:43 2014
Picon

Re: Yi project proposal for GSOC 2014

I think this has potential to be a good proposal, although I have a few concerns:

1.  It's a bifurcated proposal, with two major components.  I think the proposal would be stronger if you address more either how adding concurrency will help with all those tickets, or other features that should be supported in yi but can't with the current design.  You give a few examples further down, but at present it reads (to me) as though you want to add concurrency just for the sake of it.

2.  Despite the well-known fact that Concurrency is Hard, in many ways Haskell provides better tools to manage concurrency than many other languages.  There are so many options, that sometimes people have difficulty knowing what to pick.  This work seems to provide an obvious benefit to the Haskell community in that others can see what you chose, why, and how it worked in practice (including any pitfalls).

Out of your benefits to the Haskell community, IMHO 2) and 3) are solid but 1) is rather general and conceivably would apply to any proposal.  Unless you have specific library deliverables in mind, I'd suggest starting with your third point.

These aren't really technical concerns, rather they're about the language/focus of your proposal.  Although I do think this is an ambitious project, the scope as you've defined it might be manageable within a GSOC.  That said, I wouldn't be surprised if adding concurrency takes more time than you've allocated, or is a source of new bugs that you'll have to fix, thereby preventing you from working on the bugs you've already identified.

Cheers,
John L.


On Mon, Mar 10, 2014 at 8:09 AM, Mateusz Kowalczyk <fuuzetsu <at> fuuzetsu.co.uk> 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

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Mateusz Kowalczyk | 11 Mar 07:42 2014
Picon

Re: Yi project proposal for GSOC 2014

On 10/03/14 23:43, John Lato wrote:
> I think this has potential to be a good proposal, although I have a few
> concerns:
> 
> 1.  It's a bifurcated proposal, with two major components.  I think the
> proposal would be stronger if you address more either how adding
> concurrency will help with all those tickets, or other features that should
> be supported in yi but can't with the current design.  You give a few
> examples further down, but at present it reads (to me) as though you want
> to add concurrency just for the sake of it.

Actually, the tickets mentioned are not affected (much) by concurrency
being implemented or not. Here are some things that lack of concurrency
does affect at the moment:

* Can't do periodic events

* Can't wait for a process output in the background (an easy test is to
ask Yi to run a ‘sleep 2000’ system command). This is a big deal for
interacting with things like flyspell or ghc-mod.

* Can't do networking

* Can't do <insert anything that takes time or periodic updates>

When I say it can't do it, I mean ‘can't do it without stopping
everything else including the interface’. This is a big problem for an
editor because it means we can't write many, many of the editor modes
that people pretty much require nowadays: flyspell, flycheck,
compilation, <insert your favourite mode here>. What Yi can do are
‘static’ modes such as dired: they do not require background updates or
anything of the sort so they are fine in a single thread most of the
time. Any longer editor actions effectively lock up the interface for
the user. I'd wager that your own text editor performs some of these
actions that we couldn't feasibly implement in Yi right now.

> 2.  Despite the well-known fact that Concurrency is Hard, in many ways
> Haskell provides better tools to manage concurrency than many other
> languages.  There are so many options, that sometimes people have
> difficulty knowing what to pick.  This work seems to provide an obvious
> benefit to the Haskell community in that others can see what you chose,
> why, and how it worked in practice (including any pitfalls).
> 
> Out of your benefits to the Haskell community, IMHO 2) and 3) are solid but
> 1) is rather general and conceivably would apply to any proposal.  Unless
> you have specific library deliverables in mind, I'd suggest starting with
> your third point.

In hindsight I also think that 1) should be moved down and 2) and 3) up.
I think it was simply the first thing to come to my mind. I mention it
because it may seem surprising to some people that in fact, even if they
are not interested in Yi, they might still benefit from new libraries if
nothing else. I don't have any specific deliverables here so I'll
probably switch the points around as you recommend.

> These aren't really technical concerns, rather they're about the
> language/focus of your proposal.  Although I do think this is an ambitious
> project, the scope as you've defined it might be manageable within a GSOC.
>  That said, I wouldn't be surprised if adding concurrency takes more time
> than you've allocated, or is a source of new bugs that you'll have to fix,
> thereby preventing you from working on the bugs you've already identified.

I also think concurrency might take a rather long time but as I already
am involved with Yi, I do not plan to put it off to the day 1 of coding
period which should give me a good head start. While it's technically
not part of the proposal, I don't really plan on sitting doing nothing
with Yi until the project starts and then be swarmed with work.

I think that the >1 month of the coding period I allocated will be
enough at that point. It is a fair point about any new bugs which is why
I say that I do not guarantee every single bug I mentioned will be
closed but rather serve as a guideline of what I'll work on in the
second part.

> Cheers,
> John L.

--

-- 
Mateusz K.
Carter Schonwald | 11 Mar 09:04 2014
Picon

Re: Yi project proposal for GSOC 2014

I should point out that the ways Vim and Emacs (and others like Sublime / Textmate) do those plugins is they often run them in a subprocess.

Now i agree that having in process multi threading would be a good thing, I merely point out that there are ways to add the plugins you outline that need not depend on fully resolving the concurrency story. 

Yes, not calling a subprocess and stuff will be much better, just pointing out there are *ungodly* but feasible alternative hacks. 

:) 
-Carter


On Tue, Mar 11, 2014 at 2:42 AM, Mateusz Kowalczyk <fuuzetsu <at> fuuzetsu.co.uk> wrote:
On 10/03/14 23:43, John Lato wrote:
> I think this has potential to be a good proposal, although I have a few
> concerns:
>
> 1.  It's a bifurcated proposal, with two major components.  I think the
> proposal would be stronger if you address more either how adding
> concurrency will help with all those tickets, or other features that should
> be supported in yi but can't with the current design.  You give a few
> examples further down, but at present it reads (to me) as though you want
> to add concurrency just for the sake of it.

Actually, the tickets mentioned are not affected (much) by concurrency
being implemented or not. Here are some things that lack of concurrency
does affect at the moment:

* Can't do periodic events

* Can't wait for a process output in the background (an easy test is to
ask Yi to run a ‘sleep 2000’ system command). This is a big deal for
interacting with things like flyspell or ghc-mod.

* Can't do networking

* Can't do <insert anything that takes time or periodic updates>

When I say it can't do it, I mean ‘can't do it without stopping
everything else including the interface’. This is a big problem for an
editor because it means we can't write many, many of the editor modes
that people pretty much require nowadays: flyspell, flycheck,
compilation, <insert your favourite mode here>. What Yi can do are
‘static’ modes such as dired: they do not require background updates or
anything of the sort so they are fine in a single thread most of the
time. Any longer editor actions effectively lock up the interface for
the user. I'd wager that your own text editor performs some of these
actions that we couldn't feasibly implement in Yi right now.

> 2.  Despite the well-known fact that Concurrency is Hard, in many ways
> Haskell provides better tools to manage concurrency than many other
> languages.  There are so many options, that sometimes people have
> difficulty knowing what to pick.  This work seems to provide an obvious
> benefit to the Haskell community in that others can see what you chose,
> why, and how it worked in practice (including any pitfalls).
>
> Out of your benefits to the Haskell community, IMHO 2) and 3) are solid but
> 1) is rather general and conceivably would apply to any proposal.  Unless
> you have specific library deliverables in mind, I'd suggest starting with
> your third point.

In hindsight I also think that 1) should be moved down and 2) and 3) up.
I think it was simply the first thing to come to my mind. I mention it
because it may seem surprising to some people that in fact, even if they
are not interested in Yi, they might still benefit from new libraries if
nothing else. I don't have any specific deliverables here so I'll
probably switch the points around as you recommend.

> These aren't really technical concerns, rather they're about the
> language/focus of your proposal.  Although I do think this is an ambitious
> project, the scope as you've defined it might be manageable within a GSOC.
>  That said, I wouldn't be surprised if adding concurrency takes more time
> than you've allocated, or is a source of new bugs that you'll have to fix,
> thereby preventing you from working on the bugs you've already identified.

I also think concurrency might take a rather long time but as I already
am involved with Yi, I do not plan to put it off to the day 1 of coding
period which should give me a good head start. While it's technically
not part of the proposal, I don't really plan on sitting doing nothing
with Yi until the project starts and then be swarmed with work.

I think that the >1 month of the coding period I allocated will be
enough at that point. It is a fair point about any new bugs which is why
I say that I do not guarantee every single bug I mentioned will be
closed but rather serve as a guideline of what I'll work on in the
second part.

> Cheers,
> John L.

--
Mateusz K.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Mateusz Kowalczyk | 11 Mar 09:11 2014
Picon

Re: Yi project proposal for GSOC 2014

On 11/03/14 08:04, Carter Schonwald wrote:
> I should point out that the ways Vim and Emacs (and others like Sublime /
> Textmate) do those plugins is they often run them in a subprocess.
> 
> Now i agree that having in process multi threading would be a good thing, I
> merely point out that there are ways to add the plugins you outline that
> need not depend on fully resolving the concurrency story.
> 
> Yes, not calling a subprocess and stuff will be much better, just pointing
> out there are *ungodly* but feasible alternative hacks.
> 
> :)
> -Carter
> 

I am far too well aware of this ;P The reason why I'm not even
mentioning this as a possibility is because it is a terrible thing to do
and requires a lot of juggling to behave more or less like you'd want
it. Even today I have my emacs freeze up when I run cabal repl inside of
it for the first time.

Also as I mentioned, we have no means to periodically run things, which
means we can't periodically query our subprocess. There is no mechanism
for such scheduling and while doing it in a single thread like emacs and
vim do is *a* way to do it, you yourself point out that it's sub-par.

So yeah, I'm not even starting to consider that option, I don't want to
end up with yet another editor that doesn't do actual concurrency.

--

-- 
Mateusz K.
Evan Laforge | 11 Mar 21:46 2014
Picon

Re: Yi project proposal for GSOC 2014

I support this idea for purely selfish reasons.  I write haskell in
vim, and I'm constantly bothered by vim bugs that will likely never be
fixed, and I don't dare try to fix them myself because vim source is
such a jungle.  I have several extensions for syntactic manipulation
written in vimscript and python, and they mostly work but not entirely
reliably because vim extension is clumsy.  I use tags and they also
have problems, but once again I'm not about to go in and redo vim's
tag support.  Etc. etc.

Yi is tempting because it promises to be a place where I could fix
these things for real, but I've been discouraged in the past by
immaturity (can't even get it to build) and lack of documentation.  So
I think some concentrated attention to the build, documentation,
general cleanliness, and performance would be a great idea.  I'm not
too fussed about a lack of concurrency since I think there are more
fundamental problems, but if it would result in improvements to those
fundamental problems, I'm all for it.
Mateusz Kowalczyk | 11 Mar 21:57 2014
Picon

Re: Yi project proposal for GSOC 2014

On 11/03/14 20:46, Evan Laforge wrote:
> I support this idea for purely selfish reasons.  I write haskell in
> vim, and I'm constantly bothered by vim bugs that will likely never be
> fixed, and I don't dare try to fix them myself because vim source is
> such a jungle.  I have several extensions for syntactic manipulation
> written in vimscript and python, and they mostly work but not entirely
> reliably because vim extension is clumsy.  I use tags and they also
> have problems, but once again I'm not about to go in and redo vim's
> tag support.  Etc. etc.

I do hope that this is where a lot of support for Yi will come from.

> Yi is tempting because it promises to be a place where I could fix
> these things for real, but I've been discouraged in the past by
> immaturity (can't even get it to build) and lack of documentation.  So
> I think some concentrated attention to the build, documentation,
> general cleanliness, and performance would be a great idea.  I'm not
> too fussed about a lack of concurrency since I think there are more
> fundamental problems, but if it would result in improvements to those
> fundamental problems, I'm all for it.
> 

While there are more fundamental problems as you mention, we don't stand
a chance without concurrency to come close to what existing editors can do.

Certainly documentation will get written during the project. I don't
explicitly mention it partly because it should implied that we document
what we're doing and partly because Google doesn't allow for
documentation projects so I didn't want to make it sound like one.

PS: If you can't get it to build or are struggling otherwise, please pop
into #yi on Freenode and we will almost certainly be able to help you
(although you might have to wait for one of us to be online). There's
also a mailing list although you might have to wait a bit longer
(although a reply is more certain). If you have any specific issues
(even if they are “Please document XYZ”), please do make issues on GitHub!

--

-- 
Mateusz K.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Mateusz Kowalczyk | 17 Mar 11:40 2014
Picon

Re: Yi project proposal for GSOC 2014

On 10/03/14 15:09, 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!
> 
> 
> [snip]

It was about 5 days now so I'll be submitting the proposal with minor
changes we discussed.

Thanks!

--

-- 
Mateusz K.

Gmane