headers
Simon Marlow | 1 Feb 2008 10:27
Picon

Re: Using "GHC as a library" with own functions makes runStmt return RunBreak

Mads Lindstrøm wrote:

> For those interested I figured out how to avoid the RunBreak -returns.
> Use RunToCompletion in stead of SingleStep in the application of runStmt.
> I guess Interactive-6.8.hs should also use SingleStep. 

SingleStep is what GHCi uses to implement :step - that is, it runs until 
the next breakpoint location and then stops, returning RunBreak to the 
caller of runStmt.  To run the whole statement, what you want is 
RunToCompletion, as you discovered.

Cheers,
	Simon
Permalink | Reply | 0 comments |
headers
Simon Marlow | 1 Feb 2008 10:37
Picon

Re: Bootstrapping for Leopard

Matthias Kilian wrote:
> On Wed, Jan 30, 2008 at 08:13:01PM +1100, Manuel M T Chakravarty wrote:

> [...]
>> This is due to a change of the configure stage that AFAIK was made to  
>> easy building on windows.  Instead, of using shell commands/scripts  
>> (as GHC did previously) to obtain some configuration information (here  
>> the file path at which the top of the GHC build tree is located), the  
>> build system now uses small Haskell programs/scripts.  This makes the  
>> build more portable ** if there is already a Haskell compiler on the  
>> system **.
> 
> But it just doesn't make sense at all. You need a good set of shell
> commands at all, since they're used by configure as well as in
> Makefiles. I really can't believe that simple stuff like this doesn't
> work on windos:
> 
> --- aclocal.m4.orig	Mon Dec 10 19:11:31 2007
> +++ aclocal.m4	Sun Jan 20 17:10:07 2008
>  <at>  <at>  -1098,20 +1098,14  <at>  <at>  AC_REQUIRE([AC_PROG_CC])
>  AC_DEFUN([FP_FIND_ROOT],[
>  AC_MSG_CHECKING(for path to top of build tree)
>  
> -dnl This would be
> -dnl     make -C utils/pwd clean && make -C utils/pwd
> -dnl except we don't want to have to know what make is called. Sigh.
> -if test ! -f utils/pwd/pwd && test ! -f utils/pwd/pwd.exe; then
> -  cd utils/pwd
> -  rm -f *.o
> -  rm -f *.hi
(Continue reading)

Permalink | Reply | 3 comments |
headers
Simon Marlow | 1 Feb 2008 10:46
Picon

Re: What does unsafePerformIO do to the stack

Bernd Brassel wrote:
> Consider the following program:
> 
> module Stack where
> 
> import System.IO.Unsafe
> 
> main = print (sim (replicate 1299959 ()))
> 
> sim []     = True
> sim (_:xs) = goodStack (sim xs)
> 
> goodStack x = fromJust (Just x)          --no stack overflow
> badStack  x = unsafePerformIO (return x) --stack overflow
> 
> fromJust (Just x) = x

goodStack == id, and GHC even with no optimisation will transform it into 
id, and inline it into sim.  So with goodStack, sim ends up being 
tail-recursive.  With badStack, sim is no longer tail recursive 
(unsafePerformIO is not inlined), so it runs out of stack.  Simple!

> Is this behaviour necessary? Is there any work around, e.g., employing
> the foreign function interface?

There's unsafeInlinePerformIO (sometimes called inlinePerformIO), which is 
usable in certain cases, but be very careful.  From Data.ByteString.Internal:

{-# INLINE inlinePerformIO #-}
inlinePerformIO :: IO a -> a
(Continue reading)

Permalink | Reply | 7 comments |
headers
Simon Marlow | 1 Feb 2008 10:49
Picon

Re: Is GHC 6.8.2 on solaris 32 bits or 64 bits

hsing-chou chen wrote:
> Thank you for porting GHC 6.8.2 to solaris, I am assigned a
> 
> job to make sure GHC run 64 bits on solaris. Is your
> 
> solaris port 64 bits. Or it only 32 BITS. I know 32 bits
> 
> GHC can still run on 64 bits solaris. However company want
> 
> to run really 64 bits GHC on solaris. Thanks a lot if you

You want to look at the porting instructions:

http://hackage.haskell.org/trac/ghc/wiki/Building/Porting

Start from GHC 6.6.1 (6.8.2 doesn't bootstrap from .hc files yet).

This won't be easy, you'll need to know details of the processor 
architecture, and be prepared to learn about GHC internals.  But it'll be 
fun, if you like that sort of thing :)

Cheers,
	Simon
Permalink | Reply | 2 comments |
headers
Bernd Brassel | 1 Feb 2008 13:39
Picon

Re: What does unsafePerformIO do to the stack

Thanks for your answer Simon.

Simon Marlow wrote:
> Bernd Brassel wrote:
>> Consider the following program:
>>
>> module Stack where
>>
>> import System.IO.Unsafe
>>
>> main = print (sim (replicate 1299959 ()))
>>
>> sim []     = True
>> sim (_:xs) = goodStack (sim xs)
>>
>> goodStack x = fromJust (Just x)          --no stack overflow
>> badStack  x = unsafePerformIO (return x) --stack overflow
>>
>> fromJust (Just x) = x
> 
> goodStack == id, and GHC even with no optimisation will transform it
> into id, and inline it into sim.  So with goodStack, sim ends up being
> tail-recursive.  With badStack, sim is no longer tail recursive
> (unsafePerformIO is not inlined), so it runs out of stack.  Simple!

Is it really that simple? I guess that in a lazy language we have to
look a bit closer to see what is tail recursive and what is not. If I
understand you correctly, you say that if goodStack was not inlined you
would have a bad stack as well, right? But look at what it would be
doing. In a lazy language the call to sim would go to the heap and
(Continue reading)

Permalink | Reply | 5 comments |
headers
Peter Achten | 1 Feb 2008 13:50
Picon
Favicon

Second Call for Papers TFP 2008, The Netherlands

2ND CALL FOR PAPERS
TRENDS IN FUNCTIONAL PROGRAMMING 2008
RADBOUD UNIVERSITY NIJMEGEN, THE NETHERLANDS
MAY 26-28, 2008
INVITED SPEAKER: PROF. HENK BARENDREGT
http://www.st.cs.ru.nl/AFP_TFP_2008/

The symposium on Trends in Functional Programming (TFP) is an
international forum for researchers with interests in all aspects of
functional programming languages, focusing on providing a broad view
of current and future trends in Functional Programming. It aspires to
be a lively environment for presenting the latest research results
through acceptance by extended abstracts and full papers. A formal
post-symposium refereeing process selects the best articles presented
at the symposium for publication in a high-profile volume.

TFP 2008 is hosted by the Radboud University Nijmegen, The Netherlands,
and will be held in the rural setting of Center Parcs “Het Heijderbos”,
Heijen (in the vicinity of Nijmegen), The Netherlands.

TFP 2008 is co-located with the 6th Int’l. Summer School on Advanced
Functional Programming (AFP’08), which is held immediately before TFP’08.

SCOPE OF THE SYMPOSIUM
The symposium recognizes that new trends may arise through various
routes. As part of the Symposium's focus on trends we therefore identify
the following five article categories. High-quality articles are
solicited in any of these categories:

Research: leading-edge, previously unpublished research.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Denis Bueno | 2 Feb 2008 18:27
Picon

Re: Read instance of StdGen returns no parse

On Jan 26, 2008 7:01 PM, Yitzchak Gale <gale <at> sefer.org> wrote:
[snip explanation]
> The documentation in System.Random is a bit misleading.
> It says "the read instance of StdGen has the following properties:
> It guarantees to succeed on any string..." The word "read" should
> really be "Read" instead. It also wouldn't hurt to mention that the
> read *function* may fail, so use reads instead.
>
> Hope this helps.

Definitely.  The error now makes sense.  Thanks for the response.

--

-- 
                              Denis
Permalink | Reply | 0 comments |
headers
Tim Chevalier | 3 Feb 2008 02:44
Picon
Gravatar

Re: [Haskell-cafe] strange GHC assembler failure

On 2/2/08, Tim Newsham <newsham <at> lava.net> wrote:
> I'm getting a weird build error:
> [ 9 of 95] Compiling Plugin.Pl.Common ( Plugin/Pl/Common.hs,
> dist/build/lambdabot/lambdabot-tmp/Plugin/Pl/Common.o )
> /tmp/ghc52608_0/ghc52608_0.s: Assembler messages:
>
> /tmp/ghc52608_0/ghc52608_0.s:36:0:  Error: unassigned file number 1
> [... more of these ...]
>
> I narrowed this down -- this happens when I add my new library
> "silc-client" to the "Build-depends:" line in the cabal file even
> if none of its code is referenced.  Removing the dependency makes
> the error go away.  The module I'm referencing is a new one I'm
> still working on and it makes use of FFI and references external
> headers and libraries.
> (I put a copy at http://www.thenewsh.com/~newsham/silc-client.tgz
> if it helps anyone debug..  this is not release-quality code
> though).
>
> Any idea what is going on here?
>

This would probably be a better question for ghc-users, since that's a
lower-traffic list for GHC-specific questions. Redirected there.

Cheers,
Tim

--

-- 
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian Lynagh | 3 Feb 2008 17:35
Picon
Gravatar

Re: Bootstrapping for Leopard

On Wed, Jan 30, 2008 at 08:13:01PM +1100, Manuel M T Chakravarty wrote:
> Philip K.F. Hölzenspies:
> >
> >for f in `$(FIND) ghc-$(ProjectVersion)/compiler
> >ghc-$(ProjectVersion)/rts -name "*.cmm" -follow -print` ""; do \
> > if test "x$$f" !=3D "x"; then \
> >   echo `echo "$$f" | sed 's/cmm$$/hc/g' ` >> hc-files-to-go ; \
> > fi; \
> >done;
> >
> >This adds some non-existing .hc files to the hc-files-to-go list  
> >that tar will
> >not find, later on, causing an error. I just added a test to see  
> >whether the
> >file exists. If it does not, I call make for that .hc file  
> >explicitly, which
> >solves the problem for most files. The files that don't have a make  
> >target, I
> >simply omitted from the hc-files-to-go. I haven't been able to test  
> >the
> >severity of this, because of the second problem.
> 
> I am not sure what the problem is here.  Simon?  Ian?

I think there are some files that are meant to be missing; you can
ignore the tar warnings/errors about them.

I'm not sure what they are OTTOMH - possibly debug, prof, debug_prof etc
variants of AutoApply.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Philip Hölzenspies | 3 Feb 2008 18:12
Picon
Picon
Favicon

Re: Bootstrapping for Leopard

On Feb 3, 2008, at 5:35 PM, Ian Lynagh wrote:
> I think there are some files that are meant to be missing; you can
> ignore the tar warnings/errors about them.
>
> I'm not sure what they are OTTOMH - possibly debug, prof, debug_prof  
> etc
> variants of AutoApply.

Dear Ian, All,

They are indeed variants of AutoApply, but to simply ignore the tar  
error does not seem like a good idea. Tar terminates upon these errors  
and other stuff gets added to the hc-files-to-go later on in the  
Makefile. IMHO, if indeed these files are not required, the makefile  
should read:

for f in `$(FIND) ghc-$(ProjectVersion)/compiler ghc-$(ProjectVersion)/ 
rts -name "*.cmm" -follow -print` ""; do\
	fd="`echo $$f | sed 's/cmm$$/hc/g'`; \
	if test "x$$f" != "x" -a -e "$$fd"; then \
		echo $fd >> hc-files-to-go; \
	fi; \
done;

I don't know whether the -a argument for test is "common" test syntax,  
but it should give a logical. The -e option tests that "$$fd" exists  
and is a file.

Regards,
Philip
(Continue reading)

Permalink | Reply | 0 comments |

Gmane