[Haskell-cafe] Yi project proposal for GSOC 2014
Carter Schonwald
carter.schonwald at gmail.com
Mon Mar 10 19:20:25 UTC 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140310/5fee7b89/attachment.html>
More information about the Haskell-Cafe
mailing list