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