headers
Daniil Elovkov | 1 Jan 2008 12:24

laura.daun <at> web.am

Привет Лаура!

С Новым Годом тебя и всю твою семью! Мама говорит тебе
там мало солнца.  
День начал удлиняться. Пусть тебе будет светло и
тепло. Мы тебе желаем  
здоровья, интересных приятных событий, поездок, дел.
Пусть Оке и дети  
будут здоровы, удчачливы, всем довольны и тебя радуют!

Gott nytt år till dig, Åke, Aram och David (och deras flickor också) !

Даня и Даша.
Permalink | Reply | 1 comment |
headers
Victor Nazarov | 1 Jan 2008 19:27
Picon
Gravatar

Re: Redefining built in syntax

On Dec 31, 2007 7:58 PM, Neil Mitchell <ndmitchell <at> gmail.com> wrote:
> Hi,
>
> I'm getting errors such as:
>
> C:/Documents/Uni/packages/base/GHC/Base.lhs:270:12:
>     Illegal binding of built-in syntax: []
>
> When I try and compile GHC/Base.lhs using the GHC API. Is there some
> flag I can pass to allow the rebinding of built in syntax?
>

-package-name base

should do the thing
--

-- 
vir
http://vir.comtv.ru/
Permalink | Reply | 5 comments |
headers
Daniil Elovkov | 1 Jan 2008 20:16

Was wrong address

Erm, sorry for the spam.
I failed to manage my email program :)

Happy New Year everybody.

On Tue, 01 Jan 2008 14:24:15 +0300, Daniil Elovkov  
<daniil.elovkov <at> googlemail.com> wrote:
> Привет Лаура!
> ...
Permalink | Reply | 0 comments |
headers
Simon Marlow | 2 Jan 2008 13:48
Picon

Re: ANNOUNCE: GHC version 6.8.2

alpheccar wrote:
> Was someone able to build ghc 6.8.2 on PPC with OS X 10.4 (Tiger) ?
> I had no problems to build the 6.8.1 but with 6.8.2, I get the error:
> 
> ../../compiler/stage1/ghc-inplace -package-name base-3.0.1.0 
> -hide-all-packages -split-objs -i -idist/build/autogen -idist/build -i. 
> -Idist/build -Iinclude -#include "HsBase.h" -odir dist/build -hidir 
> dist/build -stubdir dist/build -package rts-1.0 -O -fglasgow-exts 
> -package-name base -XCPP -idist/build  -H16m -O -O -Rghc-timing 
> -fgenerics -c Data/Generics/Twins.hs -o 
> dist/build/Data/Generics/Twins.o  -ohi dist/build/Data/Generics/Twins.hi
> ghc-6.8.2: panic! (the 'impossible' happened)
>   (GHC version 6.8.2 for powerpc-apple-darwin):
>         lookupVers1 base:GHC.Prim sym{tc}

This is a new bug in 6.8.2 that we discovered just before Christmas:

http://hackage.haskell.org/trac/ghc/ticket/2011

the workaround is simple: just make clean in libraries/base.

Cheers,
	Simon
Permalink | Reply | 0 comments |
headers
Simon Marlow | 2 Jan 2008 14:17
Picon

Re: [Haskell-cafe] Re: #haskell works

Bulat Ziganshin wrote:
> Hello Simon,
> 
> Thursday, December 20, 2007, 4:01:59 PM, you wrote:
> 
>> Fixing it all properly means some fairly significant architectural changes,
>> and dropping the via-C backend
> 
> oh, thank you. from my POV, C backend still may be used together with
> "non-registerized" compilers. in particular, i hope that win-x64 will
> be supported at least in this way
> 
> noone asked my question about plans of win-x64 support. it's important
> for my users, so i ask you again - can you please implement it?
> 
> to other GHC users: i'm pretty sure that win-x64 support will not be
> implemented if it's required only for me. so, if someone need it -
> please write about this to ghc debelopers

It'll get implemented when (a) there is a working mingw64, and (b) it is 
important enough to enough people.  As I understand it, (a) is getting 
closer, but there's still no official release.

My guess is that it's a couple of weeks' work.  Win64 is quite different 
from the x86-64 Unix ABI: the calling convention is different, which means 
that all the FFI stuff has to be ported (the NCG foreign call support, GHCi 
foreign calls, rts/Adjustor.c).  It took me a few days to get these working 
for x86-64 on Unix.

What's more, while x86-64 on Unix is nicer in many ways than the 32-bit
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Marlow | 2 Jan 2008 14:42
Picon

Re: --make should not touch the -o file if it doesn't change it

Alex Jacobson wrote:
> Right now, if you recompile with --make, the exeutable gets a new 
> timestamp.  That seems incorrect.  Is this a bug?

If the executable was re-linked, then it gets a new timestamp, since the 
file's contents have changed, but if no compilation or linking was 
required, then the executable and its timestamp remain unchanged.  Seems ok 
to me, am I missing something?

