Re: The Future of Haskell discussion at the Haskell Workshop
On Tue, 9 Sep 2003, Adrian Hey wrote: I rarely use named fields in my Haskell progs with Haskell as it is ... but you sure agree records are useful for collecting heterogenous data? for example, see data DynFlags here: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/main/CmdLineOpts.lhs IMHO preserving the status quo wrt records should be low priority. It really doesn't bother me much if new (useful) language features break existing code. but this might be an issue for others, who have to maintain legacy code. best regards, -- -- Johannes Waldmann http://www.informatik.uni-leipzig.de/~joe/ -- -- [EMAIL PROTECTED] -- phone/fax (+49) 341 9732 204/209 -- .. .. Viertes Leipziger Jongliertreffen, 17. - 19. Oktober 2003 .. .. .. .. http://www.informatik.uni-leipzig.de/~joe/juggling/vier/ .. .. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The Future of Haskell discussion at the Haskell Workshop
Hello, I may be wrong but can't we keep old records and add new ones (as proposed in the First Class Modules paper) with a different syntax? Ussual records and extensible records are both usefull, in different cases. Best regards, Nicolas Oury Le mardi, 9 sep 2003, à 14:52 Europe/Paris, Johannes Waldmann a écrit : On Tue, 9 Sep 2003, Adrian Hey wrote: I rarely use named fields in my Haskell progs with Haskell as it is ... but you sure agree records are useful for collecting heterogenous data? for example, see data DynFlags here: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/main/ CmdLineOpts.lhs IMHO preserving the status quo wrt records should be low priority. It really doesn't bother me much if new (useful) language features break existing code. but this might be an issue for others, who have to maintain legacy code. best regards, -- -- Johannes Waldmann http://www.informatik.uni-leipzig.de/~joe/ -- -- [EMAIL PROTECTED] -- phone/fax (+49) 341 9732 204/209 -- .. .. Viertes Leipziger Jongliertreffen, 17. - 19. Oktober 2003 .. .. .. .. http://www.informatik.uni-leipzig.de/~joe/juggling/vier/ .. .. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
ANNOUNCE: HOpenGL 1.05 released
HOpenGL, a Haskell binding for OpenGL and GLUT version 1.05 I am pleased to announce the sixteenth release of the Haskell binding for GL 1.2.1 / GLU 1.3 / GLUT 3.7beta. It offers easy access to *the* industrial strength 3D graphics API and a GUI toolkit. More details about HOpenGL can be found at http://haskell.org/HOpenGL/ This is a compatibility/bug fix release with the following changes: * Fixed a memory allocation bug for GL state queries. * Works with new hierarchical libraries now. * Always use the correct calling convention. * The build system works with recent versions of GHC and GreenCard now. As always, feedback and/or patches are highly welcome. A note for people on the bleeding edge: If you are interested in the future of HOpenGL and its new API, you might wish to build GHC from CVS, configuring with `--enable-hopengl'. This will result in a GHC with two additional packages `OpenGL' and `GLUT'. The APIs have improved quite a bit and are now modeled around the notion of state variables. Furthermore, OpenGL's extension mechanism is now supported on all major platforms, including Linux, Windows and Mac OS X. Note that this is still work in progress, but early feedback would be very useful. Have fun! Sven ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The Future of Haskell discussion at the Haskell Workshop
On Tuesday 09 September 2003 13:52, Johannes Waldmann wrote: On Tue, 9 Sep 2003, Adrian Hey wrote: I rarely use named fields in my Haskell progs with Haskell as it is ... but you sure agree records are useful for collecting heterogenous data? Yes, I would agree that even the current situation is sometimes better than having a large number of unnamed fields (as a huge-tuple say). But for the average product type or constructor (2..3 fields), it just isn't worth the aggrovation IMO. Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The Future of Haskell discussion at the Haskell Workshop
hello, i think records are very useful, and we don't use them much in haskell, becuase the current record system is not very good. Adrian Hey wrote: IMHO preserving the status quo wrt records should be low priority. It really doesn't bother me much if new (useful) language features break existing code. I think this is a better option than permanently impoverishing the language and/or forcing users to migrate their entire code to some other less impoverished language which may appear in the future. i also think that having backwards compatability is not much of an issue. after all, ghc has introduces a number of not backward compatable changes to haskell, and i never heard any complaints. i am referring to the hirarchical modules, and more recently template haskell, which has introduced a number of syntactic differences, and we had to actually go through our code and fix it to work with ghc 6. What I don't particularly want to see is some half baked record system, the usefulness of which has been compromised by the need to retain backwards compatibility. I quite liked what I saw of the First Class Modules paper. Is there some reason why we can't have (shouldn't have?) that. (Apart from the additional workload it places on Haskell implementors :-) there has been a lot of work on record systems, so there really is no excuse for having a half-baked recrod system. the trex implementation in hugs tried to retain backward compatability with haskell, which resulted in a rather ugly syntax (this of course is just my opinion :-) my preference would be to have something simillar to trex but with a nicer syntax, i.e. extensible records that do not need to be declared. incidently i gathered that people wanted reocrds that support record concatenation, does anyone have any examples of what that might be used for? bye iavor -- == | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | == ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: The Future of Haskell discussion at the Haskell Workshop
Coming from the ML world, I can say that I find the lack of proper records a real loss. It is extremely convenient to write functions which take many parameters as taking a record, for then you don't have to worry so much about the order of arguments. SML gets this much right, but the ad hoc treatment of record selection in SML is a royal pain. Haskell has all of the machinery needed to support this nicely so it seems a shame for it to be omitted. I can say from experience that forcing records to be declared (as in Ocaml) so that there is at most one record type that a given label can come from in any given scope is a royal pain. You're then forced to come up with unique names for the labels so that you don't get a conflict (much as we have to do with datatype constructors.) In Ocaml, you tend to get around this by putting the record types in different modules, but this is only marginally better namespace control. Neither SML nor Ocaml supports polymorphic record selection which is absolutely crucial. I've found few needs for extension or polymorphic update, though there are some compelling examples, and I suspect that more will crop up if these features are widely available. Finally, it seems that good record support at the core level is a nice stepping stone to (first-class) modules. -Greg ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Formal Methods for Components and Objects 2003
(We apologize for the reception of multiple copies) *** CALL FOR PARTICIPATION ** Second International Symposium on Formal Methods for Components and Objects (FMCO 2003) DATES 4 - 7 November 2003 PLACE Lorentz Center, Leiden University, Leiden, The Netherlands URL http://fmco.liacs.nl/fmco03.html EARLY REGISTRATION DEADLINE (15/09/2004) IS APPROACHING OBJECTIVES The objective of this symposium is to bring together researchers and practioners in the areas of software engineering and formal methods to discuss the concepts of reusability and modifiability in component-based and object-oriented software systems. FORMAT The symposium is a four days event in the style of the former REX workshops, organised to provide an atmosphere that fosters collaborative work, discussions and interaction. The program consists of keynote and technical presentations, and contains an exquisite social event. Speakers' contributions will be published after the symposium in Lecture Notes in Computer Science by Springer-Verlag. PRELIMINARY PROGRAM TUESDAY 4th, November 2003 8:45 - 9:00 Welcome 9:00 - 10:00 Keynote: David Parnas (University of Limerick, IE) Mathematical Documentation of Software 10:00 - 10:30 Break 10:30 - 11:15 Razvan Diaconescu (IMAR, RO) Behavioural specification for hierarchical object composition 11:15 - 12:00 Heike Wehrheim (University of Oldenburg, DE) Preserving Properties under Change 12:00 - 13:30 Lunch break 13:30 - 14:30 Keynote: Andrew D. Gordon (Microsoft Research Cambridge, UK) Formal Tools for Securing Web Services 14:30 - 15:00 Break 15:00 - 15:45 Jeannette Wing (Carnegie Mellon University, USA) Vulnerability Analysis Using Attack Graphs 15:45 - 16:00 Break 16:00 - 16:45 Albert Benveniste (IRISA/INRIA - Rennes, FR) Heterogeneous reactive systems formal modeling 16:45 - 17:30 Yassine Lakhnech (University of Grenoble, FR) t.b.a. WEDNSDAY 5th, November 2003 9:00 - 10:00 Keynote: Tony Hoare (Microsoft Research Cambridge, UK) The Verifying Compiler: a Grand Challenge for Computing Research 10:00 - 10:30 Break 10:30 - 11:15 Willem-Paul de Roever (University of Kiel, DE) Data Refinement: model-oriented proof methods and their comparison 11:15 - 12:00 Frank de Boer (CWI, Amsterdam, NL) Hoare Logics for Object-Oriented Programming: State of the Art 12:00 - 13:30 Lunch break 13:30 - 14:15 Jean-Marc Jezequel (IRISA, Rennes, FR) Model-Driven Engineering: Basic Principles and Open Problems 14:15 - 15:00 Jan Friso Groote (Eindhoven University of Technology, NL) t.b.a. 17:00 - 19:15 Social Event 19:30 - Dinner THURSDAY 6th, November 2003 9:00 - 10:00 Keynote: Yuri Gurevich (Microsoft Research Redmond, USA) The Semantics of AsmL 10:00 - 10:30 Break 10:30 - 11:15 Egon Boerger (Pisa University, IT) Exploiting the A in Abstract State Machines for Specification Reuse. A Java/C# Case Study. 11:15 - 12:00 Werner Damm (University of Oldenburg, DE) t.b.a. 12:00 - 13:30 Lunch break 13:30 - 14:30 Keynote: Desmond D'Souza (Kinetium, Austin, USA) t.b.a. 14:30 - 15:00 Break 15:00 - 15:45 Rob van Ommering (Philips Research Laboratories, Eindhoven, NL) Component Based Architectures and Formalization 15:45 - 16:30 Jose Luiz Fiadeiro (University of Leicester, UK) CommUnity on the move: architectures for distribution and mobility 16:30 - 16:45 Break 16:45 - 17:30 Gregor Engels (University of Paderborn, DE) Consistent interaction of components FRIDAY 7th, November 2003 9:00 - 10:00 Keynote: E. Allen Emerson (The University of Texas at Austin, USA) Model Checking Many Components 10:00 - 10:30 Break 10:30 - 11:15 Amir Pnueli (The Weizmann Institute of Science, ISR) t.b.a. 11:15 - 12:00 Natalia Sidorova (Eindhoven University of Technology, NL) Practical approaches for the verification of asynchronous components: model checking, abstraction and static analysis 12:00 - 13:30 Lunch break 13:30 - 14:30 Keynote: Joseph Sifakis (Verimag, FR) t.b.a. 14:30 - 15:00 Break 15:00 - 15:45 Philippe Schnoebelen (CNRS, Cachan, FR) The Verification of Lossy Channel Systems 15:45 - 16:30 Bengt Jonsson (Uppsala University, SE) t.b.a. 16:30 - 17:15 Jan Rutten (CWI, Amsterdam, NL) A case study in coinductive stream calculus: signal flow graphs for dummies MOBI-J WORKSHOP On Monday 3rd, November 2003, there will be a one-day Mobi-J workshop on Assertional Methods for Java and its Extension with Mobile Asynchronous
Re: The Future of Haskell discussion at the Haskell Workshop
Hi. Here's another opinion for the Records! Records! chorus: - The record and module system is one of the two big things I'd like to see changed in Haskell. (OT: the other is subtyping.) - It shouldn't happen before Haskell 2, because of backward compatability. (The dot operator for function composition is widely used, but is the obvious choice for record projection.) - The way to get a feature into Haskell 2 begins with contributing it as an optional extension to GHC and/or nhc98 and/or Hugs. - I'd like something similar to Cayenne's record system, which combines records, modules and let-expressions. But with these refinements: * Dot notation for record opening. Instead of Cayenne's open rec_expr in expr allow (rec_expr).(expr) which has the familiar single-field projection as a special case (rec_expr).field_name * Some sort of catenation or merge facility. Speaking of which... Iavor Diatchki writes: : | incidently i gathered that people wanted reocrds that support record | concatenation, does anyone have any examples of what that might be used for? When a module imports and reexports some other modules, it is effectively doing record catenation. (It may add a few fields of its own, if it exports any declarations, but that can be handled by record extension as opposed to catenation.) The (relational database) join operator also needs it - if you're into doing such things in Haskell. I've implemented a language with a record system along the lines I've just described. It's part of my work, but the record system isn't commercially sensitive. If it pans out well, I'll look into contributing it to a Haskell implementation. (O'Hugs may well be the best fit.) - Tom ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The Future of Haskell discussion at the Haskell Workshop
G'day all. On Tue, Sep 09, 2003 at 02:52:48PM +0200, Johannes Waldmann wrote: but this might be an issue for others, who have to maintain legacy code. You know a language has made it when we're talking about legacy code. On the other hand, you have to worry about a pure declarative language where support for anything legacy is a priority. Just a little bit. Cheers, Andrew Bromage ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Weird Undecidable Instances Bug
On Monday, Sep 8, 2003, at 03:53 US/Pacific, Simon Peyton-Jones wrote: Consider an instance decl like: instance (Lte a b l,If l b a c) = Max a b c (This is a real example.) Notice that l is used on the LHS of the = but not the RHS. The idea is that l will get unified by a functional dependency. But if such a unification re-starts the solving process from scratch, we just get into an infinite loop (apply instance decl, apply fds, unify, start again, apply instance decl again, etc). Could you give me an example of a goal you had in mind, where this method fails? I tried (Lte a b l,If l b a c) |- (Max a b c) but the method works on this. This reminds me of Prolog, somewhat. I wonder if it would be worth prototyping confluent solvers in Prolog? I might try this actually, as a way of getting a handle on the problem. I'd be especially interested in any tricky examples you may have. On the other hand, does the solver have to be confluent? What if it spawned off different threads, and gave up after doing a certain amount of work, which the user could set (like -fcontext-stack)? Provided the solver thread scheduling is deterministic, I imagine that every correct program would be solvable in a finite amount of work. I guess one possibility might be to make such an instance decl illegal. Nooo!!! My workaround was simply to put the instance declaration in a later module. Then g type-checks fine. -- Ashley Yakeley, Seattle WA ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Weird Undecidable Instances Bug
Simon said This is a tricky one. Here's what is going on. I believe there's nothing tricky going on. Your type annotation g :: (F a b,D b (T r)) = (a,T r) g = f is simply incorrect. Keep in mind that GHC does NOT improve type annotations. For example, g :: (F a b, C (T r)) = (a,T r) g = f type checks. (I replaced D b (T r) by C (T r) ) I understand that it might sound reasonable to accept g :: (F a b,D b (T r)) = (a,T r) g = f Indeed, depending on how we define subsumption among type schemes forall a b t. (F a b,D b t) = (a,t) -- inferred subsumes forall a b r. (F a b,D b (T r)) = (a,T r) -- annotated wrt the instance and FD. However, for GHCs evidence translation scheme we need a more restrictive subsumption check (because GHC never improves user-provided type annotations). Consider an instance decl like: instance (Lte a b l,If l b a c) = Max a b c (This is a real example.) Notice that l is used on the LHS of the = but not the RHS. The idea is that l will get unified by a functional dependency. But if such a unification re-starts the solving process from scratch, we just get into an infinite loop (apply instance decl, apply fds, unify, start again, apply instance decl again, etc). Well, there might not be any immediate problem here. The only danger with instance (Lte a b l,If l b a c) = Max a b c is that we need to uniquely determine l given a, b and c. (If we can't then type inference (i.e. subsumption checking) might become incomplete) However, if there's a FD such as class Lte a b l | a b - l then things should work out. We only get into trouble in case we find instance Lte a b l = Lte [a] [b] [l] By trouble I mean, type inference might become undecidable. To conclude, class Max a b c class Lte a b l | a b - l class If l b a c instance (Lte a b l,If l b a c) = Max a b c is safe (i.e. type inference is sound and decidable). Things become unsafe if we add instance Lte a b l = Lte [a] [b] [l] Why and how to fix this problem is subject of current investigations. Will let you know once a readable version is available. Martin ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Weird Undecidable Instances Bug
On Tuesday, Sep 9, 2003, at 00:40 US/Pacific, Martin Sulzmann wrote:
Your type annotation
g :: (F a b,D b (T r)) = (a,T r)
g = f
is simply incorrect.
I must say I don't understand. I need a value of that type. In the
original, g is actually a method in a class, and its definition is in
an instance declaration. Its type is actually given, not annotated. For
instance:
-- ghc -fglasgow-exts -fallow-undecidable-instances -c WeirdInsts.hs
module WeirdInsts where
{
data T r = MkT;
class C t;
class D b t;
instance (C (T r)) = D b (T r); -- (1)
class F a b | a - b;
f :: (F a b,D b t) = (a,t);
f = undefined;
class G t where
{
g :: forall a b. (F a b,D b t) = (a,t);
};
instance G (T r) where
{
g = f;
};
}
This exhibits the same behaviour.
--
Ashley Yakeley, Seattle WA
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-802692 ] SIGSEGV in Text.Regex
Bugs item #802692, was opened at 2003-09-08 19:40
Message generated for change (Comment added) made by simonmar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=802692group_id=8032
Category: hslibs/text
Group: 6.0.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Remi Turk (remit)
Assigned to: Nobody/Anonymous (nobody)
Summary: SIGSEGV in Text.Regex
Initial Comment:
Hi all,
while writing a little download-some-weblog-program I
encountered what appears to be a memory management
bug in Text.Regex of ghc-6.0.1.
Both 6.0 and 6.0.1 crash. I didn't try other versions yet.
possible interesting information can be found at:
http://home.wanadoo.nl/remi.turk/tmp/LJGet/core.bz2
http://home.wanadoo.nl/remi.turk/tmp/LJGet/grepHref.bz2
http://home.wanadoo.nl/remi.turk/tmp/LJGet/grepHref.hs
If I need to provide additional information or isolate
the problem into a smaller code-fragment, please let me
know.
Happy hacking,
Remi
some gdb-info:
{- gdb copyright info... -}
Program terminated with signal 11, Segmentation fault.
{- reading symbols from... -}
#0 chunk_free (ar_ptr=0x0, p=0x4045cbf8) at malloc.c:3049
3049malloc.c: No such file or directory.
(gdb) info stack
#0 chunk_free (ar_ptr=0x0, p=0x4045cbf8) at malloc.c:3049
#1 0x400f883e in __libc_free (mem=0x4045cc00) at
malloc.c:3023
#2 0x40132fd2 in __regfree (preg=0x40205058) at
regex.c:5866
#3 0x805720f in s686_info ()
#4 0x805a4f0 in s4zy_ret ()
#5 0x4c58308 in ?? ()
Cannot access memory at address 0x99548be
--
Comment By: Simon Marlow (simonmar)
Date: 2003-09-09 08:58
Message:
Logged In: YES
user_id=48280
Strange - I thought I fixed this bug between 6.0 and 6.0.1.
You're absolutely certain it happens with 6.0.1?
The URLs in your bug report don't work.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=802692group_id=8032
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-802366 ] SunOS 5.8: lib/HSunix.o: unknown symbol `sendfile'
Bugs item #802366, was opened at 2003-09-08 10:06
Message generated for change (Comment added) made by simonmar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=802366group_id=8032
Category: Compiler
Group: 6.0.1
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: klaus (sternhaus)
Assigned to: Simon Marlow (simonmar)
Summary: SunOS 5.8: lib/HSunix.o: unknown symbol `sendfile'
Initial Comment:
hello.
on SunOS 5.8, with a fresh compiled ghc (configure
-prefix=/home/xxx/local make)
and the some for the precompiled version,
i getting the following error.
any ideas or help?
thx in advance, klaus
-
ghci-6.0.1 -package unix
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.0.1, for
Haskell 98.
/ /_\/ __ / /___| | http://www.haskell.org/ghc/
\/\/ /_/\/|_| Type :? for help.
Loading package base ... linking ... done.
Loading package unix ... linking ...
/home/xxx/local/lib/HSunix.o: unknown symbol `sendfile'
ghc-6.0.1: panic! (the `impossible' happened, GHC version
6.0.1):
can't load package `unix'
-
or in the long form
ghci-6.0.1 -v -package unix
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.0.1, for
Haskell 98.
/ /_\/ __ / /___| | http://www.haskell.org/ghc/
\/\/ /_/\/|_| Type :? for help.
Glasgow Haskell Compiler, Version 6.0.1, for Haskell 98,
compiled by GHC version 6.0
Using package config file:
/home/xxx/local/lib/ghc-6.0.1/package.conf
Packages
Package
{name = data,
auto = False,
import_dirs =
[/home/xxx/local/lib/ghc-6.0.1/hslibs-imports/data],
source_dirs = [],
library_dirs = [/home/xxx/local/lib/ghc-6.0.1],
hs_libraries = [HSdata],
extra_libraries = [],
include_dirs = [],
c_includes = [],
package_deps = [haskell98, lang, util],
extra_ghc_opts = [],
extra_cc_opts = [],
extra_ld_opts = [],
framework_dirs = [],
extra_frameworks = []}
Package
{name = unix,
auto = True,
import_dirs = [/home/xxx/local/lib/ghc-6.0.1/imports],
source_dirs = [],
library_dirs = [/home/xxx/local/lib/ghc-6.0.1],
hs_libraries = [HSunix],
extra_libraries = [HSunix_cbits, dl],
include_dirs = [],
c_includes = [HsUnix.h],
package_deps = [base],
extra_ghc_opts = [],
extra_cc_opts = [],
extra_ld_opts = [],
framework_dirs = [],
extra_frameworks = []}
Package
{name = base,
auto = True,
import_dirs = [/home/xxx/local/lib/ghc-6.0.1/imports],
source_dirs = [],
library_dirs = [/home/xxx/local/lib/ghc-6.0.1],
hs_libraries = [HSbase],
extra_libraries = [HSbase_cbits],
include_dirs = [],
c_includes = [HsBase.h],
package_deps = [rts],
extra_ghc_opts = [],
extra_cc_opts = [],
extra_ld_opts = [],
framework_dirs = [],
extra_frameworks = []}
Package
{name = rts,
auto = False,
import_dirs = [],
source_dirs = [],
library_dirs = [/home/xxx/local/lib/ghc-6.0.1],
hs_libraries = [HSrts],
extra_libraries = [m, gmp, dl],
include_dirs = [/home/xxx/local/lib/ghc-6.0.1/include],
c_includes = [Stg.h],
package_deps = [],
extra_ghc_opts = [],
extra_cc_opts = [],
extra_ld_opts =
[-u,
GHCziBase_Izh_static_info,
-u,
GHCziBase_Czh_static_info,
-u,
GHCziFloat_Fzh_static_info,
-u,
GHCziFloat_Dzh_static_info,
-u,
GHCziPtr_Ptr_static_info,
-u,
GHCziWord_Wzh_static_info,
-u,
GHCziInt_I8zh_static_info,
-u,
GHCziInt_I16zh_static_info,
-u,
GHCziInt_I32zh_static_info,
-u,
GHCziInt_I64zh_static_info,
-u,
GHCziWord_W8zh_static_info,
-u,
GHCziWord_W16zh_static_info,
-u,
GHCziWord_W32zh_static_info,
-u,
GHCziWord_W64zh_static_info,
-u,
GHCziStable_StablePtr_static_info,
-u,
GHCziBase_Izh_con_info,
-u,
GHCziBase_Czh_con_info,
-u,
GHCziFloat_Fzh_con_info,
-u,
GHCziFloat_Dzh_con_info,
-u,
GHCziPtr_Ptr_con_info,
-u,
GHCziPtr_FunPtr_con_info,
-u,
GHCziStable_StablePtr_con_info,
-u,
GHCziBase_False_closure,
-u,
GHCziBase_True_closure,
-u,
GHCziPack_unpackCString_closure,
-u,
GHCziIOBase_stackOverflow_closure,
-u,
GHCziIOBase_heapOverflow_closure,
-u,
GHCziIOBase_NonTermination_closure,
-u,
GHCziIOBase_BlockedOnDeadMVar_closure,
-u,
GHCziIOBase_Deadlock_closure,
-u,
GHCziWeak_runFinalizzerBatch_closure,
-u,
[ ghc-Bugs-802692 ] SIGSEGV in Text.Regex
Bugs item #802692, was opened at 2003-09-08 21:40
Message generated for change (Comment added) made by hampusr
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=802692group_id=8032
Category: hslibs/text
Group: 6.0.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Remi Turk (remit)
Assigned to: Nobody/Anonymous (nobody)
Summary: SIGSEGV in Text.Regex
Initial Comment:
Hi all,
while writing a little download-some-weblog-program I
encountered what appears to be a memory management
bug in Text.Regex of ghc-6.0.1.
Both 6.0 and 6.0.1 crash. I didn't try other versions yet.
possible interesting information can be found at:
http://home.wanadoo.nl/remi.turk/tmp/LJGet/core.bz2
http://home.wanadoo.nl/remi.turk/tmp/LJGet/grepHref.bz2
http://home.wanadoo.nl/remi.turk/tmp/LJGet/grepHref.hs
If I need to provide additional information or isolate
the problem into a smaller code-fragment, please let me
know.
Happy hacking,
Remi
some gdb-info:
{- gdb copyright info... -}
Program terminated with signal 11, Segmentation fault.
{- reading symbols from... -}
#0 chunk_free (ar_ptr=0x0, p=0x4045cbf8) at malloc.c:3049
3049malloc.c: No such file or directory.
(gdb) info stack
#0 chunk_free (ar_ptr=0x0, p=0x4045cbf8) at malloc.c:3049
#1 0x400f883e in __libc_free (mem=0x4045cc00) at
malloc.c:3023
#2 0x40132fd2 in __regfree (preg=0x40205058) at
regex.c:5866
#3 0x805720f in s686_info ()
#4 0x805a4f0 in s4zy_ret ()
#5 0x4c58308 in ?? ()
Cannot access memory at address 0x99548be
--
Comment By: Hampus Ram (hampusr)
Date: 2003-09-09 21:47
Message:
Logged In: YES
user_id=159064
I too get a sigsegv when I run the given code (the links
work just fine for me) and I've tried with both ghc 6.0.1
and CVS version from about a week ago.
--
Comment By: Simon Marlow (simonmar)
Date: 2003-09-09 10:58
Message:
Logged In: YES
user_id=48280
Strange - I thought I fixed this bug between 6.0 and 6.0.1.
You're absolutely certain it happens with 6.0.1?
The URLs in your bug report don't work.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=802692group_id=8032
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-802692 ] SIGSEGV in Text.Regex
Bugs item #802692, was opened at 2003-09-08 21:40
Message generated for change (Comment added) made by remit
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=802692group_id=8032
Category: hslibs/text
Group: 6.0.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Remi Turk (remit)
Assigned to: Nobody/Anonymous (nobody)
Summary: SIGSEGV in Text.Regex
Initial Comment:
Hi all,
while writing a little download-some-weblog-program I
encountered what appears to be a memory management
bug in Text.Regex of ghc-6.0.1.
Both 6.0 and 6.0.1 crash. I didn't try other versions yet.
possible interesting information can be found at:
http://home.wanadoo.nl/remi.turk/tmp/LJGet/core.bz2
http://home.wanadoo.nl/remi.turk/tmp/LJGet/grepHref.bz2
http://home.wanadoo.nl/remi.turk/tmp/LJGet/grepHref.hs
If I need to provide additional information or isolate
the problem into a smaller code-fragment, please let me
know.
Happy hacking,
Remi
some gdb-info:
{- gdb copyright info... -}
Program terminated with signal 11, Segmentation fault.
{- reading symbols from... -}
#0 chunk_free (ar_ptr=0x0, p=0x4045cbf8) at malloc.c:3049
3049malloc.c: No such file or directory.
(gdb) info stack
#0 chunk_free (ar_ptr=0x0, p=0x4045cbf8) at malloc.c:3049
#1 0x400f883e in __libc_free (mem=0x4045cc00) at
malloc.c:3023
#2 0x40132fd2 in __regfree (preg=0x40205058) at
regex.c:5866
#3 0x805720f in s686_info ()
#4 0x805a4f0 in s4zy_ret ()
#5 0x4c58308 in ?? ()
Cannot access memory at address 0x99548be
--
Comment By: Remi Turk (remit)
Date: 2003-09-09 23:36
Message:
Logged In: YES
user_id=26642
*verifying*
yes it does crash with 6.0.1.
I can reach the files without any problem, both from home
and from university. Are they still unreachable?
--
Comment By: Hampus Ram (hampusr)
Date: 2003-09-09 21:47
Message:
Logged In: YES
user_id=159064
I too get a sigsegv when I run the given code (the links
work just fine for me) and I've tried with both ghc 6.0.1
and CVS version from about a week ago.
--
Comment By: Simon Marlow (simonmar)
Date: 2003-09-09 10:58
Message:
Logged In: YES
user_id=48280
Strange - I thought I fixed this bug between 6.0 and 6.0.1.
You're absolutely certain it happens with 6.0.1?
The URLs in your bug report don't work.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=802692group_id=8032
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: GHC build fails without alex
When building the current version of GHC from CVS without having alex installed, the build tries to use alex-inplace instead, but apparently the dependency that tells make(1) to build that executable before using it is missing. I had to execute make ProjectsThatExist=alex in the top level before the build of GHC itself would succeed. I guess, this qualifies as a bug. :-) It's not really a bug (well, the same situation arises with Happy and Haddock). There are no dependencies between top-level projects. I'll switch the default build order so that these packages get build before GHC if you say 'make' at the top level. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC build fails without alex
| typecheck/TcSimplify.lhs:22: | Module `TcUnify' (hi-boot interface) does not export `unifyTauTy' | make[1]: *** [stage2/typecheck/TcSimplify.o] Error 1 | make[1]: Leaving directory `/usr/local/src/ghc-current/ghc/compiler' | make: *** [stage2] Error 2 This is now fixed. BTW, [EMAIL PROTECTED] is a better place for bug reports related to the CVS version of GHC. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC build fails without alex
Peter Simons wrote: [...] | typecheck/TcSimplify.lhs:22: | Failed to load interface for `TcUnify': | Bad interface file: stage2/typecheck/TcUnify.hi-boot-6 | stage2/typecheck/TcUnify.hi-boot-6:6: parse error on input `.' | | typecheck/TcSimplify.lhs:22: | Module `TcUnify' (hi-boot interface) does not export `unifyTauTy' | make[1]: *** [stage2/typecheck/TcSimplify.o] Error 1 | make[1]: Leaving directory `/usr/local/src/ghc-current/ghc/compiler' | make: *** [stage2] Error 2 I performed a 'distclean', a 'cvs update', and tried it again -- same problem. I'm compiling on Linux/x86 using GHC 5.04.3 and GCC 3.2.3. Just update again... :-) Cheers, S. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
simonmar: On Sat, 6 Sep 2003, Donald Bruce Stewart wrote: simonmar: I was a bit too soon reporting the sparc-sun-solaris2, two attempts have died with stg_ap_v_ret. Same result sparc-*-openbsd. Also with mips-sgi-irix65 . An attempt died with stg_ap_v_ret . I'm trying to follow Ian's stepsbut please, report any change you can make on the doc Bootstraping GHC from hc-files. Aha! I *think* I've figured out what's going wrong. The stg_ap_v_ret failure is caused by info tables being generated for the wrong endianness. This isn't supposed to happen, because we should be cross-compiling for the correct endianness, but I'm guessing that the config.h copied over from the target to the host machine has been overwritten during the build process with an incorrect one. Try this: before doing 'cd H/ghc make boot make' on the host machine, do 'touch ghc/includes/config.h'. Check after the build that this file hasn't been overwritten. Looks like that was it! I've just built a working unreg compiler on sparc-unknown-openbsd, which I have not been able to do previously. So get porting :) -- Don ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
On Wed, Sep 10, 2003 at 07:57:33AM +1000, Donald Bruce Stewart wrote: Looks like that was it! I've just built a working unreg compiler on sparc-unknown-openbsd, which I have not been able to do previously. Is that using the instructions in the users guide and without having to copy .hi files over? Thanks Ian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
igloo: On Wed, Sep 10, 2003 at 07:57:33AM +1000, Donald Bruce Stewart wrote: Looks like that was it! I've just built a working unreg compiler on sparc-unknown-openbsd, which I have not been able to do previously. Is that using the instructions in the users guide and without having to copy .hi files over? Following the new guide, and the new distrib/hc-build, with the fix to .hc file generation on the host that Simon sorted out yesterday. This generated a working sparc binary. That compiler in turn is recompiling the libraries and generating new .hi files. So, no, I don't have to copy the .hi files over, though at the cost of waiting for the .hi files to be regenerated. -- Don ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
dons: simonmar: Aha! I *think* I've figured out what's going wrong. The stg_ap_v_ret failure is caused by info tables being generated for the wrong endianness. This isn't supposed to happen, because we should be cross-compiling for the correct endianness, but I'm guessing that the config.h copied over from the target to the host machine has been overwritten during the build process with an incorrect one. Try this: before doing 'cd H/ghc make boot make' on the host machine, do 'touch ghc/includes/config.h'. Check after the build that this file hasn't been overwritten. Looks like that was it! I've just built a working unreg compiler on sparc-unknown-openbsd, which I have not been able to do previously. $ uname -msr OpenBSD 3.3 sparc $ cat test.hs import System.Info main = print System.Info.arch print System.Info.os $ /usr/obj/ports/ghc-6.0.1/ghc-6.0.1/ghc/compiler/ghc-inplace test.hs $ ./a.out sparc openbsd -- Don :D ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Prefix and postfix operators
Dnia ro 27. sierpnia 2003 20:48, Eugene Nonko napisa: Are there any plans to extend Haskell parser to support prefix and postfix operators? It will be just great for domain-specific languages. It always kind of bothered me that unary minus is special. Having only infix operators has the advantage that operators are never adjacent to other operators, so you don't need extra spaces just to separate them nor complicated lexical conventions which tell where multi-character operator sequences should be split. Especially as prefix and postfix operators look better without spaces. In Haskell there are rare troubles because of - and ~ (lazy patterns). ! (strictness annotations) happens not to be used adjacent to operators. I think there are no more unary operators, so it's almost safe; problematic cases with - and ~ are really rare. -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
