Hi Ian, Simon,
I have ghc-6.6 (darcs version from 20070405) running registerized on
FreeBSD/amd64. The FreeBSD version is 6.2.
The problem with the compiler crash turned out to be simple. In the
FreeBSD header file regex.h, regex_t is defined as
typedef struct {
int re_magic;
On Sun, Apr 08, 2007 at 07:49:24PM -0400, Gregory Wright wrote:
>
> I have ghc-6.6 (darcs version from 20070405) running registerized on
> FreeBSD/amd64.
Excellent! Well done, and thanks for persevering!
It would be great if you could let us have a bindist and any necessary
patches.
> The fix i
Hi Ian,
On Apr 9, 2007, at 12:21 PM, Ian Lynagh wrote:
On Sun, Apr 08, 2007 at 07:49:24PM -0400, Gregory Wright wrote:
I have ghc-6.6 (darcs version from 20070405) running registerized on
FreeBSD/amd64.
Excellent! Well done, and thanks for persevering!
It would be great if you could let u
Hi Ian,
On Apr 9, 2007, at 12:21 PM, Ian Lynagh wrote:
With this patch, we are pretty close. However, there still seems
to be
something wrong with the splitter. I can make a working registerized
compiler if I set splitObjs=NO in build.mk, but it seems as if
whatever is
wrong with ghc-spli
Gregory Wright wrote:
I have ghc-6.6 (darcs version from 20070405) running registerized on
FreeBSD/amd64. The FreeBSD version is 6.2.
The problem with the compiler crash turned out to be simple. In the
FreeBSD header file regex.h, regex_t is defined as
typedef struct {
int re_magic;
Simon Marlow wrote:
> Aha. Text/Regex/Posix.hs is generated from Text/Regex/Posix.hsc by
> hsc2hs, but this is done on the *host* rather than the *target* when
> bootstrapping, and thus generates the wrong results. If you'd run
> hsc2hs on the target, then Text/Regex/Posix.hs would have been corr
Hi Olli,
On Apr 10, 2007, at 1:23 PM, Oliver Braun wrote:
Hi Gregory,
* Gregory Wright <[EMAIL PROTECTED]> [2007-04-09 12:38 -0400]:
I have ghc-6.6 (darcs version from 20070405) running
registerized on
FreeBSD/amd64.
I will certainly provide patches and a binary distribution that
people
Chris Kuklewicz wrote:
Simon Marlow wrote:
Aha. Text/Regex/Posix.hs is generated from Text/Regex/Posix.hsc by
hsc2hs, but this is done on the *host* rather than the *target* when
bootstrapping, and thus generates the wrong results. If you'd run
hsc2hs on the target, then Text/Regex/Posix.hs wo
Simon Marlow wrote:
> Chris Kuklewicz wrote:
>> Could the solution be to depend on a pure Haskell regex implementation
>> instead
>> of on a regex-posix / Posix.hsc and the system regex library?
>
> Yes, as I mentioned, ticket 1160
> (http://hackage.haskell.org/trac/ghc/ticket/1160) is for replaci
Just a further note on the FreeBSD/amd64 port. I have the
mangler fixed up now, so the only remaining issue is the linker.
I hope to send patches soon.
Best Wishes,
Greg
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http:/
Simon Marlow <[EMAIL PROTECTED]> wrote:
> Also after the base
> reorg we might find we have no hsc2hs-generated code left in base and
> we can disable hsc2hs to prevent this happening again.
Ah. I was about to checkin a replacement for System.Posix.Types (in
base) that uses hsc2hs instead of a
Malcolm Wallace wrote:
Simon Marlow <[EMAIL PROTECTED]> wrote:
Also after the base
reorg we might find we have no hsc2hs-generated code left in base and
we can disable hsc2hs to prevent this happening again.
Ah. I was about to checkin a replacement for System.Posix.Types (in
base) that use
Simon Marlow <[EMAIL PROTECTED]> wrote:
> I suppose we could add a dependency on another Haskell compiler just to
> run hsc2hs, but that's a pain.
I'm hoping that by the end of this summer, nhc98 will be able to compile
the whole of ghc. :-) Also, and alternatively, the yhc chaps have
mooted t
Hi
I'm hoping that by the end of this summer, nhc98 will be able to compile
the whole of ghc. :-) Also, and alternatively, the yhc chaps have
mooted the idea of moving from nhc98's front end to ghc's, which might
eventually give you a fully portable bytecode route to bootstrapping ghc
on new m
I'm confused. I thought we copied the configuration from the target to the host
as part of the bootstrapping process, but now I can't see how this is supposed
to happen for HsBaseConfig.h. It looks like following the instructions in the
building guide will result in failure if you try to cross
Simon Marlow <[EMAIL PROTECTED]> writes:
> > Ah. I was about to checkin a replacement for System.Posix.Types (in
> > base) that uses hsc2hs instead of autoconf.
>
> Anyway, to answer your question, using hsc2hs in System.Posix.Types
> will cause problems for bootstrapping GHC, yes, because we ca
On Thu, Apr 12, 2007 at 04:33:27PM +0100, Simon Marlow wrote:
>
> I'm confused. I thought we copied the configuration from the target to the
> host as part of the bootstrapping process, but now I can't see how this is
> supposed to happen for HsBaseConfig.h. It looks like following the
> inst
On Thu, Apr 12, 2007 at 08:49:03PM +0100, Malcolm Wallace wrote:
> Simon Marlow <[EMAIL PROTECTED]> writes:
>
> > > Ah. I was about to checkin a replacement for System.Posix.Types (in
> > > base) that uses hsc2hs instead of autoconf.
> >
> > Anyway, to answer your question, using hsc2hs in Syste
Neil Mitchell wrote:
Hi
I'm hoping that by the end of this summer, nhc98 will be able to compile
the whole of ghc. :-) Also, and alternatively, the yhc chaps have
mooted the idea of moving from nhc98's front end to ghc's, which might
eventually give you a fully portable bytecode route to boot
Claus Reinke wrote:
I'm confused. I thought we copied the configuration from the target
to the host as part of the bootstrapping process, but now I can't see
how this is supposed to happen for HsBaseConfig.h. It looks like
following the instructions in the building guide will result in
failu
Hi
How do you plan to implement unboxed types? AFAIK, implementing unboxed types
requires a typed intermediate language. Maybe you could get away with boxing
all the unboxed types, but then Int would have an extra level of boxing.
Indeed, we intend to box everything. Plus there were compiler
Neil Mitchell wrote:
Hi
How do you plan to implement unboxed types? AFAIK, implementing
unboxed types
requires a typed intermediate language. Maybe you could get away with
boxing
all the unboxed types, but then Int would have an extra level of boxing.
Indeed, we intend to box everything.
Hi
> Indeed, we intend to box everything. Plus there were compilers which
> did unboxing before having unboxed types - as the paper said, it
> wasn't as neat, but it was possible.
Right, but the problem is that if you box all of GHC's unboxed types, you end up
with an extra layer of boxing comp
I wrote:
> So, should I push my patch for building
> System.Posix.Types with nhc98 (i.e. without autoconf, with hsc2hs)?
OK, I have pushed a revised patch, which should not alter the behaviour
for ghc at all. I moved the invocation of hsc2hs into the NHC.*
hierarchy, and just re-export that modul
Hello Chris,
Wednesday, April 11, 2007, 12:23:35 PM, you wrote:
> After I upgrade to 6.6.1 (using OS X on PPC) then I will make new versions of
> regex-compat and regex-tdfa. The thing I have to fix is that the current
> "unstable" regex-tdfa depends on the "unstable" regex-base and I have to ma
25 matches
Mail list logo
