Re: Win 32 GUI for GHC
What I really meant was UI controls, like buttons, options box, check box, etc... > I believe so. If you find go to the Haskell web site and then go to the > HOPenGL Link, you should find information on Win32 systems. At least, > that's where I'd look first, but I'm otherwise not sure. ;) > > -stephen > > Anibal Maffioletti Rodrigues de DEUS wrote: > > > > Is there currently any way of using Win32 GUI with GHC ? >
Re: Win 32 GUI for GHC
I believe so. If you find go to the Haskell web site and then go to the HOPenGL Link, you should find information on Win32 systems. At least, that's where I'd look first, but I'm otherwise not sure. ;) -stephen Anibal Maffioletti Rodrigues de DEUS wrote: > > Is there currently any way of using Win32 GUI with GHC ?
Win 32 GUI for GHC
Is there currently any way of using Win32 GUI with GHC ?
Re: GHC Renamer
Mon, 17 Jul 2000 15:38:45 -0500, Kate S. Golder <[EMAIL PROTECTED]> pisze:
> Are these declarations simply added to all files?
They are values referenced in RULES pragmas in Prelude modules.
> In particular what are "PrelBase.zi" and "PrelBase.zaza"?
Look at ghc/compiler/basicTypes/OccName.lhs in GHC's sources.
It describes and implements the encoding of Haskell names as valid
alphanumeric identifiers. In particular zi is (.) and zaza is (&&).
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/GCS/M d- s+:-- a23 C+++$ UL++>$ P+++ L++>$ E-
^^W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-
GHC Renamer
I have been playing around with parts of the GHC front end, particularly
the Renamer, and am trying to understand the output dumped by this stage.
As part of this process I created a file (Blank.hs), where the file
contains only an empty module declaration:
module Blank where
when I run "ghc -ddump-rn Blank.hs" I get the output which appears at the
end of this message.
Are these declarations simply added to all files? If so, why, and what
are they used for?
In particular what are "PrelBase.zi" and "PrelBase.zaza"?
Also, why are only the types of the functions given, and not their
definitions?
Thanks,
Kate Golder
Renamer:
module Blank where
PrelBase.zi{-r7V,i-} ::
forall b{-rNx-} :: PrelGHC.*{-312,l-} c{-rNy-} :: PrelGHC.*{-312,l-}
a{-rNz-} :: PrelGHC.*{-312,l-}.
(b{-rNx-} -> c{-rNy-})
-> (a{-rNz-} -> b{-rNx-}) -> a{-rNz-} -> c{-rNy-}
PrelBase.zaza{-r7b,i-} ::
PrelBase.Bool{-34,i-}
-> PrelBase.Bool{-34,i-} -> PrelBase.Bool{-34,i-}
An imported rule...
An imported rule...
PrelList.filterList{-rue,j-} ::
forall a{-rN3-} :: PrelGHC.*{-312,l-}.
(a{-rN3-} -> PrelBase.Bool{-34,i-}) -> [a{-rN3-}] -> [a{-rN3-}]
PrelList.filterFB{-riV,j-} ::
forall t{-rN0-} :: PrelGHC.*{-312,l-} t1{-rN1-} :: PrelGHC.*{-312,l-}.
(t{-rN0-} -> t1{-rN1-} -> t1{-rN1-})
-> (t{-rN0-} -> PrelBase.Bool{-34,i-})
-> t{-rN0-} -> t1{-rN1-} -> t1{-rN1-}
PrelBase.mapList{-r62,j-} ::
forall a{-rMX-} :: PrelGHC.*{-312,l-} b{-rMY-} :: PrelGHC.*{-312,l-}.
(a{-rMX-} -> b{-rMY-}) -> [a{-rMX-}] -> [b{-rMY-}]
PrelBase.mapFB{-r61,j-} ::
forall t{-rMS-} :: PrelGHC.*{-312,l-} t1{-rMT-} :: PrelGHC.*{-312,l-}
t2{-rMU-} :: PrelGHC.*{-312,l-} t3{-rMV-} :: PrelGHC.*{-312,l-}.
(t3{-rMV-} -> t1{-rMT-} -> t2{-rMU-})
-> (t{-rMS-} -> t3{-rMV-}) -> t{-rMS-} -> t1{-rMT-} -> t2{-rMU-}
PrelBase.append{-r5p,j-} ::
forall a{-rMQ-} :: PrelGHC.*{-312,l-}.
[a{-rMQ-}] -> [a{-rMQ-}] -> [a{-rMQ-}]
PrelBase.augment{-03,s-} ::
forall a{-rMO-} :: PrelGHC.*{-312,l-}.
(forall b{-rMN-} :: PrelGHC.*{-312,l-}.
(a{-rMO-} -> b{-rMN-} -> b{-rMN-}) -> b{-rMN-} -> b{-rMN-})
-> [a{-rMO-}] -> [a{-rMO-}]
An imported rule...
An imported rule...
An imported rule...
An imported rule...
An imported rule...
An imported rule...
An imported rule...
An imported rule...
PrelPack.unpackCStringzh{-0u,s-} ::
PrelGHC.Addrzh{-31,s-} -> [PrelBase.Char{-38,i-}]
PrelPack.unpackFoldrCStringzh{-0t,s-} ::
forall a{-r9h-} :: PrelGHC.*{-312,l-}.
PrelGHC.Addrzh{-31,s-}
-> (PrelBase.Char{-38,i-} -> a{-r9h-} -> a{-r9h-})
-> a{-r9h-} -> a{-r9h-}
PrelPack.unpackAppendCStringzh{-0s,s-} ::
PrelGHC.Addrzh{-31,s-}
-> [PrelBase.Char{-38,i-}] -> [PrelBase.Char{-38,i-}]
PrelPack.unpackNByteszh{-0r,s-} ::
PrelGHC.Addrzh{-31,s-}
-> PrelGHC.Intzh{-3e,s-} -> [PrelBase.Char{-38,i-}]
PrelPack.packCStringzh{-0j,s-} ::
[PrelBase.Char{-38,i-}] -> PrelGHC.ByteArrayzh{-35,s-}
PrelBase.addr2Integer{-0e,s-} ::
PrelGHC.Addrzh{-31,s-} -> PrelBase.Integer{-3l,i-}
PrelBase.foldr{-07,i-} ::
forall a{-r8k-} :: PrelGHC.*{-312,l-} b{-r8l-} :: PrelGHC.*{-312,l-}.
(a{-r8k-} -> b{-r8l-} -> b{-r8l-})
-> b{-r8l-} -> [a{-r8k-}] -> b{-r8l-}
PrelBase.build{-04,s-} ::
forall a{-r8i-} :: PrelGHC.*{-312,l-}.
(forall b{-r8h-} :: PrelGHC.*{-312,l-}.
(a{-r8i-} -> b{-r8h-} -> b{-r8h-}) -> b{-r8h-} -> b{-r8h-})
-> [a{-r8i-}]
==
-funbox-strict-fields
Why it's not the default (or the only case)?
I don't have a test case to make experiments, but intuitively unboxing
strict fields should be an obvious advantage in most cases. A record
of Bools or Ints - why allocate each separately? I guess they are more
often examined directly than passed further (which needs repacking).
When somebody uses them, he tells that they are "strict parts of the
value" rather than independent objects attached.
Instead of making repacking cheaper, an optimizing GHC should aim at
avoiding it at all, by e.g. passing the unboxed value directly to a
worker of a strict function if it's not inlined. A lazy function will
receive a thunk with the whole selection code anyway.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/GCS/M d- s+:-- a23 C+++$ UL++>$ P+++ L++>$ E-
^^W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-
Re: How to add libgmp.a to lds search path
"Manuel M. T. Chakravarty" wrote: > Is it possible that you are using a Linux box on which the > gmp devel libraries are not (properly) installed? Very likely. Our local sysadmins do not appear to consider integers a sufficiently common concept in computer science to justify a MB or so installing gmp. So I (like about 7 others no doubt) compiled my own copy of gmp and copied libgmp.a to where GHC puts its libraries: [installation directory]/lib/ghc-4.08/
Re: How to add libgmp.a to lds search path
Sven Kuenzler <[EMAIL PROTECTED]> wrote, > I am trying to build fptools from CVS. I have managed to get the binary > releases of happy-1.6 and ghc-4.08 working and configured fptools > successfully. > > The next error I get is that ld cannot find -lgmp. So I built it from > ghc/rts/gmp. > Now, how do I make GHC _find_ that library. I do not have super user > permissions on that machine, so I cannot "make install " > > LD_LIBRARY_PATH is ignored by ghc? Is it possible that you are using a Linux box on which the gmp devel libraries are not (properly) installed? Suse and RedHat do not install gmp development support by default (only if you explicitly install extra packages - eg, the gmp-devel rpm on RedHat). Manuel
How to add libgmp.a to lds search path
Hi, I am trying to build fptools from CVS. I have managed to get the binary releases of happy-1.6 and ghc-4.08 working and configured fptools successfully. The next error I get is that ld cannot find -lgmp. So I built it from ghc/rts/gmp. Now, how do I make GHC _find_ that library. I do not have super user permissions on that machine, so I cannot "make install " LD_LIBRARY_PATH is ignored by ghc? Sven -- We must admit that looking at progress bars does not qualify as working -- Apocalypse Geek
