Hi all, I'm very excited to announce the first release of Yi since last summer. It is relatively light on new features, but it finally should compile nicely on friendly machines. This means, for the most part, machines with the latest Haskell Platform installed. (Windows, unfortunately, has not been tested all that much. See details below, though, for install info.) ## What's new? * New vte UI. This is a terminal UI inside a GUI, much like gvim. It depends on Gtk2Hs for the GUI, and then launches the vty UI inside the terminal. * Compatibility with the latest Haskell Platform release * Start yi-contrib package. We intend to move more stuff here, to clean up the core yi package. * We're now on GitHub (and mirrored on Google Code)! See below for info. ## What's Yi? Yi is a text editor written in Haskell and extensible in Haskell. The long-term goal of the Yi project is to provide the editor of choice for Haskell programmers. Yi now works relatively well in the terminal, using the vty package, and also has Gtk frontends using vte (which interfaces with the terminal interface) and a Pango frontend. There is also a Cocoa frontend under (slow) development. ## Installation Using cabal install: $ cabal update $ cabal install yi The default UI depends on the vty package, which will only compile with the ncurses development headers available. On Ubuntu, you need to install the `libncurses5-dev` package. On Windows, you'll need to disable the default vty terminal UI, and use a Gtk UI instead (the vte UI requires vty, so you can't install that either): $ cabal install yi -f-vty -fpango (Windows support is not well-tested, though.) Optionally also install the contrib package: $ cabal install yi-contrib ## Features * A purely functional editor core * Key-bindings written as parsers of the input * Emacs, Vim and (partial) Cua emulations provided by default * Console front-end (Gtk2Hs and Cocoa front-ends in development) * Static configuration (XMonad style) for fast load * Haskell support: * Lexical highlighting and (unicode-based) beautification. * Layout-aware parenthesis-matching * Auto-indentation * cabal-build within the editor * Syntax highlighting for a number of other languages (latex, python, perl, ...) ## More Info Read the README [1] on GitHub for more information. The source code [2] is also hosted there. ## Credits This release is brought to you by: * Alexey Levan * Gwern Branwen * Issac Trotts * Jean-Philippe Bernardy * Jeff Wheeler * Jeremy Wall * Maciej Piechotka * Malte Sommerkorn and all the contributors to the previous versions. Also, Yi would not exist without all the work put into the Haskell platform. [1] https://github.com/yi-editor/yi/blob/master/README.md [2] https://github.com/yi-editor/yi -- Jeff Wheeler Undergraduate, Electrical Engineering University of Illinois at Urbana-Champaign
On Fri, 25 Mar 2011 01:23:46 -0500, Jeff Wheeler <wheele11@illinois.edu> wrote:
Hi all,
I'm very excited to announce the first release of Yi since last summer. It is relatively light on new features, but it finally should compile nicely on friendly machines. This means, for the most part, machines with the latest Haskell Platform installed. (Windows, unfortunately, has not been tested all that much. See details below, though, for install info.)
Great work. Pardon me complaining again but it would be much more easier to integrate into ArchLinux if the following changes where made: * mention alex in the cabal file (I don't remember the syntax but there is a way to specify tools needed to build). * depends on latest version of dependencies: pointedlist, rose-zipper Cheers, -- Nicolas Pouillard http://nicolaspouillard.fr
On Mon, Mar 28, 2011 at 7:33 AM, Edward Amsden <eca7215@cs.rit.edu> wrote:
* mention alex in the cabal file (I don't remember the syntax but there is a way to specify tools needed to build). build-tools: alex
in the library/executable section
Oh, my bad. I removed this because alex is included in the Platform, so it seemed like it'd always be available. I'll add it back. I originally pulled pointedlist from Yi, but since switched from data-accessor to fclabels per suggestions by a few people. I also put the repo on github, it's on the yi-editor account page. Do we want to do the same switch on Yi? (I'll readily admit that I don't really know the advantages of data-accessor vs. fclabels.) I don't know about rose-zipper, but I'll look at that. -- Jeff Wheeler Undergraduate, Electrical Engineering University of Illinois at Urbana-Champaign
It's rather off-topic, but I'm curious: what makes fclabels better than data-accessor? The latter seems to be more successful in terms of the number of packages available on Hackage that provide some extra functionality for it. Best regards, Krzysztof Skrzętnicki On Mon, Mar 28, 2011 at 21:40, Jeff Wheeler <wheele11@illinois.edu> wrote:
On Mon, Mar 28, 2011 at 7:33 AM, Edward Amsden <eca7215@cs.rit.edu> wrote:
* mention alex in the cabal file (I don't remember the syntax but there is a way to specify tools needed to build). build-tools: alex
in the library/executable section
Oh, my bad. I removed this because alex is included in the Platform, so it seemed like it'd always be available. I'll add it back.
I originally pulled pointedlist from Yi, but since switched from data-accessor to fclabels per suggestions by a few people. I also put the repo on github, it's on the yi-editor account page. Do we want to do the same switch on Yi? (I'll readily admit that I don't really know the advantages of data-accessor vs. fclabels.)
I don't know about rose-zipper, but I'll look at that.
-- Jeff Wheeler
Undergraduate, Electrical Engineering University of Illinois at Urbana-Champaign
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
On 29 March 2011 06:40, Jeff Wheeler <wheele11@illinois.edu> wrote:
On Mon, Mar 28, 2011 at 7:33 AM, Edward Amsden <eca7215@cs.rit.edu> wrote:
* mention alex in the cabal file (I don't remember the syntax but there is a way to specify tools needed to build). build-tools: alex
in the library/executable section
Oh, my bad. I removed this because alex is included in the Platform, so it seemed like it'd always be available. I'll add it back.
Not *everyone* has the Platform installed! (I prefer to install ghc and then just the libraries I need via my package manager). -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/28/11 17:06 , Ivan Lazar Miljenovic wrote:
On 29 March 2011 06:40, Jeff Wheeler <wheele11@illinois.edu> wrote:
Oh, my bad. I removed this because alex is included in the Platform, so it seemed like it'd always be available. I'll add it back.
Not *everyone* has the Platform installed! (I prefer to install ghc and then just the libraries I need via my package manager).
So you're saying that the Platform is pointless? I think there's some miscommunication going on somewhere, if we're all going to pretend it doesn't exist. - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery.b@gmail.com system administrator [openafs,heimdal,too many hats] kf8nh -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2RMZsACgkQIn7hlCsL25UrNACfaLU53OZXL/qRzhMhU/1+6KvA OksAoNH6aJVlIdmAQQjRnCW8HPgNvOcT =WNJG -----END PGP SIGNATURE-----
On 29 March 2011 12:10, Brandon S Allbery KF8NH <allbery.b@gmail.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 3/28/11 17:06 , Ivan Lazar Miljenovic wrote:
On 29 March 2011 06:40, Jeff Wheeler <wheele11@illinois.edu> wrote:
Oh, my bad. I removed this because alex is included in the Platform, so it seemed like it'd always be available. I'll add it back.
Not *everyone* has the Platform installed! (I prefer to install ghc and then just the libraries I need via my package manager).
So you're saying that the Platform is pointless? I think there's some miscommunication going on somewhere, if we're all going to pretend it doesn't exist.
No, my meaning was that the reasoning of "I don't need to specify this as a dependency since it's part of the Platform" isn't sound since not everyone has the Platform. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/28/11 21:15 , Ivan Lazar Miljenovic wrote:
On 29 March 2011 12:10, Brandon S Allbery KF8NH <allbery.b@gmail.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 3/28/11 17:06 , Ivan Lazar Miljenovic wrote:
On 29 March 2011 06:40, Jeff Wheeler <wheele11@illinois.edu> wrote:
Oh, my bad. I removed this because alex is included in the Platform, so it seemed like it'd always be available. I'll add it back.
Not *everyone* has the Platform installed! (I prefer to install ghc and then just the libraries I need via my package manager).
So you're saying that the Platform is pointless? I think there's some miscommunication going on somewhere, if we're all going to pretend it doesn't exist.
No, my meaning was that the reasoning of "I don't need to specify this as a dependency since it's part of the Platform" isn't sound since not everyone has the Platform.
The point of the Platform is to provide a baseline. So you *are* saying it is pointless, because you want packages to confirm to a different baseline. - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery.b@gmail.com system administrator [openafs,heimdal,too many hats] kf8nh -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2RM5MACgkQIn7hlCsL25UgggCg01PqGZflU7EQdEa03TR9sMEE CrwAoICxWlsJmPhhq3MEbSdkzyR1x+CL =km8w -----END PGP SIGNATURE-----
On 29 March 2011 12:19, Brandon S Allbery KF8NH <allbery.b@gmail.com> wrote:
No, my meaning was that the reasoning of "I don't need to specify this as a dependency since it's part of the Platform" isn't sound since not everyone has the Platform.
The point of the Platform is to provide a baseline. So you *are* saying it is pointless, because you want packages to confirm to a different baseline.
My impression that the Platform was a baseline in regards to "what do I need to get started to develop with Haskell?", and not in terms of specifying dependencies. After all, we still need to specify a dependency on `base' in .cabal files, even though it comes with GHC and other compilers (let alone the Platform)? Consider also people who just want to use software written in Haskell but aren't developers, especially those that use distros like Gentoo that build from source (either by default or optionally for non-packaged software) rather than using pre-built binaries: they aren't going to want to know/care about the Platform, they just want their package manager to get the minimal dependencies that are required to build and install that piece of software. As such, being explicit about build tools is beneficial in this regard (e.g. when gtk2hs was cabalised, how much fun was had when cabal-install couldn't work out that it needed to install gtk2hs-buildtools to get the extra build tools it needed?). -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/28/11 21:29 , Ivan Lazar Miljenovic wrote:
On 29 March 2011 12:19, Brandon S Allbery KF8NH <allbery.b@gmail.com> wrote:
No, my meaning was that the reasoning of "I don't need to specify this as a dependency since it's part of the Platform" isn't sound since not everyone has the Platform.
The point of the Platform is to provide a baseline. So you *are* saying it is pointless, because you want packages to confirm to a different baseline.
My impression that the Platform was a baseline in regards to "what do I need to get started to develop with Haskell?", and not in terms of specifying dependencies. After all, we still need to specify a dependency on `base' in .cabal files, even though it comes with GHC and other compilers (let alone the Platform)?
And it regularly causes annoying dependency issues, including causing cabal to regularly do diamond dependencies. Somehow the Haskell community is hellbent on repeating the mistakes every other community learned about the hard way years ago, especially in the area of dependencies (first refusing to acknowledge the need for upper dependency limits, more recently trying to avoid adding an epoch — and I'm not counting how packages included with the compiler but not recognized as such by Cabal lead directly to Cabal introducing diamond dependency failures). Is this *really* necessary, or should those of us who've seen it before just sit back and watch you all ram your heads against the same brick walls? (Why no, it doesn't look like a brick wall now; that's the point. It *will*. Learn *before* it happens.) - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery.b@gmail.com system administrator [openafs,heimdal,too many hats] kf8nh -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2RODUACgkQIn7hlCsL25VOXwCguwsUCVTZoDyh8FxD9buJkiO5 AzIAoLC61yrpRTi9bmId13hupf1dc9Tl =vL+w -----END PGP SIGNATURE-----
On Mon, Mar 28, 2011 at 6:39 PM, Brandon S Allbery KF8NH < allbery.b@gmail.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 3/28/11 21:29 , Ivan Lazar Miljenovic wrote:
On 29 March 2011 12:19, Brandon S Allbery KF8NH <allbery.b@gmail.com> wrote:
No, my meaning was that the reasoning of "I don't need to specify this as a dependency since it's part of the Platform" isn't sound since not everyone has the Platform.
The point of the Platform is to provide a baseline. So you *are* saying it is pointless, because you want packages to confirm to a different baseline.
My impression that the Platform was a baseline in regards to "what do I need to get started to develop with Haskell?", and not in terms of specifying dependencies. After all, we still need to specify a dependency on `base' in .cabal files, even though it comes with GHC and other compilers (let alone the Platform)?
And it regularly causes annoying dependency issues, including causing cabal to regularly do diamond dependencies.
Somehow the Haskell community is hellbent on repeating the mistakes every other community learned about the hard way years ago, especially in the area of dependencies (first refusing to acknowledge the need for upper dependency limits, more recently trying to avoid adding an epoch — and I'm not counting how packages included with the compiler but not recognized as such by Cabal lead directly to Cabal introducing diamond dependency failures). Is this *really* necessary, or should those of us who've seen it before just sit back and watch you all ram your heads against the same brick walls?
While more precise solutions do exist, cabal-dev solves this rather well in practice via sandboxing. I have not run into the diamond dependency issue even once in several months of using cabal-dev regularly. If I were still using plain-old cabal I would have hit it at least a few times and I probably would have blown away my ghc install a few times as well. I think Ivan's point is: When we can be precise about dependencies we should be. I agree that someone using the HP as a dependency might not realize that Alex is part of that. Depending on the HP is a conservative overapproximation. Once we have more precise information, even if redundant in this case, I think it's appropriate to document it as such. The alternative to that, is for Cabal to know what "HP-2011.1" implies in terms of dependencies and to then be able to check for those things. As I far as I can tell, Cabal does not function that way. Just my $0.02, Jason
On Mon, Mar 28, 2011 at 8:46 PM, Jason Dagit <dagitj@gmail.com> wrote:
I think Ivan's point is: When we can be precise about dependencies we should be. I agree that someone using the HP as a dependency might not realize that Alex is part of that. Depending on the HP is a conservative overapproximation. Once we have more precise information, even if redundant in this case, I think it's appropriate to document it as such. The alternative to that, is for Cabal to know what "HP-2011.1" implies in terms of dependencies and to then be able to check for those things. As I far as
Indeed, I think I definitely should have left the build-depends: alex in there, if for no other reason than that Cabal doesn't read my mailing-list post to know that Yi depends on the Haskell Platform. -- Jeff Wheeler Undergraduate, Electrical Engineering University of Illinois at Urbana-Champaign
On 2011-03-28 20:19:15PM Brandon S Allbery KF8NH <allbery.b@gmail.com> wrote:
On 3/28/11 21:15 , Ivan Lazar Miljenovic wrote:
On 29 March 2011 12:10, Brandon S Allbery KF8NH <allbery.b@gmail.com> wrote:
On 3/28/11 17:06 , Ivan Lazar Miljenovic wrote:
On 29 March 2011 06:40, Jeff Wheeler <wheele11@illinois.edu> wrote:
Oh, my bad. I removed this because alex is included in the Platform, so it seemed like it'd always be available. I'll add it back.
Not *everyone* has the Platform installed! (I prefer to install ghc and then just the libraries I need via my package manager).
So you're saying that the Platform is pointless? I think there's some miscommunication going on somewhere, if we're all going to pretend it doesn't exist.
No, my meaning was that the reasoning of "I don't need to specify this as a dependency since it's part of the Platform" isn't sound since not everyone has the Platform.
The point of the Platform is to provide a baseline. So you *are* saying it is pointless, because you want packages to confirm to a different baseline.
It's reasonable for a package meant to be easily installed to depend on anything from the platform. It's not reasonable for a package to incorrectly specificy its dependencies, just because the union of the specified dependencies and some random platform release happens to provide all the actual dependencies. Brandon
On Mon, 28 Mar 2011 14:40:21 -0500, Jeff Wheeler <wheele11@illinois.edu> wrote:
On Mon, Mar 28, 2011 at 7:33 AM, Edward Amsden <eca7215@cs.rit.edu> wrote:
* mention alex in the cabal file (I don't remember the syntax but there is a way to specify tools needed to build). build-tools: alex
in the library/executable section
Oh, my bad. I removed this because alex is included in the Platform, so it seemed like it'd always be available. I'll add it back.
I originally pulled pointedlist from Yi, but since switched from data-accessor to fclabels per suggestions by a few people. I also put the repo on github, it's on the yi-editor account page. Do we want to do the same switch on Yi? (I'll readily admit that I don't really know the advantages of data-accessor vs. fclabels.)
I would suggest going to fclabels for Yi itself as well.
I don't know about rose-zipper, but I'll look at that.
I think releasing the constraint is enough for rose-zipper. -- Nicolas Pouillard http://nicolaspouillard.fr
participants (9)
-
Brandon Moore -
Brandon S Allbery KF8NH -
Daniel Fischer -
Edward Amsden -
Ivan Lazar Miljenovic -
Jason Dagit -
Jeff Wheeler -
Krzysztof Skrzętnicki -
Nicolas Pouillard