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
