From: Bulat Z. <bul...@gm...> - 2006-07-03 15:10:20
|
Hello Thiago, Monday, July 3, 2006, 4:18:01 PM, you wrote: >> - background compilation with errors highlighting > There is already some support for background compilation using GHC. > Error highlighting doesn't still work as I'd like to, but is there > too. now i'm using editor with just syntax highlighting and therefore i wrote about things those lacking are most important for me. first is the compilation. after i've compiled program i don't like to find files, go to specified line just because i'm not Ceasar and can't think about files/lines and program bugs simultaneously. why the error highlighting is a problem? GHC even supports -ferror-spans option in which emacs-style error message is printed (i.e. it includes the exact range of lines/chars what contain error) the next problem is slowness of GHC compilation. There are whole range of methods to deal with it: 1) background compilation, as you already implemented 2) fast "precompilation" with hugs and reporting bugs it encountered and then "true" compilation with ghc - of course, for this sort of scenario the program should be compatible with both compilers 3) "wide" compilation scheme - on first step compile all modules just searching for syntax errors (which should be much faster) and on the second step perform full compilation 4) using GHCi - it's a 2-3 times faster than GHC and moreover you will drop the startup time and the linking time. This also can be combined with GHC compilation - after module has been successfully compiled with GHCi and programmer continues to further develop his code, GHC can be invoked in background to recompile the modules and make them faster work / faster load in next GHCi session 5) using the GHC library to find simple errors just while editing so compilation in most cases will be successful this list contains all ideas i can recall. i personally like the last variant. of course, the compilation should still be performed in background, it just be called much less often and programmer will not wait for its completion. on the other side, for debugging, 4th variant will be more interesting i also mentioned tight integration with WinHugs. are you seen WinHugs 2006 version? are you able to see it? look at least at http://haskell.org/haskellwiki/WinHugs (Win)Hugs remains the fastest way to debug haskell programs and new WinHugs adds new pretty look and usability features to this story. one especially important one is ability to position editor just at the line containing error. It's already supported for Vim and i will be glad to see the same support for Eclipse. May be it just need adding instructions about setting up editor's call (for Vim it is "gvim.exe --remote-silent +%d %s") The almost complete support for WinHugs should include just two facilities: 1) save all, run modified files through the CPP, load module specified 2) same as above plus run the function specified (running modules through C preprocessor required because WinHugs can't preprocess modules and developing any serious program as compatible both with Hugs and GHC is impossible without conditional compilation) >> - syntax highlighting, including highlighting of bracket's pair > There is already some of this too, although it may not be exactly what > you have in mind. i'm spoiled with vim-like one in FAR :) >> - ability to "fall in" definition of identifier under cursor > Being worked on. Should be one of the leading features on the next > release, together with some more code completion. i does it on Vim, using modified hasktags (original one finds only functions with explicit signatures). if Eclipse supports 'tags' file, it should be relatively easy, at least for global identifiers (although field names and class methods will be out of luck in this case). what set of indexed identifiers you are plan to support? >> - automatic management of import lists > Being worked on, together with code completion. I would like some more > detail here, though. if compiler complains about missing identifiers, the plugin should find module where it defined and add this module name (or this identifier if module already imported with just some identifiers) to import list. i personally keep import list splitted into two parts - global and local modules of current project, each list sorted alphabetically it will be also great to delete from import list unused modules/identifiers, but that is very low on my priority list >> - auto-indenting with user-tuned style > This one seems very challenging and interesting, not a must-have for > me but a very attractive feature. You can start with indenting after lines with "special" words (such as if, when and so on). The catch is what in Haskell many "control structures" are finished on the same line they are started or just partially applied and passed as parameters to some other functions :) I personally want to see as "control structures" many functions i defined myself. It's also true for syntax highlighting - my current syntax file contains as "reserved words" the "return", "when", "forever", "block" and many other function names also i should mention that Emacs haskell mode, afaik, already does it. you can try to borrow their experience? > I have purposely left some items behind, just because resources are > limited and we need to focus on some more valuable features. Do you > think the ones I selected are the most valuable ones? i tried to sort them in the importance order and for me the first 4 are most important (i often need them in my development process): - background compilation with errors highlighting - integration with WinHugs - syntax highlighting, including highlighting of bracket's pair - ability to "fall in" definition of identifier under cursor > Would you mind to delve into some more detail on the topics above on > the EclipseFP mailing list? I am particularly interested on these four > (in order of priority): > - ability to "fall in" definition of identifier under cursor > - automatic management of import lists > - syntax highlighting > - auto-indenting with user-tuned style i've said about everything except for syntax highlighting. there is no much to say - editor i use has vim-like features, which means that it's really great in this area. may be there is some Eclipse package that does the same? one feature i forgot to mention is code navigation. The structured code navigation should, imho, include files in the project mirroring the directory structure and on the next level each file should be splitted to "sections". In the absence of classes splitting to sections is widely used for the Haskell source files. For example, GHC library sources contains the following section headings: -- ----------------------------------------------------------------------------- -- Handy IOErrors -- ----------------------------------------------------------------------------- -- Handle Finalizers and so on. I personally adopted this headings style but it will be great to just allow to use regexp to define it. And inside each section one can see the identifiers it define Another, unstructured view should just list all identifiers in project and type in several chars from the identifier name to locate it in list. It's an explanation of this very helpful feature: my shell (FAR manager) saves all the commands i use (now this list contains ~5000 ones!) and when i open this list and start to type some word, it just filers whole list and show only commands which contains this sequence of letters. that is damn useful. just for example i open this window and typed "hugs" - FAR filters out 146 commands which includes this word: ---------------------------- Commands history *[hugs](146/5144) -------------------------- t C:\Base\Compiler\Hugs\runhugs.exe +st.qkoOuI -98 nocmt.hs <Key_Func.hs t C:\Base\Compiler\Hugs\runhugs.exe +st.qkoOuI -98 nocmt.hs <Key_Func.hs|more t C:\Base\Compiler\Hugs\runhugs.exe +st.qkoOuI -98 Win32Files.hs t C:\Base\Compiler\Hugs\runhugs.exe +st.qkoOuI -98 Signals.hs t C:\Base\Compiler\Hugs\runhugs.exe +st.qkoOuI -98 Array.hs fc /b C:\Downloads\????????????????\Haskell\MinHugs_2005-11-01.exe MinHugs_2005-11-01.exe t C:\Base\Compiler\Hugs\runhugs.exe +st.qkoOuI -98 B.hs hugs.pdf winhugs.exe -c200 .................. > You can subscribe to our mailing list on > http://lists.sourceforge.net/mailman/listinfo/eclipsefp-develop done >> Are you use GHC library? > Not yet, but it may turn to be a very wise decision to make in the > future. Simon said in his paper that many great features of Visual Haskell would be impossible without GHC running in background > EclipseFP is being written in Java, I wonder how the GHC > library would be accessed on such a environment. Need to take a look > at the paper. http://haskell.org/haskellwiki/InterfacingOtherLanguages#Java -- Best regards, Bulat mailto:Bul...@gm... |
From: Thiago A. <thi...@gm...> - 2006-07-03 16:33:44
|
Leif, On 7/3/06, Leif Frenzel <hi...@le...> wrote: > I think the way to go is to call it via JNI. This has worked fine for me > in the past on Windows with dlls Although it required quite some glue code written in C, and it did not look very pretty. Have you already taken a look at this thing here http://sourceforge.net/projects/jvm-bridge/ Seems like it will free us from writing much of the glue code. I will definetely experiment with the GHC library + JVM-Bridge, it seems very much promising. Has anyone actually tried something like that? Cheers, Thiago Arrais |
From: Thiago A. <thi...@gm...> - 2006-07-04 02:34:05
|
Bulat, Thank you for the detailed responses. I apologize for not answering before, I was waiting for a quieter time to be able to answer properly. On 7/3/06, Bulat Ziganshin <bul...@gm...> wrote: > now i'm using editor with just syntax highlighting and therefore i > wrote about things those lacking are most important for me. first is > the compilation. I agree with you, background compilation is the most important feature for me too. Therefore, I will try to work on this for the next release. I am looking for a Cabal-integrated build system and planning to delegate all the work (like dependency fetching and selective compilation) to the chosen build system instead of implementing it as part of EclipseFP. I think I will experiment with this approach. EclipseFP distributes live builds for every modification to the source code. Can I contact you when those builds start to be available? Would you mind trying them? > after i've compiled program i don't like to find > files, go to specified line just because i'm not Ceasar and can't > think about files/lines and program bugs simultaneously. Not to mention that with an background compilation running frequently (at least more frequently that it would run if it was called manually), people tend to have fewer compilation errors to fix at a time. This should happen a lot on productivity (at least it helps me). > why the error highlighting is a problem? GHC even supports > -ferror-spans option in which emacs-style error message is printed > (i.e. it includes the exact range of lines/chars what contain error) I will take a look at that. I don't actually know where our error-reporting problems come from because EclipseFP is a pretty old code base and I wasn't around when this was coded. But I do know that the current error highlighting isn't the best thing one would want. It certainly helps a lot, but it still isn't as precise as one would like. The background compilation and error highlighting issues are already enough work (and my message is getting quite long already). This doesn't mean the other issues are not valid, but we need to keep a focus here if we want to get anything done. So, I am snipping the rest of the message for the time being (and hoping those issues can be dealt with soon). Cheers, Thiago Arrais --=20 Mergulhando no Caos - http://thiagoarrais.blogspot.com Pensamentos, id=E9ias e devaneios sobre desenvolvimento de software e tecnologia em geral |
From: Bulat Z. <bul...@gm...> - 2006-07-05 10:44:11
|
Hello Thiago, Tuesday, July 4, 2006, 6:34:00 AM, you wrote: > Thank you for the detailed responses. I apologize for not answering > before, I was waiting for a quieter time to be able to answer > properly. i just installed the whole thing (just extracted your archive over the Eclipse directory) and now can tell how it works on windows (i guess that you work with Unix?) >> now i'm using editor with just syntax highlighting and therefore i >> wrote about things those lacking are most important for me. first is >> the compilation. > I agree with you, background compilation is the most important feature > for me too. Therefore, I will try to work on this for the next > release. I am looking for a Cabal-integrated build system and planning > to delegate all the work (like dependency fetching and selective > compilation) to the chosen build system instead of implementing it as > part of EclipseFP. i agree that using Cabal infrastructure is a proper way, especially if you develop system for application programmers that need RAD solution (as opposite to hardcore hackers that can setup everything by hand). i just suggest to leave the non-Cabal building also available, for example via use of customized cmdlines (so hacker can use batch files or makefiles or just "ghc --make" to build/run what he need) > I think I will experiment with this approach. EclipseFP distributes > live builds for every modification to the source code. Can I contact > you when those builds start to be available? Would you mind trying > them? with a great pleasure, both to help myself to get a good IDE and to help you develop great IDE for future Haskell users the only issue is what i have limited internet speed, so i can't download, say, 2 megs each day > Not to mention that with an background compilation running frequently > (at least more frequently that it would run if it was called > manually), people tend to have fewer compilation errors to fix at a > time. This should happen a lot on productivity (at least it helps me). of course, i also want to get it. but i'm not yet understand how you determine moment for each compilation? especially for multi-file changes (for example, global function renaming) >> why the error highlighting is a problem? GHC even supports >> -ferror-spans option in which emacs-style error message is printed >> (i.e. it includes the exact range of lines/chars what contain error) > I will take a look at that. I don't actually know where our i can't yet compile Haskell programs. see below... > focus here if we want to get anything done. So, I am snipping the rest > of the message for the time being (and hoping those issues can be > dealt with soon). feel free to return to these questions when you need. i just tried to consolidate in one letter that i think about those 4 questions and don't expect that you will deal with them all immediately one more important question is support of debugging with GHCi. while it's very large work and i don't expect that you can implement it immediately, i ask you to look at the GHCi debugger development (are you seen a letter by Pepe Iborra in cvs-ghc?) and ensure that debugger he developed will be later usable in your project. IDE with debugger and without one is a very different beasts! and now about my first Eclipse and EclipseFP experience. i installed jre-1_5_0-windows-i586.exe (J2SE runtime environment 5.0) plus Eclipse 3.2. It's possible that my problems with running compiler is just because i use old version of Java machine, so i will go to update it. So, i started Eclipse and: 1. I already know that i should open "Haskell perspective", but this may be non obvious for newcomers 2. When i open just a .hs file, there is no much Haskell support. i need to open project and then most of Haskell plugin power arrives (including even most of syntax highlighting) 3. Executable names "ghc", "hugs" is enough to check their presence, but not enough to run ghci/hugs interpreter. i need to set up their full names (C:/Base/Compiler/ghc-6.4/bin/ghc.exe) to allow them to run in "Console" window (the first 3 topics may go to little FAQ for new EclipseFP users) 4. Console window sometimes start to mesh output. It also don't contains visible cursor 5. i still can't run compiler. when i give "Build something" command, Eclipse just make hour-glass cursor for a moment and... nothing happens. "Compiler output" window is still empty 6. Syntax highlighting is good, it just should mention: Capitalized names as constants aUPPER_CASED names also (although it's my own convention) 123, 0x123 and so on as numeric constants "foreign ccall unsafe safe" as reserved words #... as preprocessor lines {-# ... #-} as pragmas sequences of non-alpha chars and `func` as operators i also will be glad to see ability to define which words (in my opinion!) are reserved and which words are names of "special functions" - such as try/block/... -- Best regards, Bulat mailto:Bul...@gm... |
From: Thiago A. <thi...@gm...> - 2006-07-05 12:25:54
|
Bulat, On 7/5/06, Bulat Ziganshin <bul...@gm...> wrote: > i just installed the whole thing (just extracted your archive over the > Eclipse directory) and now can tell how it works on windows (i guess > that you work with Unix?) Yup. Linux to be exact. Although, I can access some Windows boxes sometimes and always take the chance to test EclipseFP there. I wonder if there is anyone using it on non-Linux non-Windows platforms. > i just suggest to leave the non-Cabal building also available, for > example via use of customized cmdlines Sure. I don't like when tools impose their development model on me, I'd rather keep users as free as they want to be. Customizable builds is one of many choice points we should keep as loose as possible. I hope to get back to that discussion soon, as I start messing with the building thing. > the only issue is what i have limited internet speed, so i can't > download, say, 2 megs each day You actually don't need to. Unfortunately, EclipseFP doesn't get touched that often. We work with some periods of intense activity and some of almost none, mostly depending on our free time. On the intense weeks though, there can be three or four changes to source control per day. If really want to keep up on those times, you can download the changes from the repo and build everything yourself. I haven't adapted the build process to Windows yet, but it wouldn't be /that/ hard if we want to. > of course, i also want to get it. but i'm not yet understand how you > determine moment for each compilation? especially for multi-file > changes (for example, global function renaming) That's not very complex. Compilation is triggered when something gets written to the filesystem. The platform evaluates the deltas and (optimally) the resources that have changed since the last compilation are re-compiled and everything is then linked together. >i ask you to look at the GHCi debugger development (are > you seen a letter by Pepe Iborra in cvs-ghc?) and ensure that debugger > he developed will be later usable in your project. I saw your message to haskell-cafe. Actually the first thing I wanted to work on when I started on EclipseFP was a debugger. I even started a prototype, but never got it published because it wasn't actually a Haskell debugger, but one for a conceptual functional language. GHCi debugger seems very promising. I didn't have the time to take a look at it yet, but will soon. My original idea for a real Haskell debugger was to actually use an interpreter behind the scenes. That's where GHCi becomes handy. Regarding your problems with compilation. I know that under Windows I once needed to configure the full path to GHC in order to get anything compiled. Seems like the PATH environment variable has some subtleties. Anyway, you need to set up a Haskell Project if you want anything to get compiled, a simple .hs file will get coloured, parsed, and outlined but it doesn't do many tricks. You may also want to check the provided Help page under Help > Help Contents > Functional Programming > Haskell > Getting Started. > 1. I already know that i should open "Haskell perspective", but this > may be non obvious for newcomers You can also create a Haskell Project on any other perspective that you will be asked if you want to switch to the Haskell perspective. Theoretically, you don't need to be on the Haskell perspective to program Haskell, but you'll certainly have a better experience if you are. > 2. When i open just a .hs file, there is no much Haskell support. i > need to open project and then most of Haskell plugin power arrives > (including even most of syntax highlighting) Yup. A .hs file outside of a Haskell Project won't do very much. You need to create a project to get anything compiled. > 4. Console window sometimes start to mesh output. It also don't > contains visible cursor > > 5. i still can't run compiler. when i give "Build something" command, > Eclipse just make hour-glass cursor for a moment and... nothing > happens. "Compiler output" window is still empty This is a known bug (http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1458192&group= _id=3D108233&atid=3D649852). Can you check if there is a 'theResult.exe' file under you project's 'bin' folder? This is where the built executable is placed by default. > 6. Syntax highlighting is good, it just should mention: Besides what you mention, there is also need to improve syntax highlighting on literate haskell files. Cheers, Thiago Arrais --=20 Mergulhando no Caos - http://thiagoarrais.blogspot.com Pensamentos, id=E9ias e devaneios sobre desenvolvimento de software e tecnologia em geral |