Cheers,
	Simon
Permalink | Reply | 1 comment |
headers
Simon Marlow | 2 Jan 2008 14:48
Picon

Re: <.> defined in GHC and System.FilePath

Neil Mitchell wrote:

> The GHC API uses the <.> operator, which clashes with System.FilePath.
> Possibly this might want renaming to something else - I have
> absolutely no idea what it does!
> 
> Prelude> :m GHC
> Prelude GHC> :i <.>
> (<.>) :: HsWrapper -> HsWrapper -> HsWrapper    -- Defined in HsBinds

I tend to use

   import qualified GHC
   import GHC (Name, Id, ...)

i.e. qualify most things, but selectively import a few things unqualified. 
  The GHC API is quite huge, I expect clashes to be fairly common if you 
import it unqualified.

Cheers,
	Simon
Permalink | Reply | 0 comments |
headers
Simon Marlow | 2 Jan 2008 15:14
Picon

Re: [Haskell] garbage collection of Concurrent Haskell threads?

[ moving to glasgow-haskell-users <at> haskell.org ]

Conal Elliott wrote:
> Thanks, Simon.  If I understand the mechanism you're describing, it 
> discards readers of an empty MVar when there are no other references to 
> the MVar *because* the MVar can never get written.  And if there are 
> other readers but no writers, then I'm guessing GC wouldn't know that, 
> and none of the readers get discarded.  Is that so?

I'm not sure I understand precisely what you mean here.  Do you mean when 
there are other running threads that might read the MVar in the future?  In 
that case, yes, blocked readers would not be detected and sent an exception.

> I think Baker & Hewitt's trick was analogous to discarding writers of an 
> already full MVar when there are readers (readMVar) but no takers 
> (takeMVar).  (Though not quite, since readMVar is implemented via 
> takeMVar & putMVar.)

It shouldn't be the case that you have a thread doing putMVar on a full 
MVar simultaneously with another thread doing readMVar, because the 
readMVar could be preempted between the take and put and then block - this 
would almost certainly be an undesirable race condition.

> I guess that effectively means IVars instead of MVars.
> 
> In either direction (blocked reader or blocked writer), the interface of 
> MVars (or IVars) would seem to prevent an accurate analysis, since GC 
> wouldn't know whether a Var reference was for reading or writing.
 >
> Right?  A simple solution might be to hide the Var itself and instead
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alex Jacobson | 2 Jan 2008 16:18

Re: --make should not touch the -o file if it doesn't change it

I think this was a bug on my part.  Some file was getting touched that I 
wasn't aware of.  Sorry.

-Alex-

Simon Marlow wrote:
> Alex Jacobson wrote:
>> Right now, if you recompile with --make, the exeutable gets a new 
>> timestamp.  That seems incorrect.  Is this a bug?
> 
> If the executable was re-linked, then it gets a new timestamp, since the 
> file's contents have changed, but if no compilation or linking was 
> required, then the executable and its timestamp remain unchanged.  Seems 
> ok to me, am I missing something?
> 
> Cheers,
>     Simon
Permalink | Reply | 0 comments |
headers
Isaac Dupree | 2 Jan 2008 19:12
Favicon

odd GHC 6.8.2 compile failure

linking the compiled stage2 failed when bootstrapping from 6.6.1, with 
--prefix=$HOME .

It's odd because I previously had a 6.8.2 (official x86 Linux bin-dist) 
installed as root (it's gone now), and I still have a bunch of 
cabal/hackage packages installed in $HOME that were compiled by that 
6.8.2 (in addition to a few things installed by `cabal install` in 
~/.cabal/).  Do you think that could be confusing the build process, and 
if it is, is that a bug - and a bug in what?

...
make[3]: Leaving directory 
`/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2/compiler'
make -f Makefile.ghcbin -wr HS_PROG=stage2/ghc-6.8.2 stage2/ghc-6.8.2
make[3]: Entering directory 
`/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2/compiler'
../compiler/stage1/ghc-inplace -H16m -O -package ghc -Istage2 -cpp 
-fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen 
-Iparser -Rghc-timing  -DGHCI -threaded -fforce-recomp    -c 
main/Main.hs -o stage2/main/Main.o  -ohi stage2/main/Main.hi
<<ghc: 293758172 bytes, 332 GCs, 8590865/18490044 avg/max bytes 
residency (5 samples), 42M in use, 0.00 INIT (0.00 elapsed), 0.83 MUT 
(0.91 elapsed), 0.40 GC (0.43 elapsed) :ghc>>
../compiler/stage1/ghc-inplace -o stage2/ghc-6.8.2 -H16m -O -package ghc 
-Istage2 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen 
-InativeGen -Iparser -Rghc-timing  -DGHCI -threaded -fforce-recomp 
   stage2/main/Main.o
/Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(InstalledPackageInfo.o): 
In function `sEZA_info':
(.text+0x177c4): undefined reference to
(Continue reading)

Permalink | Reply | 7 comments |

Gmane