Re[4]: [Haskell-cafe] EclipseFP (Haskell IDE) 0.10.0 released
Hello Piotr, Monday, July 3, 2006, 10:27:22 AM, you wrote: - syntax highlighting, including highlighting of bracket's pair - fast access to help about identifier - auto-indenting with user-tuned style Personally I consider these 3 essential, so I'd vote for them to be implemented in first place (in order as above). I think will test that code completion today - out of sheer curiosity ;) i answer in cafe so that Thiago can see you preferences :) for me, compilation errors navigation, syntax highlighting and code navigation is minimal required features set. help is actually replaced by code navigation - function's definition in Haskell typically contains appropriate help text (which is eventually extracted by Haddock and placed into html file). The only advantage of using pure html help is to omit all the unneeded information (implementation details and so on) and see beautiful formatted text with hyperlinks smart indentation is not easy for Haskell, i think. I don't even sure that myself has some strict indenting rules. moreover, with many edits of source files this again loses it's meaning i'm also curious about code completion - never worked with good one (after the MultiEdit's support for C language constructs :) ) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[4]: [Haskell-cafe] EclipseFP (Haskell IDE) 0.10.0 released
On 03/07/06, Bulat Ziganshin [EMAIL PROTECTED] wrote: i answer in cafe so that Thiago can see you preferences :) Ups. That's that 'Replay to all' phenomena again ;) smart indentation is not easy for Haskell, i think. I don't even sure that myself has some strict indenting rules. moreover, with many edits of source files this again loses it's meaning For me it would be sufficient to increase indentation after few certain constructs (mostly those involving layout). Of course the indentation needs to be inceased in such a case according to layout rule instead of some fixed amount of whitespace. i'm also curious about code completion - never worked with good one (after the MultiEdit's support for C language constructs :) ) I was growing up without code completion. Therefore it's somehow strange to let a computer insert some text instead of me. Like he knew better ;) But completion of function names from few libraries would be usefull after all.. Regards, Piotr Kalinowski -- Intelligence is like a river: the deeper it is, the less noise it makes ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] EclipseFP (Haskell IDE) 0.10.0 released
Bulat, Thanks for the suggestions (by the way, very good article on IO). Some comments below. On 7/3/06, Bulat Ziganshin [EMAIL PROTECTED] 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. - 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. - 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. - automatic management of import lists Being worked on, together with code completion. I would like some more detail here, though. - auto-indenting with user-tuned style This one seems very challenging and interesting, not a must-have for me but a very attractive feature. 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? 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 You can subscribe to our mailing list on http://lists.sourceforge.net/mailman/listinfo/eclipsefp-develop Are you use GHC library? Not yet, but it may turn to be a very wise decision to make in the future. 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. Cheers, Thiago Arrais ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re[2]: Debugging with GHCi.
Hello Pepe, Monday, July 3, 2006, 2:15:59 PM, you wrote: As you may know, this project was accepted for Google SoC and work started a few weeks ago. There are now some observable results that can be tested, and I have set up a wiki page at: http://haskell.org/haskellwiki/Ghci/Debugger As we are now approaching the less clear parts of the project your impressions and ideas (either extense designs or small pointers) are very welcome. The designs for dynamic breakpoints and call traces are open issues yet. i'm very pleased with this year's selection of SoC projects and debugging is among the things i'm highly demanded. I personally interested in debugging imperative C-like code, with abilities to set breakpoints, watch (and change?) variable values, see call stack (i think that closures stack should serve this need), see local variables at each call stack level, evaluate expression and perform IO actions it's especially important for me to be able to use debugger inside some IDE that will allow to set breakpoints and ask variables' values directly inside the source code I'd written. i can recall the following haskell IDEs: HIDE, EclipseFP, Haskell mode for Emacs, Visual Haskell, WinGhci. I think their authors will say better what kind of interface with debugger they prefer imho, just console I/O interface should be enough for most IDEs, as long as debugger's output can be non-ambiguously parsed. Gdb often used to debug C++ programs inside IDEs in this way, i think that cloning it's interface should make it easier to integrate GhcDebugger support into IDEs i also vote for simplest implementation of dynamic breakpoints - the tight integration with IDEs, i.e. _features_, is more important than efficiency (if i correctly understood that this may change only an efficiency) I also will appreciate ability to view call traces - it's the thing that i really need sometimes, especially when debugging unexpected exceptions like head: empty list. It will be especially great to see all variables' values at each execution moment. I don't have a great ideas about representation of this trace. One obvious idea would be to save some binary file and write special viewer for it, another possible idea is to produce (gigantic) html with trace represented as tree with usual '+' marks to expand each node. ps: you will not get much answers - first, because it's a summer and most Haskellers prefer at this time to set up breakpoints on bodies of their girlfriends ;) second - because this maillist don't have many readers. i suggest you to dup your question into main Haskell list and i cc'ed my answer to haskell-cafe in advance. but nevertheless your project is really important to make Haskell more usable for everyday work and Haskellers returned from their vacations will be glad to see that their debugging tasks becomes much easier. please also write exhaustive documentation at the end of your work so that ghci debugger will not become black hole feature -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] EclipseFP (Haskell IDE) 0.10.0 released
Thiago Arrais wrote: Bulat, Thanks for the suggestions (by the way, very good article on IO). Some comments below. On 7/3/06, Bulat Ziganshin [EMAIL PROTECTED] wrote: - auto-indenting with user-tuned style This one seems very challenging and interesting, not a must-have for me but a very attractive feature. The haskell-mode in Emacs cycles through several logical indent levels as you keep pressing the Tab key. This tends to work for me, but not every time. -- Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Input/Output file
Hi all, I have a module Test.hs: module Test where import IO readMsgFile = do putStr Input file: ifile - getLine putStr Output file: ofile - getLine s - readFile ifile writeFile ofile (test s) --test function test :: String - String test s |s == true = True |s == false = False |otherwise = [] Then, I run *Test readMsgFile Input file: test1.txt Output file: result1.txt The content of test1.txt is string true. So I expect the result in result1.txt is True But, open file result1.txt, it displays empty. I do not know why it does not return correct answer. If you don't mind, please share with me. Thanks a lot. S. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Input/Output file
Sara, --test function test :: String - String test s |s == true = True |s == false = False |otherwise = [] Then, I run *Test readMsgFile Input file: test1.txt Output file: result1.txt The content of test1.txt is string true. So I expect the result in result1.txt is True But, open file result1.txt, it displays empty. Could it be that the input file has a trailing return or something similar? You could easily test this by making a small change to your test function: test s | ... | ... | otherwise = error $ The file contains: ++ s HTH, Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Input/Output file
Hi Sara, Just a guess, but your input file is probably true\n - with a trailing newline. In fact, many text editors won't let you create a file without that training newline. Thanks Neil On 7/3/06, Sara Kenedy [EMAIL PROTECTED] wrote: Hi all, I have a module Test.hs: module Test where import IO readMsgFile = do putStr Input file: ifile - getLine putStr Output file: ofile - getLine s - readFile ifile writeFile ofile (test s) --test function test :: String - String test s |s == true = True |s == false = False |otherwise = [] Then, I run *Test readMsgFile Input file: test1.txt Output file: result1.txt The content of test1.txt is string true. So I expect the result in result1.txt is True But, open file result1.txt, it displays empty. I do not know why it does not return correct answer. If you don't mind, please share with me. Thanks a lot. S. ___ 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
Re[4]: [Haskell-cafe] EclipseFP (Haskell IDE) 0.10.0 released
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
Re: [Haskell-cafe] EclipseFP (Haskell IDE) 0.10.0 released
Are you use GHC library? Not yet, but it may turn to be a very wise decision to make in the future. 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. 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, but not on Linux (because GHC did not yet support position-independent code at that time and I didn't manage to connect to a native library otherwise). Is this possible meanwhile? Ciao, Leif Cheers, Thiago Arrais ___ 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
Re: [Haskell-cafe] Input/Output file
On 03/07/06, Stefan Holdermans [EMAIL PROTECTED] wrote: test s | ... | ... | otherwise = error $ The file contains: ++ s Or perhaps, ... | otherwise = error $ The file contains: ++ show s Then all the newlines and other control characters will be printed in their escaped form, making it more obvious. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] EclipseFP (Haskell IDE) 0.10.0 released
Leif, On 7/3/06, Leif Frenzel [EMAIL PROTECTED] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: Packages and modules
Concerning packages, Alex asks: | We covered this extensively in the Cabal vs Haskell thread starting | here: http://www.haskell.org//pipermail/libraries/2005-April/003607.html | | You concluded it by saying on April 22: | |And this observation points towards a simpler solution: rather than |invisibly pre-pend the package name, just get the programmer to do so. |So package P exposes a module called P.M and package Q exposes Q.M. All |P's internal modules are called P.something, and similarly for Q. (We |rely on some social mechanism for allocating new package names, as now.) |Now of course you can import P.M and Q.M in a single module. | |That would be simple. It might be pretty inconvenient to say 'import |Base.Data.List' rather than just 'import Data.List'. But nothing forces |you to do this -- and indeed we don't do it for the current 'base' |package. The point is that it's an easy way for a package author to |ensure their package won't conflict with others. If they choose not to |avail themselves of it, it's more likely that their package will be |unusable because of accidental name conflicts. | |Bottom line: the current story is pretty defensible. I'm not sure that |keeping names unique by implicitly using package-ids is worth the |bother. | |http://www.haskell.org//pipermail/libraries/2005-April/003672.html | | It seems like you are changing your position with this proposal? Any | reason for doing so? A fair question. The basic reason is that packages are now a given. Cabal has packages, with globally unique names and versioning, and we should build on, not duplicate, this infrastructure. Once someone establishes a unique package name, that should be enough: no need to *additionally* establish unique module names, let alone for every single module in the package. Concerning other mail on this subject, which has been v useful, I've revised the Wiki page (substantially) to take it into account. http://hackage.haskell.org/trac/ghc/wiki/GhcPackages Further input (either by email or by adding material to the Wiki) would be welcome. (No guarantee Simon M agrees with what I've written... I'm at home this afternoon :-) Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] forall and a parse error
Hi, I was experimenting with forall and higher rank types briefly, in particular: x :: [forall a . a] This is illegal because of: http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.html#universal-quantification Which is fine, however its surprising to compare the error messages: [forall a . a] parse error on input `forall' [(forall a . a)] Illegal polymorphic or qualified type: forall a. a In the type signature: lst :: [(forall a. a)] In normal Haskell, I tend to view [x] as equivalent to [(x)] (provided that x is not a tuple) but in this case it has a different meaning - albeit both are erronous meanings. When running the example with Hugs, they both come out as syntax errors - the first on the forall, the second on the closing square bracket. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forall and a parse error
On 03/07/06, Neil Mitchell [EMAIL PROTECTED] wrote: In normal Haskell, I tend to view [x] as equivalent to [(x)] (provided that x is not a tuple) but in this case it has a different meaning - albeit both are erronous meanings. How would tuples make a difference? -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forall and a parse error
On 7/3/06, David House [EMAIL PROTECTED] wrote: On 03/07/06, Neil Mitchell [EMAIL PROTECTED] wrote: In normal Haskell, I tend to view [x] as equivalent to [(x)] (provided that x is not a tuple) but in this case it has a different meaning - albeit both are erronous meanings. How would tuples make a difference? [1,2] /= [(1,2)] - the brackets have changed the semantics, because of the tupling. Haskell has two distinct types of brackets, (x) for grouping, (x,y) for tupling. For that reason, there is no way to write the 1 item tuple - despite the fact that some compilers (Yhc/nhc) define and use it internally. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: JRegex on large input sizes
On Sat, Jul 01, 2006 at 02:27:17PM +0100, David House wrote: Hi all. I need a decent regex library and JRegex seems the perfect choice: simple API, yet well-featured, as well as PCRE support. I want to use it on a simple project which involves input files a little larger than typical -- between 100KB and 500KB -- but still small enough so as to not present a problem. However, and I'm fairly sure JRegex is at fault here, my program segfaults on an input of ~230KB. Has anyone used JRegex successfully in this way before? If so, what tactics did you use? This is due to the fact it tries to build the whole string in memory before running the regex on it. Originally, this limitation was due to the fact the API provided by the regex binding in fptools was insufficient to allow chunking of data properly. now that JRegex uses its own FFI binding, there is no reason this limitation should still exist. I will happily accept any patches fixing this. There was some talk of integrating JRegex into the main tree. It should be noted that there are 2 somewhat independent things included in JRegex, a better FFI binding to posix expressions as well as the PCRE library. and the general framework for providing the =~ and =~~ operators. All that is needed is a smarter FFI binding, or even just using another one that exists like Text.Regex.Lazy. it is straightforward to add the instances needed to use the JRegex fancy syntax. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Where is Data.Atom?
Another suggestion: Put your strings in an ordered binary tree (other data structures might also work here). Make your Atom an encoding of the structure of the tree (resp. other structure). This is logically a sequence of bits, 0 for left (less than), 1 for right (greater than) - if you terminate this variable-length sequence with 1, I think it all works out OK. You then encode this sequence of bits in a Word32 (or some other convenient item), with implicit trailing zeros. root ~ 1[000...] root.left ~ 01[000...] root.right ~ 11[000...] ... There are clearly some questions such as how unbalanced is the tree likely to get (since you can't conveniently rebalance it), and what to do if your Atom overflows, but this might give you something to work with. -- Iain Alexander [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New Benchmark Under Review: Magic Squares
Perhaps you could post a new entry page on our shootout wiki? http://www.haskell.org/hawiki/ShootoutEntry This makes it easier for people to keep contributing. Cheers, Don daniel.is.fischer: Am Sonntag, 2. Juli 2006 01:58 schrieb Brent Fulgham: We recently began considering another benchmark for the shootout, namely a Magic Square via best-first search. This is fairly inefficient, and we may need to shift to another approach due to the extremely large times required to find a solution for larger squares. A slightly less naive approach to determining the possible moves dramatically reduces the effort, while Josh Goldfoot's code did not finish within 4 1/2 hours on my machine, a simple modification (see below) reduced runtime for N = 5 to 4.3 s, for N = 6 to 86.5 s. Unfortunately, the squares are now delivered in a different order, so my programme would probably be rejected :-( I thought the Haskell community might be interested in the performance we have measured so far (see http:// shootout.alioth.debian.org/sandbox/fulldata.php? test=magicsquaresp1=java-0p2=javaclient-0p3=ghc-0p4=psyco-0 Interestingly, Java actually beats the tar out of GHC and Python for N=5x5 (and I assume higher, though this already takes on the order of 2 hours to solve on the benchmark machine). Memory use in GHC stays nice and low, but the time to find the result rapidly grows. I was hoping for an order of magnitude increase with each increase in N, but discovered that it is more like an exponential... Thanks, -Brent Modified code, still best-first search: import Data.Array.Unboxed import Data.List import System.Environment (getArgs) main :: IO () main = getArgs = return . read . head = msquare msquare :: Int - IO () msquare n = let mn = (n*(n*n+1)) `quot` 2 grd = listArray ((1,1),(n,n)) (repeat 0) unus = [1 .. n*n] ff = findFewestMoves n mn grd unus ini = Square grd unus ff (2*n*n) allSquares = bestFirst (successorNodes n mn) [ini] in putStrLn $ showGrid n . grid $ head allSquares data Square = Square { grid :: UArray (Int,Int) Int , unused :: [Int] , ffm :: ([Int], Int, Int, Int) , priority :: !Int } deriving Eq instance Ord Square where compare (Square g1 _ _ p1) (Square g2 _ _ p2) = case compare p1 p2 of EQ - compare g1 g2 ot - ot showMat :: [[Int]] - ShowS showMat lns = foldr1 ((.) . (. showChar '\n')) $ showLns where showLns = map (foldr1 ((.) . (. showChar ' ')) . map shows) lns showGrid :: Int - UArray (Int,Int) Int - String showGrid n g = showMat [[g ! (r,c) | c - [1 .. n]] | r - [1 .. n]] bestFirst :: (Square - [Square]) - [Square] - [Square] bestFirst _ [] = [] bestFirst successors (front:queue) | priority front == 0 = front : bestFirst successors queue | otherwise = bestFirst successors $ foldr insert queue (successors front) successorNodes n mn sq = map (place sq n mn (r,c)) possibilities where (possibilities,_,r,c) = ffm sq place :: Square - Int - Int - (Int,Int) - Int - Square place (Square grd unus _ _) n mn (r,c) k = Square grd' uns moveChoices p where grd' = grd//[((r,c),k)] moveChoices@(_,len,_,_) = findFewestMoves n mn grd' uns uns = delete k unus p = length uns + len findFewestMoves n mn grid unus | null unus = ([],0,0,0) | otherwise = (movelist, length movelist, mr, mc) where openSquares = [(r,c) | r - [1 .. n], c - [1 .. n], grid ! (r,c) == 0] pm = possibleMoves n mn grid unus openMap = map (\(x,y) - (pm x y,x,y)) openSquares mycompare (a,_,_) (b,_,_) = compare (length a) (length b) (movelist,mr,mc) = minimumBy mycompare openMap possibleMoves n mn grid unus r c | grid ! (r,c) /= 0 = [] | otherwise = intersect [mi .. ma] unus -- this is the difference that -- does it: better bounds where cellGroups | r == c r + c == n + 1 = [d1, d2, theRow, theCol] | r == c = [d1, theRow, theCol] | r + c == n + 1 = [d2, theRow, theCol] | otherwise = [theRow, theCol] d1 = diag1 grid n d2 = diag2 grid n theRow = gridRow grid n r theCol = gridCol grid n c lows = scanl (+) 0 unus higs = scanl (+) 0 $ reverse unus rge cg = let k = count0s cg - 1 lft = mn - sum cg in (lft - (higs!!k),lft - (lows!!k)) (mi,ma) = foldr1 mima $ map rge cellGroups mima (a,b) (c,d) = (max a c, min b d) gridRow grid n r = [grid ! (r,i) | i - [1 .. n]] gridCol grid n c = [grid ! (i,c) | i - [1 .. n]] diag1 grid n = [grid ! (i,i) |
[Haskell-cafe] Re: EclipseFP (Haskell IDE) 0.10.0 released
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 [EMAIL PROTECTED] 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 -- Mergulhando no Caos - http://thiagoarrais.blogspot.com Pensamentos, idéias e devaneios sobre desenvolvimento de software e tecnologia em geral ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] EclipseFP (Haskell IDE) 0.10.0 released
I have managed to call Haskell from Java on Linux -- I had to manually invoke gcc for the linking step because ghc won't output a shared object. It was very ugly indeed, but I can show you what I did if it will help. jvm-bridge also seems more developed now than when I was doing this, so maybe that's easier. keegan Thiago Arrais wrote: Leif, On 7/3/06, Leif Frenzel [EMAIL PROTECTED] 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 ___ 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