Timing Stats in ghci-6.6
Hi, apparently the timing doesn't work properly in ghci 6.6 (at least for me), I always get very small timings, usually 0.01 secs, sometimes 0.00 secs, once 0.07 secs, no matter how long it actually took. Is that a common problem or is it only me? Cheers, Daniel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc for PC Solaris
Simon Marlow schrieb: You should be able to use any platform with a working GHC 6.6 to bootstrap from; x86/Linux is fine. Ian bootstraps GHC on new machines for fun(!), so I'm pretty sure the process has most of the kinks ironed out at the moment. Ok, I've got a hc-file-bundle now. Comparing to http://www.haskell.org/ghc/docs/6.6/html/building/sec-porting-ghc.html#unregisterised-porting I made (had to make) the following differently: 1. I copied also ghcplatform.h from the target to the host's includes directory. Was that wrong? 2.) The directories glafp-utils and ghc do not exist in the ghc-6.6 sources so I simply called make boot make in the top-level host directory. (It failed in rts as expected) 3.) For the final make hc-file-bundle Project=Ghc I had to delete one line in the toplevel Makefile: [..]libraries/haskell-src/Language/Haskell/Parser.hs hc-files-to-go haskell-src is not a part of ghc-6.6 (without extra libs) So far Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Hacking on GHC interactively with GHCi
Clemens Fruhwirth wrote: Hello everyone, I would like to hack on GHC interactively. My aim is to load ghc into ghci and start hacking a source file in one emacs buffer, while the other hosts an inferior-haskell session connected to GHCi. I really like this kind of development style and found it to be way more productive than edit/compile/test/restart from edit. To context of the following is the compiler/ subtree, as I'm primarily interested in that. I tried to: * load all GHC compiler source files into ghci, fails because of occassional unboxed types (bytecode generated can't deal with them) * load all .o files (with unboxed types) and load a modified source in interpreted mode. This doesn't work well because for that approach you need to mix the source with the object in the same directory (copy compiler/**/*.[l]hs to stage1 or stage2). This, fails because there seem to be some sources missing, I have not investiged where the .o-boot files come from like compiler/stage2/basicTypes/OccName.o-boot. With source files, GHCi just ignores the existing .o file (resumable because it can't check whether the .o file is more recent than the source file) This is something we haven't tried, although if you get all the files in the right places I don't see any reason why it shouldn't work. * load ghci -package ghc and load main/Main.hs. This work pretty well, but only in comparsion to the other approaches -- that means loading does not fail. Invoking :main -c foobar.hs freezes the ghci session. With this approach I can not change any module withing the packaged ghc. Is that true? But that's what I want to do (in particular to the parser part). It should be possible to do this, except that I'm fairly certain you'll run into trouble if you try to run GHCi within itself due to the global state of the RTS linker. But just doing ordinary compilation in GHC loaded into GHCi should work. We have done some simple experiments using the GHC API from inside GHCi. It sounds like there's a straightforward way to show the problem, so could you submit a ticket detailing what you did to reproduce it? Thanks. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6 under sparc-sun-solaris
Duncan Coutts schrieb: So ghc -split-objs works now with either -optc-mcpu=v8 or -opta-mcpu=v9 (or even -opta-mcpu=ultrasparc). Where should I place what so that my stage1 inplace-compiler works without SplitObjs=NO in mk/build.mk? Try SRC_HC_OPTS = -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc With this I've produced a binary saying: -bash-3.00$ ghc --version ghc-6.6: schedule: re-entered unsafely. Perhaps a 'foreign import unsafe' should be 'safe'? Two further questions: 1. Without SplitObjs=NO in mk/build.mk, will every file be compiled as if -split-objs were on ghc's command line? 2. Will the options given in SRC_HC_OPTS be burned into the final stage2 compiler or will I have to supply these options explicitely again? Thanks Christian P.S. building under solaris requires over 2GB memory (and takes a day) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: scoped tyvar
Hi, After downloading Haskell 98 (current version), I tried to load stdm by typing :load stdm I kept gettin command line could not find module 'stdm' Iadded path under system variables under environment variables like this: control panel/system/Aadvanced/(under system variable)Environment variables/pathc:ghc/stdm.hs After which I tried to load stdm as before butno changes. Could you please help. Thanks Tope, South Africa On 10/17/06, Bulat Ziganshin [EMAIL PROTECTED] wrote: Hello glasgow-haskell-users,should the following work in 6.6?-- | Alloc the mutable byte vector having `elems` elements of required type allocUnboxed :: (STorIO m s, Integral elems, Unboxed a)= elems - m (MUVec s a)allocUnboxed elems :: m (MUVec s a) =-- it's line 149 allocUnboxedBytes (fromIntegral elems * sizeOfUnboxed (undefined::a)) the problem is that it works in 6.6rc1, but user reports that hiscompiler (i think, 6.6 release) can't compile it saying:Data/Unboxed.hs:149:0: Parse error in patternmay be it's because september's changes in scoped tyvars handling? how i can convert this code retaining compatibility with Hugs?--Best regards,Bulatmailto:[EMAIL PROTECTED]___ Glasgow-haskell-users mailing listGlasgow-haskell-users@haskell.orghttp://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: foldl laziness support. Reply
Although this doesn't answer your question, I think it is releated. When implementing SHA, I need to create a recursive function to append the length of a string to the string. This function needed to be strict, because it needed to accumulted the length of the string, and it needed to be lazy, because it needed to re-emmit the characters that it consumed. I have a short discussion about this at http://r6.livejournal.com/91508.html. -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Hacking on GHC interactively with GHCi
At Tue, 17 Oct 2006 10:26:15 +0100, Simon Marlow [EMAIL PROTECTED] wrote: Clemens Fruhwirth wrote: * load all .o files (with unboxed types) and load a modified source in interpreted mode. This doesn't work well because for that approach you need to mix the source with the object in the same directory (copy compiler/**/*.[l]hs to stage1 or stage2). This, fails because there seem to be some sources missing, I have not investiged where the .o-boot files come from like compiler/stage2/basicTypes/OccName.o-boot. With source files, GHCi just ignores the existing .o file (resumable because it can't check whether the .o file is more recent than the source file) This is something we haven't tried, although if you get all the files in the right places I don't see any reason why it shouldn't work. Any easy ways to do this :) ? * load ghci -package ghc and load main/Main.hs. This work pretty well, but only in comparsion to the other approaches -- that means loading does not fail. Invoking :main -c foobar.hs freezes the ghci session. With this approach I can not change any module withing the packaged ghc. Is that true? But that's what I want to do (in particular to the parser part). It should be possible to do this, except that I'm fairly certain you'll run into trouble if you try to run GHCi within itself due to the global state of the RTS linker. But just doing ordinary compilation in GHC loaded into GHCi should work. We have done some simple experiments using the GHC API from inside GHCi. It sounds like there's a straightforward way to show the problem, so could you submit a ticket detailing what you did to reproduce it? Thanks. Here is my session. I didn't noticed on the first run that it doesn't freeze first, but only after multiple invokations. So, this puts the thing in a different perspective. It works in principal but maybe there are some leftovers from the previous runs. ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Prelude :cd ~/ther-devel/ghc-6.6/compiler Prelude :set -I. -Istage1 -cpp -fglasgow-exts -package ghc ...[remark, stage1 is populated from a compile run, in particular with ghc_boot_plattform.h] Loading package template-haskell ... linking ... done. ...[cutted] Loading package ghc-6.6 ... linking ... done. Prelude :load /home/clemens/ther-devel/ghc-6.6/compiler/main/Main.hs [1 of 1] Compiling Main ( /home/clemens/ther-devel/ghc-6.6/compiler/main/Main.hs, interpreted ) Ok, modules loaded: Main. *Main :main -B/usr/lib/ghc-6.6 --help Usage: ghci [command-line-options-and-input-files] ...[removed]... *** Exception: exit: ExitSuccess *Main :main -B/usr/lib/ghc-6.6 --help ...[freeze here .. pressed C-c] *** Exception: exit: ExitFailure 1 *Main Unless you tell me that I made some mistakes here, I will file this as a bug with GHC trac. Thanks, -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Some potentially useful installers..
Hi, I've bundled up a bunch of Win32 installers for various tools that come in handy when developing withfor GHC: Alex, Happy, and Haddock (aka The Marlow Collection) http://galois.com/~sof/msi/alex-2-0-1.msi http://galois.com/~sof/msi/happy-1-15.msi http://galois.com/~sof/msi/haddock-0-7.msi enjoy, --sigbjorn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Some potentially useful installers..
Hi Sigbjorn, I've bundled up a bunch of Win32 installers for various tools that come in handy when developing withfor GHC: Alex, Happy, and Haddock (aka The Marlow Collection) Are the tools used to build these installers available? Thanks Neil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Some potentially useful installers..
Hi, some day (soon) --sigbjorn Neil Mitchell wrote: Hi Sigbjorn, I've bundled up a bunch of Win32 installers for various tools that come in handy when developing withfor GHC: Alex, Happy, and Haddock (aka The Marlow Collection) Are the tools used to build these installers available? Thanks Neil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Expecting more inlining for bit shifting
On Mon, Oct 09, 2006 at 03:54:41PM +0100, Ian Lynagh wrote:
It might be possible, but it sounds tricky. I guess it would have to go
something like try inlining this, run the simplifier, see if it got
small enough, if not back out, which could waste a lot of work if it
fails in lots of cases.
I would think the easiest way to go about this would be to extend the
rules pragma.
{-# RULES shift/const-inline forall x y# . shift x y# = ... #-}
where variables ending in # will only match constants known at compile
time. or perhaps..
{-# RULES shift/const-inline forall x (y::const Int) . shift x y# = ... #-}
or something like that.
I imagine such a thing would have other uses as well...
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
