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@gmail.com> 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
same set of basic features and have no resources left to deliver truly
On Mon, Mar 10, 2014 at 09:28:50AM -0700, Vagif Verdi wrote: the 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...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskel...@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...@gsd.uwaterloo.ca
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe