Re: [GHC] #3215: Valgrind support
#3215: Valgrind support -+-- Reporter: cmcq | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: Component: Runtime System |Version: 6.10.3 Severity: trivial | Resolution: Keywords: valgrind | Testcase: yes Os: Linux| Architecture: x86 -+-- Comment (by duncan): Is rts/Adjustor.c still used? I thought it was all libffi now. Does libffi have valgrind support? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3215#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #3235: ghci-6.10.3 can't be built with readline support
#3235: ghci-6.10.3 can't be built with readline support -+-- Reporter: guest | Owner: Type: bug | Status: new Priority: normal| Component: GHCi Version: 6.10.3| Severity: minor Keywords:| Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -+-- ghci before version 6.10 used readline for user input. This was nice because readline actually works, other programs use it (so ~/.inputrc lets me customize the behavior of many applications at once), and it is fairly powerful. 6.10.1 moved to editline, which was plain broken (busy hang during startup), had no features, etc. But changing the code back to use readline was easy. Now 6.10.3 is using haskeline, with an entirely new set of bugs (combining characters aren't handled right) and missing features (see `info readline Command Bindable`; none of that is available in haskeline). As a ghci user these changes don't do anything for me except remove existing functionality and introduce bugs. Why can't you let me optionally build ghci with readline instead of haskeline? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3235 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3235: ghci-6.10.3 can't be built with readline support
#3235: ghci-6.10.3 can't be built with readline support --+- Reporter: guest | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: GHCi |Version: 6.10.3 Severity: minor | Resolution: Keywords:| Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --+- Comment (by duncan): I'd tend to agree, however there are at least these issues: * Maintenance and testing burden of keeping several line editing systems working * Distributing binaries and problems with depending on system shared libs. * Licensing complications If the patch is not invasive and GHC HQ are not asked to maintain the readline branch then perhaps the first point is ok. It's annoying when building binaries that sometimes the .so number of readline changes and then we need to build different binaries for different systems. Using haskeline has fewer problems in this area. When one builds ghc (BSD licensed) against readline (GPL) then if you distribute the combined work it must be under the terms of the GPL. That's not something that GHC HQ want to do and some users would prefer to receive binaries under the BSD or distribute their own binaries under the terms of the BSD license. On the other hand it's perfectly OK for distros to build it that way, as long as they clearly label the licensing terms of the result (which has not always been done clearly). So if readline is to be used it has to be optional and not the default. That's fine. So the only remaining issue is the maintenance burden. I cannot speak for the GHC maintainers but if someone volunteers to properly maintain the readline support then perhaps that might be enough. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3235#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #3236: Would be nice if rts_lock (or similar) would fail when the RTS is not started
#3236: Would be nice if rts_lock (or similar) would fail when the RTS is not
started
-+--
Reporter: duncan| Owner:
Type: feature request | Status: new
Priority: normal| Component: Runtime System
Version: 6.11 | Severity: minor
Keywords:| Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-+--
If you export a Haskell function and then call it from C code you have got
to remember to start up the RTS before calling the exported C function,
otherwise it segfaults.
As a slightly nicer way of reminding people to initialise the RTS, perhaps
one of the functions on the code path for calling exported functions (ie
the calls in the _stub.c files) could check if the RTS is started and if
not do something a little nicer than segfault.
The code typically looks like
{{{
cap=rts_lock();
cap=rts_evalIO(cap,
rts_apply(cap,(HaskellObj)runIO_closure,
rts_apply(cap,Foo_zdffoozuads_closure,
rts_mkInt(cap,a1))) ,ret);
rts_checkSchedStatus(foo,cap);
cret=rts_getInt(ret);
}}}
The first bit to segfault is `allocateLocal`, probably inside `rts_mkInt`.
Note that `rts_lock` succeeds and returns a non-null capability.
On similar lines, we might want to think about the use case of building
Haskell libs that export C functions to be used by other projects and ways
to make initialising that library either nicer or automatic. We all
complain when we use C libs that require a global initialiser (implying
some global state) and yet that's exactly what we impose on callers.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3236
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3235: ghci-6.10.3 can't be built with readline support
#3235: ghci-6.10.3 can't be built with readline support --+- Reporter: guest | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: GHCi |Version: 6.10.3 Severity: minor | Resolution: Keywords:| Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --+- Comment (by judah): Note that Haskeline does have bindable commands, as documented at: http://trac.haskell.org/haskeline/wiki/WikiDocumentation Also keep in mind that the readline backend also came with problems. For example, the following didn't work: - tab-completion of Unicode identifiers (#2058) - tab completion of quoted filenames in expressions - cancel the current input line with ctrl-c I don't really object to a forked GHC/readline. But I wonder whether the effort required to maintain a separate branch of GHC would be better used to fix Haskeline's remaining issues. (I plan to tackle many of them myself in time for the ghc-6.12 release.) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3235#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3233: Cleaning on Windows currently fails
#3233: Cleaning on Windows currently fails
-+--
Reporter: igloo |Owner:
Type: bug | Status: closed
Priority: high |Milestone: 6.12.1
Component: Build System | Version: 6.11
Severity: normal| Resolution: fixed
Keywords:| Difficulty: Unknown
Testcase:| Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-+--
Changes (by igloo):
* status: new = closed
* resolution: = fixed
Comment:
Fixed by:
{{{
Sat May 16 00:19:47 BST 2009 Ian Lynagh ig...@earth.li
* Disable suffix rules when cleaning
Sat May 16 12:45:11 BST 2009 Ian Lynagh ig...@earth.li
* Hide more make rules when cleaning
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3233#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2689: make maintainer-clean leaves generated files and directories
#2689: make maintainer-clean leaves generated files and directories -+-- Reporter: claus |Owner: Type: bug | Status: closed Priority: normal|Milestone: 6.12 branch Component: Build System | Version: 6.11 Severity: normal| Resolution: fixed Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by igloo): * status: new = closed * resolution: = fixed Comment: Done; I've left #1693 open to remind us to try to do something to check that cleaning actually cleans everything it should. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2689#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #3237: Target binary-dist fails when building GHC with DPH
#3237: Target binary-dist fails when building GHC with DPH -+-- Reporter: scsibug | Owner: Type: bug | Status: new Priority: normal| Component: Build System Version: 6.11 | Severity: normal Keywords:| Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -+-- running make binary-dist for GHC with data parallel haskell fails due to missing LICENSE files in dph-seq and dph-par packages. BINDIST_EXTRAS in rules/build-package.mk assumes that all packages have a file LICENSE at the root, but dph-seq and dph-par assume their license files are in the parent directory (dph). Tested with latest GHC and dph packages from darcs. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3237 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #3238: CInt FFI exports do not use C int in _stub.h header file
#3238: CInt FFI exports do not use C int in _stub.h header file
-+--
Reporter: duncan| Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler (FFI)
Version: 6.11 | Severity: normal
Keywords:| Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-+--
Ideally if I have a FFI export like this:
{{{
foreign export ccall foo :: CInt - CInt
}}}
Then the `_stub.h` file should look like:
{{{
#ifdef __cplusplus
extern C {
#endif
extern int foo(int a1);
#ifdef __cplusplus
}
#endif
}}}
But it actually looks like:
{{{
#include HsFFI.h
#ifdef __cplusplus
extern C {
#endif
extern HsInt32 foo(HsInt32 a1);
#ifdef __cplusplus
}
#endif
}}}
So what am I complaining about? Well, I specified an FFI export mentioning
only C types but the header file uses `HsInt32`. I'd prefer an actual C
`int`. I also do not want to `#include HsFFI.h` because then when using
gcc to compile C code that uses this C function I have to know the full
path to ghc's include dir so that gcc can find `HsFFI.h`.
The point here is about exporting C functions and trying to integrate into
some bigger build system that will be using gcc not ghc to compile C code
and link the system together.
I realise this isn't trivial to fix, because GHC defines things like CInt
as newtypes for primitive types of known widths (like Int32). However,
perhaps there should be a known mapping, even though within the Haskell
world CInt is just a newtype. The set of FFI types is already hard-wired
into the compiler (with some rules to allow newtype unwrapping etc) so why
not extend that hard-wired knowledge to include the real C type (not just
the ABI width). This only needs to be used when generating the export
header files. An extra bit in the mapping can indicate if it's a C
primitive type or if the export header file has to `#include HsFFI.h`.
This ticket is related to #2926 and the solution is almost certainly the
same, but the motivation for this problem is slightly different.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3238
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3157: ghci segmentation fault when computation is interrupted
#3157: ghci segmentation fault when computation is interrupted ---+ Reporter: fft1976 |Owner: Type: bug | Status: reopened Priority: normal |Milestone: 6.10 branch Component: Runtime System | Version: 6.10.2 Severity: critical| Resolution: Keywords: ghci| Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ---+ Changes (by simonmar): * status: closed = reopened * resolution: duplicate = -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3157#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: --out-implib when linking shared libraries
I've just built a Haskell dll on Windows. As part of the process it generated an 14Mb foo.dll, and a 40Mb foo.dll.a. Looking at the flags passed to ld I see --out-implib=foo.dll.a. What is the purpose of the .a file? What might it be needed for? Is it possible to suppress it? It looks like what you're getting is an import lib that also contains a full copy of all the code. Yes, that seems likely. My guess is it's just a cat of the .o's, with header tables etc. I think it's possible to have minimal .lib files that do not contain any code and only refer to the corresponding dll. Further, I think recent gnu ld versions can link directly against dlls without using an import lib (though you may still need the import lib if you want to use MSVC to link to your dll). I don't, although having that option wouldn't be a bad thing - having a minimal .lib is perfectly reasonable as a default. Having a massive .lib seems crazy. (The fact that .lib is named .dll.a isn't too much of an issue) So my suggestion is remove it, if you're linking using gcc it should work. I'm not linking the .dll at all, only using dynamic linking, which works without the .lib. But I don't really want to start removing files - doing that in a build system seems like a bad idea. Thanks Neil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: --out-implib when linking shared libraries
On Sat, 2009-05-16 at 11:07 +0100, Neil Mitchell wrote: I don't, although having that option wouldn't be a bad thing - having a minimal .lib is perfectly reasonable as a default. Having a massive .lib seems crazy. (The fact that .lib is named .dll.a isn't too much of an issue) It's possible to create a minimal import lib via a .def file (which lists the exports). I think the dlltool helps with that. So my suggestion is remove it, if you're linking using gcc it should work. I'm not linking the .dll at all, only using dynamic linking, which works without the .lib. But I don't really want to start removing files - doing that in a build system seems like a bad idea. Sure, so at least you don't have to install them. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: --out-implib when linking shared libraries
I remember that the .dll.a libraries that GCC produces are not always compatible with MSVC. Sometimes it works if you rename them to .lib but sometimes it doesn't. It is much more realiable to create .lib from .def file via some of the MS tools. If GCC can link dynamic libraries without using the static library then it might be good idea not to build the import libraries at all. Regards, Krasimir On Sat, May 16, 2009 at 1:26 PM, Duncan Coutts duncan.cou...@worc.ox.ac.uk wrote: On Sat, 2009-05-16 at 11:07 +0100, Neil Mitchell wrote: I don't, although having that option wouldn't be a bad thing - having a minimal .lib is perfectly reasonable as a default. Having a massive .lib seems crazy. (The fact that .lib is named .dll.a isn't too much of an issue) It's possible to create a minimal import lib via a .def file (which lists the exports). I think the dlltool helps with that. So my suggestion is remove it, if you're linking using gcc it should work. I'm not linking the .dll at all, only using dynamic linking, which works without the .lib. But I don't really want to start removing files - doing that in a build system seems like a bad idea. Sure, so at least you don't have to install them. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
possible alternative to libFFI
Hello glasgow-haskell-users, http://www.nongnu.org/cinvoke/faq.html -- Best regards, Bulat mailto:bulat.zigans...@gmail.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: possible alternative to libFFI
On Sat, 2009-05-16 at 22:31 +0400, Bulat Ziganshin wrote: Hello glasgow-haskell-users, http://www.nongnu.org/cinvoke/faq.html From the page: How does C/Invoke compare to libFFI? At the C API level they're pretty similar, aside from some minor quibbles. libFFI has been around longer and is much more portable, but the last release was in 1998. Note that there are separate libffi releases again: http://sourceware.org/libffi/ libffi-3.0.8 was released on December 19, 2008. You can ftp it from ftp://sourceware.org/pub/libffi/libffi-3.0.8.tar.gz Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] Programming in Haskell -- solutions to exercises
Dear all, For info, solutions to the exercises from Programming in Haskell are now available online, from: http://www.cs.nott.ac.uk/~gmh/book.html Best wishes, Graham +-+ | Dr Graham Hutton Email : g...@cs.nott.ac.uk | | Functional Programming Lab | | School of Computer Science Web : www.cs.nott.ac.uk/~gmh | | University of Nottingham| | Jubilee Campus, Wollaton RoadPhone : +44 (0)115 951 4220| | Nottingham NG8 1BB, UK | +-+ This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: OpenGL 2.2.3.0
A new version of the OpenGL package has bee uploaded to Hackage. This is a feature release, containing the following changes and additions: * Added support for GL_ARB_copy_buffer, GL_ARB_depth_buffer_float, GL_ARB_half_float_pixel, GL_ARB_texture_rectangle, GL_EXT_packed_float and GL_EXT_texture_shared_exponent extensions. * Added missing parts of GL_ARB_vertex_shader extension. * Announce that we support MESA_ycbcr_texture and APPLE_ycbcr_422 extensions. * Improved generic vertex attribute array API. * Added support for unsigned integral uniforms. * Added more GLSL type tokens. * Added missing query for texture size limits. * Include missing aclocal.m4 and README in source distribution and removed unused Makefiles and prologue.txt. * Added 2 hacks to determine the Haskell equivalents of GLchar/GLintptr/GLsizeiptr with ancient GL headers. * Added Vector1, Vector4 and Vertex1 data types for orthogonality. * Added Functor, Applicative, Foldable , Traversable, Typeable and Typeable1 instances for all vertex attributes plus all possible derivable instances. Cheers, S. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Haskell Weekly News: Issue 118 - May 16, 2009
--- Haskell Weekly News http://sequence.complete.org/hwn/20090516 Issue 118 - May 16, 2009 --- Welcome to issue 118 of HWN, a newsletter covering developments in the [1]Haskell community. Welcome to the Google Summer of Code special edition! I asked each of the five students with accepted GSoC projects to describe what they plan to work on. You'll find their descriptions below, with links to their blogs. And keep watching this space: as I did last summer, I plan to provide readers of the HWN with weekly updates on the progress of the GSoC projects. Google Summer of Code Haddock improvements! Isaac Dupree is [2]working on improvements to [3]Haddock. Besides the various inevitable small fixes/improvements, my specific projects are to make cross-package documentation work, and to refactor the comment-parsing out of GHC and into the Haddock code-base. EclipseFP. Thomas Ten Cate will be [4]working on EclipseFP: Compared to more mainstream languages, Haskell has surprisingly poor IDE support, even though its static typing system allows for much more help from the IDE than in the case of dynamic languages. For the Java language, a very mature and powerful IDE exists in the form of Eclipse. A plugin for Haskell support in Eclipse, called EclipseFP, is in the works, but its development has been standing still for some time. I will bring EclipseFP to a more usable state. For this, I will use the Scion IDE library, which interfaces with the GHC API, so that more advanced features like type inference become possible. I will also add support for Cabal. Hopefully, this type of IDE support will lead to greater acceptance and use of Haskell, and be useful for development as well as education. Improving the Haskell space profiling experience. Gergely Patai's [5]project will be focused on space profiling: At the present moment, heap profiling Haskell programs means analysing logs off-line, using conversion tools to visualise data. However, instead of generating graphs with hp2ps, it should be possible to present the data in a graphical application in real time, which is useful while developing interactive applications, and it should also be made easier to export profiler output in different formats. The aim of the project is to create a set of tools that make heap profiling of Haskell programs easier in various ways. In particular, the following components are planned: a library to process profiler output in an efficient way and make it easily accessible for other tools in the future; a real-time visualiser (most likely using OpenGL); some kind of history manager to keep track of profiling data and make it possible to perform a comparative analysis of performance between different versions of your program; a maintainable and extensible replacement for hp2ps; and converters to provide input for other profiling tools. haskell-src-exts - haskell-src. Niklas Broberg: My [6]project, dubbed 'haskell-src-exts - haskell-src' is really two projects in one wrapping. The first milestone is to bring my haskell-src-exts library to the point where it can supersede the old haskell-src library as the de facto package for haskell source manipulation. The main problem that I need to solve is to implement a scheme that lets the user decide what extensions to recognize when parsing a source document. Currently, haskell-src-exts assumes all extensions are always on, which means that some valid H98 programs will be incorrectly parsed due to stolen syntax by e.g. Template Haskell. The second milestone is to extend the focus from source code to full source documents, and implement a scheme for handling comments as well. The ultimate goal here is to have (pretty . parse) == id, to allow haskell-src-exts to be run on source documents without changing them. This would open up for some really interesting applications, in particular refactoring tools that could automatically apply transformations to a source document while still preserving comments. darcs. Last but not least, Petr Rockai will be [7]working on improvements to [8]darcs: My project revolves around the idea of fast darcs for medium and large repositories. Three are quite a few haskellers who use darcs in their day to day (haskell) work. A fair number of hackage packages is maintained in darcs. Even though many of these repositories are of a relatively modest size, there is a number of relatively large real-world darcs repositories out there. The primary target of the project is to improve scalability of darcs for large working trees. This should help those users with existing large darcs repositories, as well as encourage people
Re: [Haskell-cafe] Data.FiniteMap deprecrated
Data.Map in the containers library. vigalchin: Hello, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/FiniteMap ... since this is deprecated what is the orthodox way to implement finite map?? Thanks, Vasili ___ 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
[Haskell-cafe] help :type class?
Does anyone have an idea how to use an instance to list all the functions of type? Thank you! ___ 好玩贺卡等你发，邮箱贺卡全新上线！ http://card.mail.cn.yahoo.com/___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help :type class?
How about hoogle? 2009/5/16 yu yang er.9...@yahoo.com.cn: Does anyone have an idea how to use an instance to list all the functions of type? Thank you! 好玩贺卡等你发，邮箱贺卡全新上线！ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help :type class?
On Fri, May 15, 2009 at 11:10 PM, yu yang er.9...@yahoo.com.cn wrote: Does anyone have an idea how to use an instance to list all the functions of type? Thank you! Perhaps :i sometype inside of ghci? Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] conflicting variable definitions in pattern
On 16 May 2009, at 03:54, wren ng thornton wrote: Conor McBride wrote: Rumblings about funny termination behaviour, equality for functions, and the complexity of unification (which isn't the proposal anyway) But unification is what you get by adding non-linearity. Hang on a minute: we're solving for sb in sb(p)=v not in sb(s)=sb(t)... Sure, all terms are ground; ...which makes it a rather special and degenerate and unawesome case of unification: the kind of unification you don't need a unification algorithm to solve. would you prefer I said testing for membership in an element of the RATEG class? I'm not familiar with that terminology, but I'll check out the link. For more ickiness about RATEG, it's not closed under compliment and the emptiness problem is undecidable (so dead code elimination can't always work). Even restricting to the closed subset (aka tree- automata with (dis-)equality constraints) leaves emptiness undecidable, though there are a couple still more restricted classes that are decidable. cf ch.4 of TATA http://tata.gforge.inria.fr/ Let's be clear. The suggestion is only that a slightly more compact notation be permitted for functionality already available via guards or view patterns. It cannot introduce any dead code elimination problems which are not already present. I'm sorry, but I just don't see the bogeyman here. All the best Conor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary and little endian encoding
On Friday 15 May 2009 06:52:29 David Leimbach wrote:
I actually need little endian encoding... wondering if anyone else hit this
with Data.Binary. (because I'm working with Bell Lab's 9P protocol which
does encode things on the network in little-endian order).
Anyone got some tricks for this?
Dave
You could just define data type and Binary instance for 9P messages. Something
like this:
P9Message = Tversion { tag :: Word16, msize :: Word32, version :: String }
| ...
instance Binary P9Message where
put (Tverstion t m v) = putWord16le t putWord32le m put v
-- and so on...
get = do
length - getWord32le
id - getWord16le
case is of
p9TMessage - do ...
There are a lot of boilerplate code thought...
BTW could you say what do you want to do with 9P? I tried to play with it
using libixp library but without any success. It was mainly to understand how
does it works and how can it be used.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GUIs, FRP, (Delimited) Continuations and Zippers
Hi all, In my app, there is one part which has a rather complicated GUI logic, it involves n drop downs with n choices each. Whenever the current selection in one of the drop downs changes by user interaction, the other (n-1) drop downs need to be notified and their item list need to possible change too. Now I have managed to code all this and it actually behaves correctly. But I'm also using tons of IORefs and tons of bookkeeping code for it. While I'd not be ashamed to show any other part of my code to another Haskeller, this part of the code is the most clumsiest I've ever written. And I have no clue if that piece of code *can* be written in any other way, ie. without the tons of IORefs and bookkeeping. The GUI library is WXHaskell. In the last few days I read up on Conal Elliotts FRP stuff (reactive) but also on Olegs ZFS (Zippers, Delimited Continuations), the latter leaving me totally baffled. Could either of those approaches (FRP / Delimited Continuations) be a solution for implementing complex GUI code? Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Decoupling OpenAL/ALUT packages from OpenGL
Am Montag, 11. Mai 2009 12:04:07 schrieb Neil Brown: [...] So possible additions to your type-class list are Foldable and maybe Traversable (no harm, although I'd have to reach further for an example for this). I guess the tricky decision might be whether to provide a Num instance (again, probably more suitable for Vector2)? [...] OK, I've added a bunch of instances for all vertex attribute types in the OpenGL 2.2.3.0 package. Let me know if there are standard classes for which you would like to see instances, too. I've deliberately omitted instances for Num, because they are not correct from a mathematical point of view: You can't e.g. add two points (only a point and a vector), the difference between two points is not a point (it's a vector), etc. Cheers, S. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building 'text-icu-0.1' on Windows
On Thu, May 14, 2009 at 10:25 AM, Bryan O'Sullivan b...@serpentine.com wrote: On Thu, May 14, 2009 at 10:18 AM, Bryan O'Sullivan b...@serpentine.com wrote: If one of you has the time to dig into this and send a patch that corrects the problem, I'd welcome the help. As I'm sure you can tell, I developed text-icu on Unix, and I don't have regular enough Windows access to make debugging this a quick and easy matter. By the way, if you run into problems building or using text or text-icu, please file a ticket here: http://trac.haskell.org/text/newticket Hi, I've attached a patch that fixes the build on Windows. It also doesn't seem to break the build on my Linux box. However, the patch basically consists of removing an #include statement and removing some library dependencies (which for some reason don't exist in the Windows distribution of ICU), so I don't know if it would break something else. The library compiles without warnings with the patch applied, though. Maybe Serge could test the patch on his machine? Thanks, Alex fix-windows-build.dpatch Description: Binary data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] typeclasses comprehension problems: situation classes?
Hello, cafe visitors!
I'm trying to learn Haskell typeclasses, - about how to use them, - but
can't handle some conceptiual problems, which confuses me a lot. I took one
real problem (ErrorInfo gragual gathering), to tackle it in my studies: I
have a class of situations: there is an object, and it gets cumulatively
filled (or updated) with content. The code is in the end - it consists of 3
versions:
1. My first try. Fast written, based on intuitive understanding. Failed.
2. The second try - exploring an open world assumption. I hoped this would
set me on the right path. Failure.
3. Surrendered to compiler - statisfied all it's requirements. This code
looks absurd to me: parameter-never-to-be-used, unwanted-defaults. Compiler
accepted this one though.
Problems:
1. How to define *fillerRole* correctly, so that it depends on the
type-value of src_t?
2. How to define *initFillable* correctly, so that it depends only on the
type-value filled_t, which is specified by the context of evaluation?
3. What are my misconcepts in the use of Haskell typeclasses here?
4. Maybe I should distinguish *situation class* (as this one), as something
unavailable in Haskell? This assumption is the last one to make... I'd
rather belive, that there is something I'm not aware of (for a considerably
long time already) in Haskell. A lack of some programming technique
Please, Help!
Regards,
Belka
==TRY=1===DOESN'T=COMPILE==
{-# LANGUAGE MultiParamTypeClasses #-}
class FillsConsideringRoles src_t filled_t role_t where
initFillable :: filled_t
fillerRole :: role_t
fill :: src_t - filled_t - filled_t
data Role = Role1 | Role2 deriving (Show)
data FillableObject = FillableObject
{ foData1 :: Maybe (Int, Role)
, foData2 :: Maybe (Int, Role)
} deriving (Show)
newEmptyFillableObject :: FillableObject
newEmptyFillableObject = FillableObject Nothing Nothing
data Constructor1 = Constructor1 Int
data Constructor2 = Constructor2 Int
instance FillsConsideringRoles Constructor1 FillableObject Role where
initFillable = newEmptyFillableObject
fillerRole = Role1
fill c fo = let (Constructor1 i) = c in fo { foData1 = Just (i,
fillerRole) }
instance FillsConsideringRoles Constructor2 FillableObject Role where
initFillable = newEmptyFillableObject
fillerRole = Role2
fill c fo = let (Constructor2 i) = c in fo { foData2 = Just (i,
fillerRole) }
main = putStrLn $ show $ fill c2 $ fill c1 initFillable
where
c1 = Constructor1 76
c2 = Constructor2 43
==TRY=1==[END]===
==TRY=2===DOESN'T=COMPILE
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE OverlappingInstances #-}
class FillsConsideringRoles src_t filled_t role_t where
initFillable :: filled_t
fillerRole :: role_t
fill :: src_t - filled_t - filled_t
--
data Role = DefaultRole | Role1 | Role2 deriving (Show)
data FillableObject = FillableObject
{ foData1 :: Maybe (Int, Role)
, foData2 :: Maybe (Int, Role)
} deriving (Show)
newEmptyFillableObject :: FillableObject
newEmptyFillableObject = FillableObject Nothing Nothing
data Constructor1 = Constructor1 Int
data Constructor2 = Constructor2 Int
instance FillsConsideringRoles filler_t filled_t Role where
fillerRole = DefaultRole
instance FillsConsideringRoles Constructor2 filled_t Role where
fillerRole = Role2
instance FillsConsideringRoles Constructor1 filled_t Role where
fillerRole = Role1
instance FillsConsideringRoles filler_t FillableObject role_t where
initFillable = newEmptyFillableObject
instance FillsConsideringRoles Constructor1 FillableObject Role where
fill c fo = let (Constructor1 i) = c in fo { foData1 = Just (i,
fillerRole) }
instance FillsConsideringRoles Constructor2 FillableObject Role where
fill c fo = let (Constructor2 i) = c in fo { foData2 = Just (i,
fillerRole) }
main = putStrLn $ show $ fill c2 $ fill c1 initFillable
where
c1 = Constructor1 76
c2 = Constructor2 43
==TRY=2==[END]===
==TRY=3===WORKS=
{-# LANGUAGE MultiParamTypeClasses #-}
class FillsConsideringRoles src_t filled_t role_t where
initFillable :: ((),src_t, role_t) - filled_t
fillerRole :: ((),src_t, filled_t) - role_t
fill :: ((),role_t) - src_t - filled_t - filled_t
data Role = DefaultRole | Role1 | Role2 deriving (Show)
data FillableObject = FillableObject
Re: [Haskell-cafe] typeclasses comprehension problems: situation classes?
Hello Belka, Saturday, May 16, 2009, 9:22:54 PM, you wrote: I'm trying to learn Haskell typeclasses, - about how to use them, - but am i correctly understood that you've started learning type classes with multi-parameter ones? this may be a bit too brave, especially for a woman :D i suggest you to read first http://haskell.org/haskellwiki/OOP_vs_type_classes about MPTC - you may find great intro in ghc manual, but anyway i suggest to start with single-parameter ones -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Foldable for BNFC generated tree
Hi Deniz, Deniz Dogan wrote: So, basically I'd like some sort of folding functionality for these data types, without having to hack the lexer/parser myself (parameterising the data types), because as I said they're being generated by BNFC. What exactly do you mean by folding functionality? Folding as in the Foldable type class applies to containers, which your data type isn't. Perhaps you're looking for generic programming? There are several good GP libraries out there: * EMGM: http://www.cs.uu.nl/wiki/GenericProgramming/EMGM * Uniplate: http://community.haskell.org/~ndm/uniplate/ * SYB: http://www.cs.vu.nl/boilerplate/ See also Neil Mitchell's blog for some examples: http://neilmitchell.blogspot.com/2009/03/concise-generic-queries.html You're right, what I was asking for didn't make much sense... I was really looking for GP. If I interpret your question correctly, you want a fold for a set of mutually recursive datatypes without type parameters. This function is available in the generic programming library multirec: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/multirec Kind reagrds, Johan Jeuring ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Graphs and graph algorithms?
Hey, Besides fgl, are there any graph libraries in Haskell that are still maintained? Are there other papers (or books) besides Erwig's that I could use to understand how graph algorithms have been implemented in functional languages? Has anything even been published on the topic since Erwig's paper? Thanks, Cory ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] typeclasses comprehension problems: situation classes?
Bulat Ziganshin wrote: Hello Belka, Saturday, May 16, 2009, 9:22:54 PM, you wrote: I'm trying to learn Haskell typeclasses, - about how to use them, - but am i correctly understood that you've started learning type classes with multi-parameter ones? this may be a bit too brave, especially for a woman :D Oh, I'd say that holds for men even more :-) It surely did hold for the man writing this. (Oh, and may I suggest that we all are careful with the gender jokes on the list, no matter how well-intended and even if we know the woman in question. It's simply too easy to mis-interpret on a medium with a bandwidth like email.) /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graphs and graph algorithms?
thestonetable: Hey, Besides fgl, are there any graph libraries in Haskell that are still maintained? Are there other papers (or books) besides Erwig's that I could use to understand how graph algorithms have been implemented in functional languages? Has anything even been published on the topic since Erwig's paper? I think fgl is pretty much the main work on purely functional graphs, though Data.Graph ships in the containers package (Launchbury et al). A quick google also turned up: http://www.osl.iu.edu/research/comparing/haskell_readme.html which would be worth uploading to hackage... We don't seem to have a binding to any of the foreign language libs for very large graphs. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graphs and graph algorithms?
We don't seem to have a binding to any of the foreign language libs for very large graphs. Do you know of any stand-out libraries in this regard worth binding? When I looked in to this last year, the best I could find was the boost library. It depends very heavily on template meta-programming, though, so it wouldn't really be bindable with any of the generality that it has in its native C++. I ask because I'm doing a lot of graph stuff in Haskell right now, and I might be willing to put in the effort to do the binding--especially while I still have c2hs syntax fresh in the brain: I just finished a complete re-write of the mathlink library (brings Haskell to Mathematica -- announcement to follow shortly). --Tracy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Request for feedback: HaskellDB + HList
Hi, It's come time to share something that I've been playing around with recently: a branch of HaskellDB which replaces the home-grown Record code with HList records. It's definitely not ready for primetime, but I thought it'd be a good time to post the code and solicit some feedback from the community. HaskellDB the concept is very promising, but IMHO the code still falls short of that promise. Hopefully this is a small step in the right direction -- the advantages of using HList: * Shared implementation of extensible records * Additional features from HList * Better error messages for record misuse * Lacks predicates * Simpler code As an example of how this can be better, a DB insert looks like so: insert db table $ constantRecord $ film .=. Munchie .*. director .=. Just Jim Wynorski .*. emptyRecord The columns need not appear in the same order as in the database. If you forget a column, you'll get error: No instance for (Fail (FieldNotFound (Proxy Director))) rather than an opaque error. Using the new insertOpt function, Maybe columns will default to Nothing rather than needing to be specified. The details: I haven't updated everything, but there's enough to run test/TestCases.hs under Postgresql. TestCases is probably the best place to look for examples of the new syntax for now. HList had name conflicts with HaskellDB's SQL expression language ((.*.), (.++.), etc.) My temporary band-aid is to move the expression functions to Database.HaskellDB.SqlExpr, and require people to import qualified. The Attr type is gone, columns labels are untyped now. I also replaced a few instances of primitive type-level recursion with HMap/HMapOut. This makes the code simpler, and the type signatures more complex -- type families would help a lot here, I think. Feedback welcome! You can find my darcs tree at: http://mysite.verizon.net/vzewxzuh/sitebuildercontent/sitebuilderfiles/haskelldb-hlist-20090516.tar.gz It also requires minor changes to HList, available at: http://mysite.verizon.net/vzewxzuh/sitebuildercontent/sitebuilderfiles/hlist-20090516.tar.gz I'll talk to the HList people about getting those merged. Thanks! Brian Bloniarz _ Hotmail® has a new way to see what's up with your friends. http://windowslive.com/Tutorial/Hotmail/WhatsNew?ocid=TXT_TAGLM_WL_HM_Tutorial_WhatsNew1_052009___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Linkage errors in scenegraph
I'd like to get the scenegraph package (http://hackage.haskell.org/cgi-bin/hackage-scripts/package/scenegraph) to work, but am encountering linkage errors. I installed scenegraph 0.1.0.1 for ghc-6.10.1 on Fedora 10 Linux. # runghc Setup configure --prefix=/opt # runghc Setup build # runghc Setup install Then I created this little program based on the example at http://www.haskell.org/haskellwiki/SceneGraph (in file SGTest.hs): module Main where import Graphics.SceneGraph import Control.Monad.Identity main :: IO () main = runScene $ osgt $ myScene myScene :: OSGT Identity SceneNode myScene = cube 0.5 `colour` Green `scale` v1x 40 `translate` vy 2 + camera `translate` vy (-10) + light `translate` vz 10 Then I compiled it and got a long list of linker errors; here are the first few lines: ghc --make SGTest Linking SGTest ... /opt/lib/scenegraph-0.1.0.1/ghc-6.10.1/libHSscenegraph-0.1.0.1.a(Basic__210.o): In function `sdE1_info': (.text+0x8d): undefined reference to `scenegraphzm0zi1zi0zi1_GraphicsziSceneGraphziMatrix_translateM_closure' /opt/lib/scenegraph-0.1.0.1/ghc-6.10.1/libHSscenegraph-0.1.0.1.a(Basic__210.o): In function `scenegraphzm0zi1zi0zi1_GraphicsziSceneGraphziBasic_translate_srt': (.data+0x0): undefined reference to `scenegraphzm0zi1zi0zi1_GraphicsziSceneGraphziMatrix_translateM_closure' /opt/lib/scenegraph-0.1.0.1/ghc-6.10.1/libHSscenegraph-0.1.0.1.a(Basic__207.o): In function `sdDq_info': (.text+0x7e): undefined reference to `scenegraphzm0zi1zi0zi1_GraphicsziSceneGraphziMatrix_scaleM_info' /opt/lib/scenegraph-0.1.0.1/ghc-6.10.1/libHSscenegraph-0.1.0.1.a(Basic__207.o): In function `scenegraphzm0zi1zi0zi1_GraphicsziSceneGraphziBasic_scale_srt': (.data+0x0): undefined reference to `scenegraphzm0zi1zi0zi1_GraphicsziSceneGraphziMatrix_scaleM_closure' /opt/lib/scenegraph-0.1.0.1/ghc-6.10.1/libHSscenegraph-0.1.0.1.a(Basic__491.o):(.text+0x27): undefined reference to `__stginit_scenegraphzm0zi1zi0zi1_GraphicsziSceneGraphziUtils_' Also with this command, same result but a lot more detail: ghc --make -v -package scenegraph SGTest With -v, the output includes gcc -v -o SGTest -DDONT_WANT_WIN32_DLL_SUPPORT SGTest.o -L/opt/lib/scenegraph-0.1.0.1/ghc-6.10.1 -L/opt/lib/hmatrix-0.5.1.1/ghc-6.10.1 -L/opt/lib/storable-complex-0.2/ghc-6.10.1 ... -lHSscenegraph-0.1.0.1 -lHShmatrix-0.5.1.1 -lgsl -llapack -lHSstorable-complex-0.2 -lHSQuickCheck-1.2.0.0 ... which seems to show that the proper -L and -l options are included. If I'm decoding the first undefined reference symbol -- (.text+0x8d): undefined reference to `scenegraphzm0zi1zi0zi1_GraphicsziSceneGraphziMatrix_translateM_closure' -- correctly, then the missing symbol is in the scenegraph-0.1.0.1 package, in module Graphics.SceneGraph.Matrix, and is associated with the translateM function defined in that module. I looked for this symbol with nm: # pwd /opt/lib/scenegraph-0.1.0.1/ghc-6.10.1 # nm HSscenegraph-0.1.0.1.o | grep translateM U scenegraphzm0zi1zi0zi1_GraphicsziSceneGraphziMatrix_translateM_closure U scenegraphzm0zi1zi0zi1_GraphicsziSceneGraphziMatrix_translateM_info # nm libHSscenegraph-0.1.0.1.a | grep translateM U scenegraphzm0zi1zi0zi1_GraphicsziSceneGraphziMatrix_translateM_closure U scenegraphzm0zi1zi0zi1_GraphicsziSceneGraphziMatrix_translateM_info but I understand the U means that it is referenced by some other function in these files, but is undefined in them. Since the module Graphics.SceneGraph.Matrix does not declare any exports, I thought that might be the reason the symbol was undefined. But looking back at the Haskell 98 language definition, I found that the absence of an export declaration in a module means that all the symbols of the module are exported. Also, I notice that in the cabal file for scenegraph, the list of exposed modules Exposed-Modules: Graphics.SceneGraph, Graphics.SceneGraph.Basic, Graphics.SceneGraph.Vector, Graphics.SceneGraph.Render, Graphics.SceneGraph.SimpleViewport, Graphics.SceneGraph.GraphViz, Graphics.SceneGraph.Library, Graphics.SceneGraph.Dump, Graphics.SceneGraph.Textures does not include Graphics.SceneGraph.Matrix, but that should only mean that I can't call functions of that module directly -- not that the other SceneGraph modules can't call them -- right? So, why is this symbol undefined? And how can I get it to work? Oh by the way: I can actually use this package if I move into its src directory, add a main function to Examples.hs, and compile and run it right there. Just can't use it as an installed library, it seems. -- ___ ___ __ _ / _ \ / _ \| || | Gregory D. Weber, Associate Professor / /_\// / | | | /\ | | Indiana University East / /_\\/ /__| | |/ \| | http://mypage.iu.edu/~gdweber/ \/\_/\___/\__/ Tel. (765) 973-8420; FAX (765) 973-8550
Re: [Haskell-cafe] Data.FiniteMap deprecrated
Yevgeni, I am specifying base as a Cabal dependency ... dumb question ... I have forgotten whether I need to import Data.Map also? Vasili On Sat, May 16, 2009 at 1:05 AM, Eugene Kirpichov ekirpic...@gmail.comwrote: It's Data.Map. It's in the base package. 2009/5/16 Vasili I. Galchin vigalc...@gmail.com: Hello, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/FiniteMap ... since this is deprecated what is the orthodox way to implement finite map?? Thanks, Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.FiniteMap deprecrated
You need to include the containers package in your cabal file. Alex On Sat, May 16, 2009 at 4:44 PM, Vasili I. Galchin vigalc...@gmail.com wrote: Yevgeni, I am specifying base as a Cabal dependency ... dumb question ... I have forgotten whether I need to import Data.Map also? Vasili On Sat, May 16, 2009 at 1:05 AM, Eugene Kirpichov ekirpic...@gmail.com wrote: It's Data.Map. It's in the base package. 2009/5/16 Vasili I. Galchin vigalc...@gmail.com: Hello, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/FiniteMap ... since this is deprecated what is the orthodox way to implement finite map?? Thanks, Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ 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] Data.FiniteMap deprecrated
yeah I do ghc can't find the Map constructor .. also in another module Parsec is being used ... I have parsec as a dependecy in my cabal file and I also have an import Text.Parsec but ghc could not find module Text.Parsec. ??? Thanks, Vasili On Sat, May 16, 2009 at 6:57 PM, Alexander Dunlap alexander.dun...@gmail.com wrote: You need to include the containers package in your cabal file. Alex On Sat, May 16, 2009 at 4:44 PM, Vasili I. Galchin vigalc...@gmail.com wrote: Yevgeni, I am specifying base as a Cabal dependency ... dumb question ... I have forgotten whether I need to import Data.Map also? Vasili On Sat, May 16, 2009 at 1:05 AM, Eugene Kirpichov ekirpic...@gmail.com wrote: It's Data.Map. It's in the base package. 2009/5/16 Vasili I. Galchin vigalc...@gmail.com: Hello, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/FiniteMap ... since this is deprecated what is the orthodox way to implement finite map?? Thanks, Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ 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] Data.FiniteMap deprecrated
You need to import Data.Map in any file you use Map in. Which version of Parsec are you using? Versions before 3.0.0 do not have a module called Text.Parsec, the module is Text.ParserCombinators.Parsec (or something like that). Alex On Sat, May 16, 2009 at 5:03 PM, Vasili I. Galchin vigalc...@gmail.com wrote: yeah I do ghc can't find the Map constructor .. also in another module Parsec is being used ... I have parsec as a dependecy in my cabal file and I also have an import Text.Parsec but ghc could not find module Text.Parsec. ??? Thanks, Vasili On Sat, May 16, 2009 at 6:57 PM, Alexander Dunlap alexander.dun...@gmail.com wrote: You need to include the containers package in your cabal file. Alex On Sat, May 16, 2009 at 4:44 PM, Vasili I. Galchin vigalc...@gmail.com wrote: Yevgeni, I am specifying base as a Cabal dependency ... dumb question ... I have forgotten whether I need to import Data.Map also? Vasili On Sat, May 16, 2009 at 1:05 AM, Eugene Kirpichov ekirpic...@gmail.com wrote: It's Data.Map. It's in the base package. 2009/5/16 Vasili I. Galchin vigalc...@gmail.com: Hello, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/FiniteMap ... since this is deprecated what is the orthodox way to implement finite map?? Thanks, Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ 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
[Haskell-cafe] Haskell Weekly News: Issue 118 - May 16, 2009
--- Haskell Weekly News http://sequence.complete.org/hwn/20090516 Issue 118 - May 16, 2009 --- Welcome to issue 118 of HWN, a newsletter covering developments in the [1]Haskell community. Welcome to the Google Summer of Code special edition! I asked each of the five students with accepted GSoC projects to describe what they plan to work on. You'll find their descriptions below, with links to their blogs. And keep watching this space: as I did last summer, I plan to provide readers of the HWN with weekly updates on the progress of the GSoC projects. Google Summer of Code Haddock improvements! Isaac Dupree is [2]working on improvements to [3]Haddock. Besides the various inevitable small fixes/improvements, my specific projects are to make cross-package documentation work, and to refactor the comment-parsing out of GHC and into the Haddock code-base. EclipseFP. Thomas Ten Cate will be [4]working on EclipseFP: Compared to more mainstream languages, Haskell has surprisingly poor IDE support, even though its static typing system allows for much more help from the IDE than in the case of dynamic languages. For the Java language, a very mature and powerful IDE exists in the form of Eclipse. A plugin for Haskell support in Eclipse, called EclipseFP, is in the works, but its development has been standing still for some time. I will bring EclipseFP to a more usable state. For this, I will use the Scion IDE library, which interfaces with the GHC API, so that more advanced features like type inference become possible. I will also add support for Cabal. Hopefully, this type of IDE support will lead to greater acceptance and use of Haskell, and be useful for development as well as education. Improving the Haskell space profiling experience. Gergely Patai's [5]project will be focused on space profiling: At the present moment, heap profiling Haskell programs means analysing logs off-line, using conversion tools to visualise data. However, instead of generating graphs with hp2ps, it should be possible to present the data in a graphical application in real time, which is useful while developing interactive applications, and it should also be made easier to export profiler output in different formats. The aim of the project is to create a set of tools that make heap profiling of Haskell programs easier in various ways. In particular, the following components are planned: a library to process profiler output in an efficient way and make it easily accessible for other tools in the future; a real-time visualiser (most likely using OpenGL); some kind of history manager to keep track of profiling data and make it possible to perform a comparative analysis of performance between different versions of your program; a maintainable and extensible replacement for hp2ps; and converters to provide input for other profiling tools. haskell-src-exts - haskell-src. Niklas Broberg: My [6]project, dubbed 'haskell-src-exts - haskell-src' is really two projects in one wrapping. The first milestone is to bring my haskell-src-exts library to the point where it can supersede the old haskell-src library as the de facto package for haskell source manipulation. The main problem that I need to solve is to implement a scheme that lets the user decide what extensions to recognize when parsing a source document. Currently, haskell-src-exts assumes all extensions are always on, which means that some valid H98 programs will be incorrectly parsed due to stolen syntax by e.g. Template Haskell. The second milestone is to extend the focus from source code to full source documents, and implement a scheme for handling comments as well. The ultimate goal here is to have (pretty . parse) == id, to allow haskell-src-exts to be run on source documents without changing them. This would open up for some really interesting applications, in particular refactoring tools that could automatically apply transformations to a source document while still preserving comments. darcs. Last but not least, Petr Rockai will be [7]working on improvements to [8]darcs: My project revolves around the idea of fast darcs for medium and large repositories. Three are quite a few haskellers who use darcs in their day to day (haskell) work. A fair number of hackage packages is maintained in darcs. Even though many of these repositories are of a relatively modest size, there is a number of relatively large real-world darcs repositories out there. The primary target of the project is to improve scalability of darcs for large working trees. This should help those users with existing large darcs repositories, as well as encourage people
