Timing Stats in ghci-6.6

2006-10-17 Thread Daniel Fischer 
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

2006-10-17 Thread Christian Maeder 
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

2006-10-17 Thread Simon Marlow 

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

2006-10-17 Thread Christian Maeder 
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

2006-10-17 Thread TOPE KAREM 

Hi,
 
After downloading Haskell 98 (current version), I tried to load stdm by typing :load stdm I kept gettin  could not find module 'stdm'
 
I added path under system variables under environment variables like this: control panel/system/Aadvanced/(under system variable)Environment variables/path   c:ghc/stdm.hs 
 
After which I tried to load stdm as before but  no 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,Bulat  mailto:[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

2006-10-17 Thread roconnor 
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 
.


--
Russell O'Connor  
``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

2006-10-17 Thread Clemens Fruhwirth 
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

typo in http://www.haskell.org/onlinereport/prelude-index.html

2006-10-17 Thread Christian Maeder 
I've just noticed the wrong example entry for break:

break:: (a -> Bool) -> [a] -> ([a], [a])
break (<2) [1,2,3] = ([1],[2,3])

this should be changed to:
break (>2) [1,2,3] = ([1,2],[3])

C.

Prelude> break (<2) [1,2,3]
([],[1,2,3])
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Some potentially useful installers..

2006-10-17 Thread Sigbjorn Finne 

Hi,

I've bundled up a bunch of Win32 installers for various
tools that come in handy when developing with&for 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..

2006-10-17 Thread Neil Mitchell 

Hi Sigbjorn,


I've bundled up a bunch of Win32 installers for various
tools that come in handy when developing with&for 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..

2006-10-17 Thread Sigbjorn Finne 

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 with&for 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: ghc-6.6 under sparc-sun-solaris

2006-10-17 Thread Duncan Coutts 
On Tue, 2006-10-17 at 12:15 +0200, Christian Maeder wrote:
> 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'?

Yes! I get exactly the same under sparc linux for ghc-6.6.

We need to file a bug report on this. I wouldn't normally complain too
loudly about sparc linux since it's a bit of a niche market, but if this
same issue affects sparc solaris then that's a bigger user base (lots of
students at several unis).

> 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?

Not "as if", the build system really does add -split-objs and does some
other magic when "SplitObjs=NO" is not in mk/build.mk.

> 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?

No, they will not be 'burned' into the final compiler. To do that you'll
want to modify the ghc wrapper script.

In the Gentoo ghc ebuild we do that with:

# Modify the ghc driver script to use GHC_CFLAGS
echo "SCRIPT_SUBST_VARS += GHC_CFLAGS" >> "${S}/driver/ghc/Makefile"
echo "GHC_CFLAGS = ${GHC_CFLAGS}"  >> "${S}/driver/ghc/Makefile"

before the ./configure and other parts of the build get started.


> P.S. building under solaris requires over 2GB memory (and takes a day)

It takes 12 hours on my old 500Mhz sparc with 1GB ram. I know split-objs
takes lots of memory when building the archive, but 2GB seems excessive.

Duncan

___
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

2006-10-17 Thread John Meacham 
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