RE: gunfoldl
Regardless of the programming, this should not have crashed GHC. I've
fixed it, and added a regression test.
Thanks for bringing it up.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Akos Korosmezey
| Sent: 18 February 2005 20:05
| To: GHC-users list
| Subject: gunfoldl
|
|
| I wrote a little data structure with quantified constructors:
|
| module MyModule where
|import Data.Generics
|import Data.HashTable
|
|data Item = forall a. (Data a) => Leaf Bool a
| | forall a. (Data a) => Branch Bool a Int Int
|
| deriving (Typeable)
|
| I want it to make an instance of Data:
|
|instance Data Item where
|gfoldl k z (Leaf b v) = z (Leaf b) `k` v
|gfoldl k z (Branch b v a1 a2) = z (\x -> Branch b x a1 a2) `k`
v
|--gunfoldl k z c = case constrIndex c of
|--1 -> k z (Leaf undefined
| undefined)
|toConstr (Leaf _ _) = leafConstr
|toConstr (Branch _ _ _ _) = branchConstr
|dataTypeOf _ = itemDataType
|
|itemDataType = mkDataType "Subliminal.Item" [leafConstr,
branchConstr]
|leafConstr = mkConstr itemDataType "Leaf" [] Prefix
|branchConstr = mkConstr itemDataType "Branch" [] Prefix
|
| But, when I try to compile it with ghc-6.4-20050217:
|
| ghc -fglasgow-exts -i. -c kicsi.hs
|
| kicsi.hs:13:4:
|Warning: No explicit method nor default method for `gunfold'
| In the instance declaration for `Data Item'
| ghc-6.4.20050217: panic! (the `impossible' happened, GHC version
| 6.4.20050217):
|cgPanic
|k{v a1vu}
|static binds for:
|local binds for:
|gunfold{v r22q}
|SRT labelghc-6.4.20050217: panic! (the `impossible' happened, GHC
| version 6.4.20050217):
|initC: srt
|
| Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
| or http://sourceforge.net/projects/ghc/.
|
| If I uncomment the gunfoldl lines:
|
| ghc -fglasgow-exts -i. -c kicsi.hs
|
| kicsi.hs:12:8: `gunfoldl' is not a (visible) method of class `Data'
|
| Compilation exited abnormally with code 1 at Fri Feb 18 20:55:32
|
| Could you please help me?
|
| Thanks
| Akos
| --
| ~~~
| ~~
| Akos Korosmezey Tel:+36-1-439-5936
| Ericsson Telecom Ltd. ETH/GSCD/RUNB Fax:+36-1-437-7576
| P.O.B. 107, H-1300 Budapest, HungaryHome: +36-26-342-687
| mailto:[EMAIL PROTECTED] Mobile: +36-30-740-7732
| ~~~
| ~~
|
| ___
| 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
Re: Scrap your boilerplate (but don't scrap them precious comments)
On Mon, Feb 28, 2005 at 05:20:18PM -0800, Ralf Lammel wrote: > That's a very good point. > Me too, I would often wish to see some principled > code details when entering documentation. For instance > what is the point of _explaining_ that "inc" aliases > "add 1", why not just show that equation! I agree that > gmap?? are a bit of this kind. It is so much easier to > explain them, while showing code. It is so much of a > hassle to explain them while not showing code. The > implementations of gmap?? are almost like algebraic > properties ... I mean these are rather principled > implementations. A documentation tool should support > algebraic laws _and_ such principled implementations. > > It would really help to link the function signatures > with the function definitions in the sense of a limited > code browsing functionality. > > I am sure this is not a new discussion topic, > but we really need this IMHO. Yeah, I have wanted some special haddock identifier which means 'include the body of the function here'. Since often, this can be the best documentation. John -- John Meacham - ârepetae.netâjohnâ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Scrap your boilerplate (but don't scrap them precious comments)
That's a very good point.
Me too, I would often wish to see some principled
code details when entering documentation. For instance
what is the point of _explaining_ that "inc" aliases
"add 1", why not just show that equation! I agree that
gmap?? are a bit of this kind. It is so much easier to
explain them, while showing code. It is so much of a
hassle to explain them while not showing code. The
implementations of gmap?? are almost like algebraic
properties ... I mean these are rather principled
implementations. A documentation tool should support
algebraic laws _and_ such principled implementations.
It would really help to link the function signatures
with the function definitions in the sense of a limited
code browsing functionality.
I am sure this is not a new discussion topic,
but we really need this IMHO.
Ralf
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-
> [EMAIL PROTECTED] On Behalf Of Benjamin Franksen
> Sent: Monday, February 28, 2005 4:11 PM
> To: glasgow-haskell-users@haskell.org
> Subject: Scrap your boilerplate (but don't scrap them precious
comments)
>
> Hi,
>
> I have been racking my brain over the infamous 'gfoldl' and 'gunfold'
> combinators. (Yes, I have read the papers). What finally made me
> understand
> how they worked was reading the code: first the implementation of the
gmap
> functions (Data/Generics/Basics.hs), then the long and detailed
comments
> in
> the same file, and finally the instance definitions for the built-in
types
> (in Data/Generics/Instances.hs).
>
> IMHO, a lot of this could and should be part of the
(haddock-generated)
> documentation.
>
> It is such a waste: all these wonderful comments in the source file,
that
> could be added to the docs with a keystroke! Instead, they simply say
>
> "Left-associative fold operation for constructor applications"
>
> which is really a bit terse for gfoldl, of which the source file
comment
> (rightly) states that its type is a "headache".
>
> Furthermore, (example) implementations can sometimes be extremely
helpful
> to
> understand things; this is especially true for a language like
Haskell, in
> which the implementation is often already the shortest (or at least a
very
> short) and most precise way to specify a functions semantics.
>
> In this case, the implementations of gfoldl helped me to understand
what
> the
> function itself does. However, how and why these extremely abstract
> combinators can serve as the basic building blocks of all the more
> concrete
> and better understandable variants is best documented by the
> implementation
> of just these variants gmapXX and friends. (Maybe one or two examples
> implementations would suffice). At least, it should be stated in the
docs
> what the type constructor ('c') is in each case.
>
> I don't know if haddock can add the implementation of a function to
the
> documentation. If not, such a feature should be considered.
>
> SYB is a wonderful piece of work and deserves to be documented as well
as
> it
> is programmed.
>
> Ben
> ___
> 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
Scrap your boilerplate (but don't scrap them precious comments)
Hi,
I have been racking my brain over the infamous 'gfoldl' and 'gunfold'
combinators. (Yes, I have read the papers). What finally made me understand
how they worked was reading the code: first the implementation of the gmap
functions (Data/Generics/Basics.hs), then the long and detailed comments in
the same file, and finally the instance definitions for the built-in types
(in Data/Generics/Instances.hs).
IMHO, a lot of this could and should be part of the (haddock-generated)
documentation.
It is such a waste: all these wonderful comments in the source file, that
could be added to the docs with a keystroke! Instead, they simply say
"Left-associative fold operation for constructor applications"
which is really a bit terse for gfoldl, of which the source file comment
(rightly) states that its type is a "headache".
Furthermore, (example) implementations can sometimes be extremely helpful to
understand things; this is especially true for a language like Haskell, in
which the implementation is often already the shortest (or at least a very
short) and most precise way to specify a functions semantics.
In this case, the implementations of gfoldl helped me to understand what the
function itself does. However, how and why these extremely abstract
combinators can serve as the basic building blocks of all the more concrete
and better understandable variants is best documented by the implementation
of just these variants gmapXX and friends. (Maybe one or two examples
implementations would suffice). At least, it should be stated in the docs
what the type constructor ('c') is in each case.
I don't know if haddock can add the implementation of a function to the
documentation. If not, such a feature should be considered.
SYB is a wonderful piece of work and deserves to be documented as well as it
is programmed.
Ben
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: segfault/massive memory use when using Data.Bits.shiftL
ganesh: > Hi, > > The following either eats memory until killed or segfaults (I can't pin > down a reason for the difference). Tested with GHC 6.2.2 and 6.4.20050212, > with various different libgmp3s under various Redhat and Debian platforms, > and WinXP. > > Prelude> :m +Data.Bits > Prelude Data.Bits> 18446658724119492593 `shiftL` (-3586885994363551744) :: > Integer Have you tried gmp-4? That's seems to be more stable. -- Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: segfault/massive memory use when using Data.Bits.shiftL
On Mon, Feb 28, 2005 at 10:59:32PM +, Ganesh Sittampalam wrote: > On Mon, 28 Feb 2005, Remi Turk wrote: > > > On Mon, Feb 28, 2005 at 02:55:56PM +, Ganesh Sittampalam wrote: > > > > > > Prelude> :m +Data.Bits > > > Prelude Data.Bits> 18446658724119492593 `shiftL` (-3586885994363551744) :: > > > Integer > > > > and calculating, in your case, 2^3586885994363551744 is not > > something your computer is going to like... > > as it's probably a number which doesn't fit in our universe :) > > Hmm, good point. I hadn't thought about the fact that the number of digits > in the answer would be rather large... Actually, the final answer will be 0: It's only the intermediate value that gets ridiculously large. > > Still, a segfault might point at a bug, which I unfortunately > > won't be able to say much about. (Due to lack of knowledge & > > information.) > > My googling suggests that gmp is prone to segfaulting when things get too > large for it, so I'll just chalk it up to that. > > I apologise for thinking this was a bug :-) No need to apologize. Segfaults _are_ IMHO almost always bugs. And in this case too, though the fault isn't GHCs. Groeten, Remi > Cheers, > > Ganesh -- Nobody can be exactly like me. Even I have trouble doing it. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: segfault/massive memory use when using Data.Bits.shiftL
On Mon, 28 Feb 2005, Remi Turk wrote: > On Mon, Feb 28, 2005 at 02:55:56PM +, Ganesh Sittampalam wrote: > > > > Prelude> :m +Data.Bits > > Prelude Data.Bits> 18446658724119492593 `shiftL` (-3586885994363551744) :: > > Integer > > and calculating, in your case, 2^3586885994363551744 is not > something your computer is going to like... > as it's probably a number which doesn't fit in our universe :) Hmm, good point. I hadn't thought about the fact that the number of digits in the answer would be rather large... > Still, a segfault might point at a bug, which I unfortunately > won't be able to say much about. (Due to lack of knowledge & > information.) My googling suggests that gmp is prone to segfaulting when things get too large for it, so I'll just chalk it up to that. I apologise for thinking this was a bug :-) Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: segfault/massive memory use when using Data.Bits.shiftL
On Mon, Feb 28, 2005 at 02:55:56PM +, Ganesh Sittampalam wrote: > Hi, > > The following either eats memory until killed or segfaults (I can't pin > down a reason for the difference). Tested with GHC 6.2.2 and 6.4.20050212, > with various different libgmp3s under various Redhat and Debian platforms, > and WinXP. > > Prelude> :m +Data.Bits > Prelude Data.Bits> 18446658724119492593 `shiftL` (-3586885994363551744) :: > Integer > > Cheers, > > Ganesh shiftL for Integer is defined in fptools/libraries/base/Data/Bits.hs: class Num a => Bits a where shiftL :: a -> Int -> a x `shiftL` i = x `shift` i instance Bits Integer where shift x i | i >= 0= x * 2^i | otherwise = x `div` 2^(-i) IOW, for y < 0: x `shiftL` y = x `shift` y = x `div` 2^(-y) and calculating, in your case, 2^3586885994363551744 is not something your computer is going to like... as it's probably a number which doesn't fit in our universe :) Still, a segfault might point at a bug, which I unfortunately won't be able to say much about. (Due to lack of knowledge & information.) Greetings, Remi -- Nobody can be exactly like me. Even I have trouble doing it. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
segfault/massive memory use when using Data.Bits.shiftL
Hi, The following either eats memory until killed or segfaults (I can't pin down a reason for the difference). Tested with GHC 6.2.2 and 6.4.20050212, with various different libgmp3s under various Redhat and Debian platforms, and WinXP. Prelude> :m +Data.Bits Prelude Data.Bits> 18446658724119492593 `shiftL` (-3586885994363551744) :: Integer Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 release candidates available
"Simon Peyton-Jones" <[EMAIL PROTECTED]> writes: > I think I've fixed this (on the head anyway; simon will merge to branch > shortly). Care to try again? Yup, the toplevel rigid type-variable problem seems to have been fixed, thanks. nhc98 now builds as expected with ghc-6.4. BTW, there seems to be a small documentation-packaging fault in the linux binary distribution. You may be aware of it already. $ make install ... if test -d share/html; \ then cp -r share/html/* /usr/malcolm/local/share/ghc-6.4.20050227/html; \ fi for i in share/*.ps; do \ cp $i /usr/malcolm/local/share/ghc-6.4.20050227 ; \ done cp: cannot stat `share/*.ps': No such file or directory $ Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ghc HEAD and tee
On 25 February 2005 15:48, Christian Maeder wrote: > we used redirect output of ghc via "tee" (within a Makefile). With the > new ghc this randomly fails now. Does anyone have an explanation for > this? > > ghc <> 2>&1 | tee log > > yields: > > Skipping Main ( hets.hs, hets.o ) > Linking ... > tee: write error > > > The linked binary and the log file are ok afterwards (and the mere > size of the log is also no problem). Hmm, I can't reproduce this behaviour, and I can't imagine what the problem is: the error message claims a write error, so that would seem to indicate some kind of problem writing the log file, which can't be affected by GHC. Or perhaps that's just a generic error message from tee. Can you give any more details that might help us to reproduce it? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1153029 ] allow hierarchical module names with --make
Feature Requests item #1153029, was opened at 2005-02-27 20:24 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1153029&group_id=8032 Category: None Group: None >Status: Closed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: allow hierarchical module names with --make Initial Comment: It would be convenient (and consistent) to allow the use of hierarchical module names with --make, so that something like: ghc -isource_directory --make app.Main -o app would find the source_directory/app/Main.hs module to begin its processing. - Jeff Newbern [EMAIL PROTECTED] -- >Comment By: Simon Marlow (simonmar) Date: 2005-02-28 11:01 Message: Logged In: YES user_id=48280 You can use hierarchical module names with --make, but your module names must be a lexically correct; that is, each component must begin with an upper case letter. App.Main would work, app.Main is not a module name. More information on hierarchical modules here: http://www.haskell.org/hierarchical-modules/ and in the GHC User Guide. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1153029&group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: 6.2.2 x86_64 build failing
On 28 February 2005 05:38, Kip Macy wrote: > In a clean tree I configured: > ./configure --prefix=/u/kmacy/usr/x86_64 > --with-ghc=/u/kmacy/src/ghc/src/ghc-6.2.2-x86_64-x86_64/ghc/compiler/ghc -inplace > > where the ghc-inplace is unregisterised, points to stage1, and is > known to compile "Hello World" > > > gcc -E -undef -traditional -P -I../includes-x c > prelude/primops.txt.pp | \ grep -v '^#pragma GCC' > > prelude/primops.txt ../utils/genprimopcode/genprimopcode --data-decl > < prelude/primops.txt > primop-data-decl.hs-incl > /bin/sh: line 1: 14846 Segmentation fault (core dumped) > ../utils/genprimopcode/genprimopcode --data-decl > primop-data-decl.hs-incl > gmake[2]: *** [primop-data-decl.hs-incl] Error 139 > gmake[2]: *** Deleting file `primop-data-decl.hs-incl' > gmake[1]: *** [boot] Error 1 > gmake[1]: Leaving directory > `/u/kmacy/src/ghc/src/ghc-6.2.2-x86_64-x86_64-clean/ghc' > gmake: *** [build] Error 1 It looks like genprimopcode is crashing. This is significant, because genprimopcode is the first Haskell program to be compiled and run by the compiler that you are bootstrapping with, so this indicates that even though your unregisterised stage1 is known to compile "hello world", it still has some problems. Try adding -debug when compiling genprimopcode, and run it with gdb to get a backtrace. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1153029 ] allow hierarchical module names with --make
Feature Requests item #1153029, was opened at 2005-02-27 12:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1153029&group_id=8032 Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: allow hierarchical module names with --make Initial Comment: It would be convenient (and consistent) to allow the use of hierarchical module names with --make, so that something like: ghc -isource_directory --make app.Main -o app would find the source_directory/app/Main.hs module to begin its processing. - Jeff Newbern [EMAIL PROTECTED] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1153029&group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
