Has there been any thought about working with the LLVM project? I
didn't find anything on the wiki along those lines.
Thanks,
Deborah
On Aug 26, 2008, at 10:57 AM, Don Stewart wrote:
I think we're all rather excited about seeing this stuff land.
What's the expected timeline, wrt. ghc 6.10's
You can't determine Unicode character properties by analyzing the
names of the characters.
Read chapter 4 of the standard:
http://www.unicode.org/versions/Unicode5.0.0/ch04.pdf
and get the property values here:
http://www.unicode.org/Public/UNIDATA/DerivedCoreProperties.txt
It sounds like
Sm = Symbol, math
Sc = Symbol, currency
Sk = Symbol, modifier
So = Symbol, other
Zs = Separator, space
Zl = Separator, line
Zp = Separator, paragraph
Cc = Other, control
Cf = Other, format
Cs = Other, surrogate
Co = Other, private use
Cn = Other, not assigned (including noncharacters)
Deborah
All characters with general category Lu have the property Uppercase,
but the converse is not true.
Deborah
On Aug 25, 2008, at 8:27 PM, Richard A. O'Keefe wrote:
On 26 Aug 2008, at 1:31 pm, Deborah Goldsmith wrote:
You can't determine Unicode character properties by analyzing the
names
I tried building 6.8.3, and just make worked, but when I tried make
framework-pkg I got stuff like this:
com.apple.tools.info-plist-utility /Users/chak/Code/ghc/
distrib/MacOS/Info copy.plist -expandbuildsettings -o /Users/debbie/
On Jun 14, 2008, at 1:06 PM, Don Stewart wrote:
tom.davie:
In the mean time -- who knows enough to make ghc target ARM, and get
this to link against the iPhone libraries? This would be quite a
coup
if it could be made to run there!
I'd be interested. We should start a wiki page for
On Dec 21, 2007, at 3:40 PM, Thorkil Naur wrote:
1. Which readline do we use? GNU readline, of course. As opposed to
the
readline installed as /usr/include/readline/*.h
and /usr/lib/libreadline.dylib on our PPC Mac OS X machines which
are said to
be (and can even be observed to be)
I see this:
$ runhaskell ./Setup.lhs build
Preprocessing executables for haddock-0.8...
shift/reduce conflicts: 5
Building haddock-0.8...
src/Main.hs:49:7:
Could not find module `System.Directory':
it is a member of package directory-1.0.0.0, which is hidden
Any ideas?
Thanks,
I stupidly missed the make sure you are logged out part, and now I
can't log in to the account I created. :-/ Any suggestions? When I log
in it just logs me in as guest without any interaction.
Deborah
On Nov 22, 2007, at 3:38 AM, Ian Lynagh wrote:
Hi all,
It is now possible to register
browsers/OSes.
Hope that helps,
-Judah
On Nov 22, 2007 10:41 AM, Deborah Goldsmith [EMAIL PROTECTED]
wrote:
I stupidly missed the make sure you are logged out part, and now I
can't log in to the account I created. :-/ Any suggestions? When I
log
in it just logs me in as guest without any
If you want to get the path to the main executable on Mac OS X, use
_NSGetExecutablePath. See:
man 3 dyld
Deborah
On Nov 19, 2007, at 4:07 AM, Christian Maeder wrote:
An additional sanity check of topdir makes sense then.
Christian
Alfonso Acosta wrote:
Simon, as usual, is right. It's
On Nov 6, 2007, at 4:06 PM, Manuel M T Chakravarty wrote:
I wasn't expecting any backwards compatibility from Leopard-built
software to Tiger, but then I am also a Mac-noob and maybe there are
ways to achieve that that I don't know of. Any suggestions?
Sorry, I missed this the first time
I asked internally at Apple about this and got the following response:
obvious symptom: stage2 compiler segfaults, gdb reports:
Program received signal SIGTRAP, Trace/breakpoint trap.
0x8fe0100c in __dyld__dyld_start ()
Ignore that. `continue` to actually run the program and get to the
I'm seeing this, too. An fgrep of /usr/include for environ picked up
this:
/usr/include/X11/Xw32defs.h:#define environ _environ
Is there any reason this X11 header would get included? That would
mess up this in HsBase.h:
/* ToDo: write a feature test that doesn't assume 'environ' to
On Oct 2, 2007, at 5:11 AM, ChrisK wrote:
Deborah Goldsmith wrote:
UTF-16 is the native encoding used for Cocoa, Java, ICU, and
Carbon, and
is what appears in the APIs for all of them. UTF-16 is also what's
stored in the volume catalog on Mac disks. UTF-8 is only used in BSD
APIs
On Oct 2, 2007, at 8:44 AM, Jonathan Cast wrote:
I would like to, again, strongly argue against sacrificing
compatibility
with Linux/BSD/etc. for the sake of compatibility with OS X or
Windows.
FFI bindings have to convert data formats in any case; Haskell
shouldn't
gratuitously break Linux
On Oct 2, 2007, at 3:01 PM, Twan van Laarhoven wrote:
Lots of people wrote:
I want a UTF-8 bikeshed!
No, I want a UTF-16 bikeshed!
What the heck does it matter what encoding the library uses
internally? I expect the interface to be something like (from my own
CompactString library):
Sorry for the long delay, work has been really busy...
On Sep 27, 2007, at 12:25 PM, Aaron Denney wrote:
On 2007-09-27, Aaron Denney [EMAIL PROTECTED] wrote:
Well, not so much. As Duncan mentioned, it's a matter of what the
most
common case is. UTF-16 is effectively fixed-width for the
On Sep 26, 2007, at 11:06 AM, Aaron Denney wrote:
UTF-16 has no advantage over UTF-8 in this respect, because of
surrogate
pairs and combining characters.
Good point.
Well, not so much. As Duncan mentioned, it's a matter of what the most
common case is. UTF-16 is effectively fixed-width
I'll look over the proposal more carefully when I get time, but the
most important issue is to not let the storage type leak into the
interface.
From an implementation point of view, UTF-16 is the most efficient
representation for processing Unicode. It's the native Unicode
On Jun 12, 2007, at 1:52 AM, Martin Grabmueller wrote:
LLVM is indeed interesting, but has several drawbacks:
- written in C++ (we don't have experience in interfacing Haskell
and C++)
You'd have to write a C wrapper, or generate the LLVM intermediate
language directly from Haskell.
-
On May 30, 2007, at 2:24 AM, Christian Maeder wrote:
Deborah Goldsmith schrieb:
OK, I was able to build 6.6.1 successfully on 10.4 (Intel Core
Duo) with
both the standard configuration and with SplitObjs = NO. The build
was
done with the same binary 6.6.1 release, GMP, and GNU readline
).
The messages about .dSYM are due to a change in the default debugging
file format for 10.5. I can't say any more than that.
Is there anything else you would like me to try?
Thanks,
Deborah
On May 25, 2007, at 1:48 AM, Christian Maeder wrote:
Deborah Goldsmith schrieb:
I'm also going to try building
On May 23, 2007, at 2:08 AM, Simon Marlow wrote:
Deborah Goldsmith wrote:
On May 22, 2007, at 1:59 AM, Christian Maeder wrote:
What are you trying to achieve? Did you compile parts with
ghc-6.6 and
ghc-6.6.1? (That may explain the crash.)
If you have installed my binary distribution you
On May 23, 2007, at 2:08 AM, Simon Marlow wrote:
One possibility is that if you compiled GHC via C (I believe this
is still the default in 6.6.1), then changes in the gcc shipped
with 10.5 might be causing problems. You might get further by adding
SRC_HC_OPTS = -O -fasm
GhcStage1HcOpts
Did you point configure at where your readline library is installed,
as discussed on the below wiki page?
http://hackage.haskell.org/trac/ghc/wiki/Building/MacOSX
Deborah
On May 23, 2007, at 6:06 PM, Philip Weaver wrote:
Hello all,
My first email to this list, so I apologize if I don't
- 0x94e75fed libgcc_s.1.dylib ??? (???)
1b0a4147d838c7cdc644818e0d15ec25 /usr/lib/libgcc_s.1.dylib
0x - 0x1780 libSystem.B.dylib ??? (???) /usr/lib/
libSystem.B.dylib
Any suggestions for how to proceed at this point?
Thanks,
Deborah
On May 17, 2007, at 8:44 PM, Deborah Goldsmith wrote
- 0x1780 libSystem.B.dylib ??? (???) /usr/lib/
libSystem.B.dylib
Deborah
On May 18, 2007, at 1:59 PM, Deborah Goldsmith wrote:
Here is more detailed crash information, FWIW:
Process: ghc-6.6.1 [37476]
Path:/Volumes/Totoro/source/ghc-6.6.1/compiler/stage1/
ghc-6.6.1
] Error 2
I'll be happy to do any other investigation anyone suggests.
Thanks,
Deborah
On May 8, 2007, at 2:29 AM, Simon Marlow wrote:
Deborah Goldsmith wrote:
Actually, I'm not sure that's what's going on. The unresolved symbol
error is:
../../compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp
On May 7, 2007, at 6:04 AM, Simon Marlow wrote:
Deborah Goldsmith wrote:
I believe what's going on here is that strerror has been changed
for better Unix conformance, under the control of the
__DARWIN_UNIX03 preprocessor flag. This is something you'll see in
10.4.x too. Here's an excerpt
of this
problem. If it's on our side we'd like to fix it, and if it's on your
side we'd like to help you be ready for Leopard.
Thanks,
Deborah Goldsmith
Internationalization, Unicode liaison
Apple Inc.
[EMAIL PROTECTED]
___
Glasgow-haskell-bugs
the projects to work when
the new version comes out. :-)
If you can think of something to try I'll be happy to try it for you
and report back.
Thanks,
Deborah
On May 4, 2007, at 5:43 AM, Malcolm Wallace wrote:
Deborah Goldsmith [EMAIL PROTECTED] wrote:
/tmp/ghc78351_0/ghc78351_0.split__108
On Thu, 2007-02-08 at 17:01 -0800, John Meacham wrote:
UCS-2 is a disaster in every way. someone had to say it. :)
UCS-2 has been deprecated for many years.
everything should be ascii, utf8 or ucs-4 or migrating to it.
UCS-4 has also been deprecated for many years. The main forms of
I can reproduce this with ghc-6.6 built from source as well. I
sampled ghc while it was stuck like this, and it looks like it's
trying to open a GUI event loop (not surprising if it's opening a
window). It looks like something about that is not working.
Unfortunately, the Intel binary
This also fails in Hugs (crashes rather than hangs), so it looks like
it's a problem with the GLUT binding on Mac OS X Intel rather than
something specific to GHC. I'll see if I can find a PPC machine to
try it on also.
Deborah
On Dec 1, 2006, at 5:13 PM, Deborah Goldsmith wrote:
I can
It fails on PowerPC too, using the standard PPC distribution.
Deborah
On Dec 1, 2006, at 6:41 PM, Deborah Goldsmith wrote:
This also fails in Hugs (crashes rather than hangs), so it looks
like it's a problem with the GLUT binding on Mac OS X Intel rather
than something specific to GHC
I can get this to work if I compile it with ghc, rather than try to
run it with ghci or hugs.
ghc --make Alpha3D.hs
./Alpha3D
works fine with no hangs.
Deborah
On Dec 1, 2006, at 6:49 PM, Deborah Goldsmith wrote:
It fails on PowerPC too, using the standard PPC distribution.
Deborah
the problem by launching ghci with
DYLD_LIBRARY_PATH set to include the X11 shared library directory.
Deborah
On Nov 16, 2006, at 4:04 PM, Deborah Goldsmith wrote:
There are some notes on the Wiki:
http://hackage.haskell.org/trac/ghc/wiki/X86OSXGhc
that may be relevant.
I know
There are some notes on the Wiki:
http://hackage.haskell.org/trac/ghc/wiki/X86OSXGhc
that may be relevant.
I know there are problems with the Intel binary distribution for
OpenGL, but the PPC distribution should work...
Deborah
On Nov 15, 2006, at 6:39 PM, Melissa Chase wrote:
I
On Nov 15, 2006, at 6:14 AM, Christian Maeder wrote:
Gregory Wright schrieb:
/opt/local/lib/ghc-6.6/HSX11_cbits.o: unknown symbol `_printf
$LDBLStub'
I think I remember seeing something like this. I'll look into it
some
more.
That's a gcc problem. I think, HSX11_cbits.o should be built
This problem pops up sometimes for all sorts of open source software
(try Googling _printf$LDBLStub), and can be due to mixing modules
compiled by gcc 3.3 and gcc 4.0, and/or due to failure to link with -
lSystemStubs.
I've had good luck using X11 with GHC if I launch it first, and run
On Oct 30, 2006, at 2:40 PM, Deborah Goldsmith wrote:
I think I have this partially figured out.
The following patch to libraries/readline/configure.ac seems to do
the trick for Darwin:
--- configure.ac.save 2006-10-10 12:09:04.0 -0700
+++ configure.ac2006-11-02 17:32
On Oct 30, 2006, at 8:47 AM, Deborah Goldsmith wrote:
Since the files are not in the distribution itself, they can hardly
be installed. :-) It looks like the Mac OS X Intel distribution has
a problem. I'll check the PPC distribution later to see if it has
the same problem.
I checked
On Oct 23, 2006, at 8:59 AM, Björn Buckwalter wrote:
On 10/19/06, Simon Marlow [EMAIL PROTECTED] wrote:
See this page that I just created:
http://hackage.haskell.org/trac/ghc/wiki/Building/MacOSX
I tried these instructions, first by using my existing (darwinports)
readline in /opt/local,
I'm attempting to build frag on Mac OS X Intel with the 6.6
distribution, and I hit the following:
/tmp/ghc25850_0/ghc25850_0.hc:5:22:
error: HsOpenGL.h: No such file or directory
A comparison of the C include directories for 6.6 and a recent 6.5
build gives:
$ diff -r
On Oct 20, 2006, at 5:04 PM, Andy Adams-Moran wrote:
Just an update: I just added slides from Howard Mansell (Credit
Suisse)
and Rishiyur Nikhil (BlueSpec). That URL again is:
http://www.galois.com/cufp
The BlueSpec link is broken.
Thanks,
Deborah
On Oct 16, 2006, at 9:16 AM, Rodney D Price wrote:
bunzip2 ghc-6.6-i386-apple-darwin.tar.bz2
tar -xvf ghc-6.6-i386-apple-darwin.tar
These can be combined in one step:
tar -xfvj ghc-6.6-i386-apple-darwin.tar.bz2
Deborah
___
Glasgow-haskell-users
On Oct 13, 2006, at 6:23 PM, Adam Megacz wrote:
I'm grateful to whoever prepared the binary bundle for ghc-6.6 on
MacOS/Intel, but the instructions for installing it are missing/wrong.
In particular, make install doesn't do much, and the only binary in
the bundle called ghc appears to need
Hi,
I was able to build this release using the 20060915 Intel build
that's available, on 10.4.8. ghci seems to work OK (except for
Readline), but an attempt to compile gives:
$ ghc example25.hs
/usr/bin/ld: Undefined symbols:
_mtlzm1zi0_ControlziMonadziState_evalStateT_closure
Thanks, Spencer Janssen already set me straight. It was indeed the
lack of --package mtl. I'm pretty sure I didn't have that before, but
my memory could be faulty.
Thanks again,
Deborah
On Oct 9, 2006, at 5:57 PM, Ian Lynagh wrote:
On Mon, Oct 09, 2006 at 05:42:14PM -0700, Deborah
50 matches
Mail list logo
