On 06/01/2011 05:44, Mark Lentczner wrote:
On Jan 4, 2011, at 5:41 PM, Antoine Latter wrote:
Are you thinking that the BOM should be automatically stripped
from UTF8 text at some low level, if present?
It should not. Wether or not a U+FFEF can be stripped depends on
context in which it is
On 15/01/11 15:26, Claus Reinke wrote:
Earlier today I was trying to set up a Windows build bot for the
'network' package. That turned out to be quite difficult. Too much
playing with PATHs, different gcc versions, etc. Does anyone have a
repeatable, step-by-step process to install GHC and get a
On 05/05/2009 20:42, Tobias Olausson wrote:
This simple implementation of CPU does not behave as expected in the
latest version of ghc using ST.Lazy since it updates the `pc` in the
wrong order.
When we use ghc-6.8 the code works as expected both with lazy and strict ST.
How is that? How do we
On 06/05/2009 07:31, Luke Palmer wrote:
On Wed, May 6, 2009 at 12:07 AM, Rouan van Dalen rvda...@yahoo.co.uk
mailto:rvda...@yahoo.co.uk wrote:
Hi everyone.
I am designing my own programming language.
I would like to know what is the best way to go about writing my
compiler in
On 06/05/2009 21:18, Bulat Ziganshin wrote:
Hello FFT,
Wednesday, May 6, 2009, 11:59:53 PM, you wrote:
I've heard it's hard to contain a long-running Haskell application in
a finite amount of memory
not exactly. you may alloc fixed pool of memory to application (say, 1gb)
if you know that
On 07/05/2009 11:51, Bulat Ziganshin wrote:
Hello Simon,
Thursday, May 7, 2009, 2:04:05 PM, you wrote:
I've heard it's hard to contain a long-running Haskell application in
a finite amount of memory
not exactly. you may alloc fixed pool of memory to application (say, 1gb)
if you know that it
On 07/05/2009 15:17, Bulat Ziganshin wrote:
Hello Simon,
Thursday, May 7, 2009, 5:45:53 PM, you wrote:
out of date and say 256k, I've just fixed that). The old generation is
allowed to grow to 2x its previous size by default before being
collected.
you are right. i just checked old logs -
On 12/05/2009 08:04, Dušan Kolář wrote:
I'm sorry for the OT post, is the conference dead? I've got no mail
since yeasterday afternoon. And that is quite unusual.
We had a full disk on haskell.org over the weekend. We freed up some
space yesterday, but it seems the lists were still stuck.
On 13/05/2009 19:53, Donnie Jones wrote:
Hello Dan,
Best place to ask is glasgow-haskell-us...@haskell.org since that is
the GHC users list.
I have CC'd your email to the GHC user list.
Cheers.
--
Donnie Jones
On Wed, May 13, 2009 at 1:35 PM, Dandanielkc...@gmail.com wrote:
Hi,
Not sure if
On 13/05/2009 13:07, Duncan Coutts wrote:
On Wed, 2009-05-13 at 15:37 +0400, Bulat Ziganshin wrote:
Hello Duncan,
Wednesday, May 13, 2009, 3:33:13 PM, you wrote:
I think it should remain deprecated and we should work on the
replacement so that TH can switch its dependency.
TH isn't
On 27/05/2009 22:02, Henning Thielemann wrote:
My proposal is thus: Discourage orphan instances! If you encounter that
an instance is missing and it is a canonical one, it should be added to
the package that defines the type or the class. If there are several
choices for the implementation then
On 12/06/2009 08:00, Michael Vanier wrote:
I've been trying to build ghc head from the darcs repo using these
instructions:
http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources
Unfortunately, when I do
./darcs-all --extra get
as described under Getting more packages it fails
On 08/06/2009 22:10, Maurício wrote:
This comes from an issue in haskell-beginner, (...)
For better or worse, this is something that people should not be
trying in the first place, (...)
Sure! That's what I sugested in the original question. I'm actually
just curious on why timer_create is
On 11/06/2009 05:40, Evan Klitzke wrote:
I've written a multi-threaded Haskell program that I'm trying to
debug. Basically what's happening is the program runs for a while, and
then at some point one of the threads goes crazy and spins the CPU
while allocating memory; this proceeds until the
On 14/06/2009 05:56, Judah Jacobson wrote:
On Sat, Jun 13, 2009 at 8:41 PM, Shu-yu Guos...@rfrn.org wrote:
Hello all,
It seems like getDirectoryContents applies codepage conversion based
on the default program locale under Windows. What this means is that
if my default codepage is some kind
On 16/06/2009 12:42, Bulat Ziganshin wrote:
Hello Simon,
Tuesday, June 16, 2009, 3:30:31 PM, you wrote:
Care to submit a patch to put this in System.Directory, or better still
put the relevant functionality in System.Win32 and use it in
System.Directory?
Simon, it will somewhat broke
On 16/06/2009 13:46, Yitzchak Gale wrote:
Simon Marlow wrote:
Care to submit a patch to put this in System.Directory, or better still
put the relevant functionality in System.Win32 and use it in
System.Directory?
Bulat Ziganshin wrote:
now getDirectoryContents return ACP (ansi code page
On 16/06/2009 16:44, Bulat Ziganshin wrote:
Hello Simon,
Tuesday, June 16, 2009, 7:30:55 PM, you wrote:
Actually we use a mixture of CRT functions and native Windows API,
gradually moving in the direction of the latter.
so file-related APIs are already unpredictable, and will remain in
this
On 16/06/2009 21:19, Bulat Ziganshin wrote:
Hello Simon,
Tuesday, June 16, 2009, 5:02:43 PM, you wrote:
I don't know how getArgs fits in here - should we be decoding argv using
the ACP?
myGetArgs = do
alloca $ \p_argc - do
p_argv_w- commandLineToArgvW getCommandLineW p_argc
On 16/06/2009 17:06, Bulat Ziganshin wrote:
Hello Simon,
Tuesday, June 16, 2009, 7:54:02 PM, you wrote:
In fact there's not a lot left to convert in System.Directory, as you'll
see if you look at the code. Feel like helping?
these functions used there are ACP-only:
c_stat c_chmod
On 17/06/2009 09:38, Bulat Ziganshin wrote:
Hello Simon,
Wednesday, June 17, 2009, 11:55:15 AM, you wrote:
Right, so getArgs is already fine.
it's what i've found in Jun15 sources:
#ifdef __GLASGOW_HASKELL__
getArgs :: IO [String]
getArgs =
alloca $ \ p_argc -
alloca $ \ p_argv - do
On 17/06/2009 13:21, Yitzchak Gale wrote:
I wrote:
I think the most important use cases that should not break are:
o open/read/write a FilePath from getArgs
o open/read/write a FilePath from getDirectoryContents
Simon Marlow wrote:
The following cases are currently broken:
* Calling
On 17/06/2009 15:03, Yitzchak Gale wrote:
Simon Marlow wrote:
The following cases are currently broken...
I propose to fix these (on Windows). It will mean that your second case
above will be broken, until someone fixes getDirectoryContents...
...it's a lot easier on Windows...
on Unix I
On 16/06/2009 21:19, Bulat Ziganshin wrote:
Hello Simon,
Tuesday, June 16, 2009, 5:02:43 PM, you wrote:
I don't know how getArgs fits in here - should we be decoding argv using
the ACP?
myGetArgs = do
alloca $ \p_argc - do
p_argv_w- commandLineToArgvW getCommandLineW p_argc
help
i agree that this looks like a deficiency of memory allocator. it's
better to write at ghc-users maillist (or at least make a copy to
Simon Marlow) to attract attention to your message
Maybe bzlib allocates using malloc()? That would not be tracked by
GHC's memory management, but could
Hi Folks,
As usual, we're planning a major release of GHC around September.
Here's our list of the main items currently scheduled for 6.12.1, and
their status. If you have the time and inclination to help with any of
these, please get involved!
* Parallel performance. 6.12.1 will ship
Karmic (9.10) will have GHC 6.10.3, possibly 6.10.4.
http://bugs.launchpad.net/ubuntu/+source/ghc6/+bug/302149
Cheers,
Simon
On 06/07/2009 23:54, Stefan Roggensack wrote:
Hello,
I have uploaded the ghc package to my ppa:
https://launchpad.net/~someone561/+archive/ppa
But I don't work
On 08/07/2009 00:17, George Pollard wrote:
2009/7/7 Matthias Görgensmatthias.goerg...@googlemail.com:
Karmic (9.10) will have GHC 6.10.3, possibly 6.10.4.
It currently spots 6.10.3, in the alpha release I run here.
A major problem is that the libraries are still for 6.8.2, so you
cannot
On 22/07/2009 02:51, Neal Alexander wrote:
Neal Alexander wrote:
Compiled with ghc -O2 -fvia-C -optc-O2 -funbox-strict-fields
-threaded btw.
GHC 6.10.3 on 64bit windows7.
Interesting. It's completely flat on Linux, but gobbles up about 1MB/s
on Windows. I'm investigating.
Cheers,
On 12/07/2009 19:26, Bulat Ziganshin wrote:
Hello Maurício,
Sunday, July 12, 2009, 9:11:53 PM, you wrote:
I did read that. It says I can use #def to insert
a C definition, but there are no examples of use, and I
could not find one.
#def inline int signof(int x) {return x0?-1:x0?1:0;}
On 23/07/2009 11:53, Simon Marlow wrote:
On 22/07/2009 02:51, Neal Alexander wrote:
Neal Alexander wrote:
Compiled with ghc -O2 -fvia-C -optc-O2 -funbox-strict-fields
-threaded btw.
GHC 6.10.3 on 64bit windows7.
Interesting. It's completely flat on Linux, but gobbles up about 1MB/s
The SIGVTALRM signal is delivered to one (random) thread in the program,
so I imagine it just isn't being delivered to the thread that runs your
second call to sleep. (the main Haskell thread is a bound thread and
hence gets an OS thread to itself).
Is there some reason you can't use
On 13/09/2009 07:45, Belka wrote:
Hello, Haskell Cafe!
I used an MVar to signalize to many threads, when it's time to finish their
business (I called it a LoopBreaker). Recently I realized, that it might be
too expensive (to use MVar) for cases when threads are many and all of them
read my
Brandon S. Allbery KF8NH wrote:
On Sep 19, 2009, at 07:45 , Duncan Coutts wrote:
On Thu, 2009-09-17 at 11:58 +0200, Marcus D. Gabriel wrote:
-- | 'reduceFilePath' returns a pathname that is reduced to canonical
-- form equivalent to that of ksh(1), that is, symbolic link names are
-- treated
Braden Shepherdson wrote:
So, assuming some GHC dev doesn't swoop down and fix this, what options
are left to the project in the short term?
An unregisterised build of an old 6.6 should work, that would get us a
working, though aging, GHC. Unfortunately a lot of the porting work to
move
Joe Buehler wrote:
Simon Marlow wrote:
For the registerised port, you really need a native code generator
(the mangler is on death row, yay). At a rough guess, I'd say porting
the NCG would take a couple of weeks or so for someone unfamiliar with
the code. Hopefully we'll improve that when
scodil wrote:
I'll chime in with a me too. I use Haskell and OpenGL for prototyping
scientific visualization software, 3D models and such. Not that I think it
couldn't be used for production software, its just that I just don't produce
much :)
The library really is fantastic. I don't think it
On 2008.08.04 20:47:12 +0200, Christian Maeder [EMAIL PROTECTED]
scribbled 1.1K characters:
Right,
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Cabal-1.4.0.1
works.
It seems that the dependencies for ghc-paths could be improved.
Thanks Christian
Yes, I emailed
On 2008.08.04 20:47:12 +0200, Christian Maeder
[EMAIL PROTECTED]
scribbled 1.1K characters:
Right,
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Cabal-
1.4.0.1
works.
It seems that the dependencies for ghc-paths could be improved.
Thanks Christian
Yes, I
Evan Laforge wrote:
I've been getting a mysterious error for a while now. It's come and
gone, but seems to be showing up slightly more consistently now.
Before I was on ghc 6.8.2 and now I'm on ghc 6.8.3, OS X 10.4 and now
10.5, i386 arch. The problem is that randomly while compiling I get
an
Bruce Eckel wrote:
So this is the kind of problem I keep running into. There will seem to
be consensus that you can do everything with isolated processes message
passing (and note here that I include Actors in this scenario even if
their mechanism is more complex). And then someone will pipe
Lev Walkin wrote:
I wondered why would a contemporary GHC 6.8.3 exhibit such a leak?
After all, the technique was known in 2000 (and afir by Wadler in '87)
and one would assume Joe English's reference to most other Haskell
systems ought to mean GHC.
Thanks for this nice example - Don Stewart
Jonathan Cast wrote:
On Wed, 2008-09-17 at 13:44 -0700, Evan Laforge wrote:
systems that don't use an existing user-space thread library (such as
Concurrent Haskell or libthread [1]) emulate user-space threads by
keeping a pool of processors and re-using them (e.g., IIUC Apache does
this).
Chris Kuklewicz wrote:
I am cross-posting this message to several lists.
I had learned the trick before the documentation was updated. It seems
I have used a very unreliable trick. And the use castToSTUArray
suggested alternative is a really poor one since I am not using arrays
at all.
Manlio Perillo wrote:
Don Stewart ha scritto:
[...]
Ok. So I'll just say: high level, efficient code is an overriding theme
of many individuals working on Haskell. Things are better and better
each year. We do not stand still.
Any roadmap for improve support in intensive IO multiplexing?
Or,
Andrew Coppin wrote:
Andrew Coppin wrote:
OK, so a GHC question: Apparently at some point, GHC used to support
DLLs. And then it stopped working. And then it may or may not have
been brought back again... Does anybody know exactly what the status
of this is? Is it currently working or broken?
Magnus Therning wrote:
I've heard that the OCaml crowd uses a modified LGPL with a static
linking exception. Unfortunately I've also heard that their addition
to LGPL hasn't gotten much review by lawyers, I'd much rather use
something that feels less ad hoc, if you get what I mean.
Any
Manlio Perillo wrote:
Simon Marlow ha scritto:
Manlio Perillo wrote:
[...]
We'd certainly support any efforts to add support for a more modern
I/O multiplexing or asynchronous I/O back-end to the IO library. It's
not too difficult, because the interface between the low-level I/O
supplier
Andrew Coppin wrote:
(1) is not of huge interest to me, but it's pleasing to know that it's
possible. (I don't actually know how DLLs work, but presumably if I were
to dig around in System.Win32 I could also call normal DLLs from Haskell
too if I desire...?)
Sure, that's possible.
(2) is
Magnus Therning wrote:
Wolfgang Jeltsch wrote:
Am Freitag, 26. September 2008 09:24 schrieb Magnus Therning:
Recently I received an email with a question regarding the licensing
of a module I've written and uploaded to Hackage. I released it under
LGPL. The sender wondered if I would
brian wrote:
On Tue, Sep 30, 2008 at 8:54 PM, Stefan Monnier
[EMAIL PROTECTED] wrote:
That still leaves anyone free to use LGPL if they want to, but please
don't assume that it allows commercial use by all potential users.
It *does* allow commercial use. Your example just shows that some
Andrew Coppin wrote:
Anyway, the point I'm trying to get to is... would it be hard for
however maintains this library to add a little more flexibility in what
it can do please?
In the new System.Process, that comes with GHC 6.10.1:
Prelude System.Process createProcess (shell echo $FOO){ env
Magnus Therning wrote:
On Wed, Oct 1, 2008 at 6:03 PM, Simon Marlow [EMAIL PROTECTED] wrote:
[..]
Dynamic linking doesn't solve all the problems, we still have the problem
that GHC does a lot of cross-module inlining, regardless of whether dynamic
linking is used. However, I really would like
Magnus Therning wrote:
On Fri, Oct 3, 2008 at 12:59 PM, Simon Marlow [EMAIL PROTECTED] wrote:
Magnus Therning wrote:
On Wed, Oct 1, 2008 at 6:03 PM, Simon Marlow [EMAIL PROTECTED]
wrote:
[..]
Dynamic linking doesn't solve all the problems, we still have the problem
that GHC does a lot
john lask wrote:
Something that has irked me in the past about System.Process is the inability
to obtain an OS system handle from the haskell Process handle. Such a facility
would greatly enhance the interoperabity of c and haskell libraries.
Provision is made (although not standardised) to
Antoine Latter wrote:
Folks,
I'm not sure who to email about this, but hopefully someone on the cafe knows:
On the machine which builds the Hackage packages the 'binary' package
is built against 'bytestring-0.9.1.2', however the package I just
uploaded gets built against 'bytestring-0.9.1.3'
Don Stewart wrote:
Note that these builds are with soft deps, provided on hackage,
base 4
parsec 3
HaXml == 1.13.*
QuickCheck 2
which train cabal-install to build a larger set of packages.
Will this happen automatically somehow, or will users have to do this manually?
Magicloud wrote:
1. I cannot install ghc-6.8.3 in my box until I found the old runable
binary.
2. After I installed cabal, and upgraded, ghc-6.8.3 cannot rebuild
itself. Because its libraries are conflict with the ones upgraded by cabal.
3. Sometimes, ghc just ignore some libs, because it does
wren ng thornton wrote:
Simon Marlow wrote:
Don Stewart wrote:
* GHC.Prim was moved,
Nobody should be importing GHC.Prim, use GHC.Exts instead.
This is oft declared, but as things stand I don't think it's a tenable
position. If someone's bothering to dig as far as GHC.Exts then it's
Don Stewart wrote:
mjm2002:
On 10/13/08, Andrew Coppin wrote:
Cool. Is there any progress on getting GHC to *not* freak out when you
ask it to compile a CAF containing several hundred KB of string literal? :-}
Yes and no. There's dons' compiled-constants pkg which has a solution:
Stephen Hicks wrote:
I've been trying out the new System.Process and have found it to be
very useful. I was wondering what the plans for it were - I'd rather
not give up support for older versions of ghc just because I want to
use createProcess. Are there plans of releasing process-1.0.1 so
[EMAIL PROTECTED] wrote:
I'd like to point out a reliable, proven and simple way of interacting
with another process, via unidirectional or bidirectional pipes. The
method supports Unix sockets, pipes, and TCP sockets.
I too have noticed insidious bugs in GHC run-time when communicating
with
Rafal Kolanski wrote:
Bryan O'Sullivan wrote:
What is the it that segfaults? The Haskell program shouldn't, at least.
The Haskell program. It does so rarely, however, and I'm unable to
reproduce it with any consistency, only enough to notice something is
wrong with what I've written.
Upon
Bulat Ziganshin wrote:
Hello Chad,
Wednesday, November 5, 2008, 6:34:01 AM, you wrote:
ghc --make -j4 Foo.hs
afair, it was implemented and not shown speed improvements. ask Simon
We did get speed improvements, it was the main case study for the initial
implementation of shared-memory
discuss this with Simon Marlow, as it was his idea. Thomas
Schilling implemented it. Personally, I think the frames are quite
handy, although not that pretty in their current form. More
importantly, you don't need to use them if you don't want to. Haddock
still generates the normal index.html as well
Don Stewart wrote:
Which version of GHC are you using?
This particular example triggers a boundary condition in ghc 6.10
where, with only one spark, GHC doesn't fire up the extra cpu. Try it
with 6.8.x to see that in action.
Simon Marlow may be able to comment more.
Yes, it's a scheduling
Don Stewart wrote:
olivier.boudry:
On Tue, Nov 25, 2008 at 3:07 PM, Simon Marlow [EMAIL PROTECTED] wrote:
Yes, it's a scheduling bug. I'll make sure it gets fixed for 6.10.2. If
you have more sparks then you shouldn't see this problem. Also, GHC HEAD is
quite a lot better with parallel
Brandon S. Allbery KF8NH wrote:
On 2008 Nov 10, at 19:04, Jason Dusek wrote:
simple exe bytes args= do
(i, o, e, p)- runInteractiveProcess exe args Nothing
Nothing
hPut i bytes
s - hGetContents o
hClose i
return s
Yep, that's your problem.
Claus Reinke wrote:
Do you have an example of a mutable state/ IO bound application, like,
hmm, a window manager or a revision control system or a file system...?
If you're looking for a challenge, how about this one (there used to
be lots of Haskellers into this game, any of you still
Manuel M T Chakravarty wrote:
Claus Reinke:
What do those folks working on parallel Haskell arrays think about the
sequential Haskell array baseline performance?
You won't like the answer. We are not happy with the existing array
infrastructure and hence have our own. Roman recently
Donn Cave wrote:
Quoth Duncan Coutts [EMAIL PROTECTED]:
| On Thu, 2008-11-27 at 11:38 -0500, Brandon S. Allbery KF8NH wrote:
|
| The way this is usually handled in the non-threaded case is to either
| use SIGCHLD or non-blocking waitpid() so that green threads can
| continue running. I'm a
Mitchell, Neil wrote:
Hi
I have the same experience with Windows XP and getContents, so I think
it's the entire IO layer on Windows, rather than just getLine on Vista.
This is being tracked here
http://hackage.haskell.org/trac/ghc/ticket/2758
Which is now fixed, FYI. 6.10.2 will have the
Bartosz Wójcik wrote:
Hi Folks,
I'm facing problem after I've reinstalled directory-1.0.0.0 (setup
configure/build/install). Since then I cannot complie anything that needs
this library. It fails with following messages:
Preprocessing library haddock-2.4.0...
Preprocessing executables for
John Meacham wrote:
On Tue, Nov 25, 2008 at 09:39:35PM +0100, Ketil Malde wrote:
This corresponds to my experiences - 64 bits is slower, something I've
ascribed to the cost of increased pointer size.
ghc unfortunatly also uses 64 bit integers when in 64 bit mode, so the
cost paid is increased
John Meacham wrote:
GHC has 'pinned arrays' that have this behavior. however, you probably
don't want to use them as they simply give the garbage collector less
choices about what to do possibly decreasing its efficiency. The garbage
collector already is free to not copy arrays if it feels it
Gwern Branwen wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
So, the Hint library was recently updated and I was editing Mueval to
run with (i386) 6.10, when I discovered that for some reason, DoS'ing
expressions were succeeding in rendering my machine unusable.
Eventually, I discovered
Gwern Branwen wrote:
On Mon, Dec 15, 2008 at 9:00 AM, Simon Marlow wrote:
This particular example illustrates a bug in 6.10.1 that we've since fixed:
http://hackage.haskell.org/trac/ghc/ticket/2783
OK, that's good...
However in general you can still write expressions that don't allocate
Jeremy Shaw wrote:
I have the following simple program:
import Control.Concurrent
main = threadDelay (10^6) main
If I run it in GHCi it requires 2-5% of my CPU. If i compile it, it
takes 0% of my CPU. It does not matter if I compile -O0, -O2,
-threaded, it always uses 0% (which is good).
Is
Jake Foell wrote:
using ghc v6.8.2
Problem:
I am creating a program that forks two other lightweight threads. One
of the forked threads seems to be stuck or dead after running
successfully for a non-trivial amount of time. I am receiving no
error messages.
Questions:
What is the best way to
Sounds like you should use an exception handler so that when the parent
dies it also kills its children. Be very careful with race conditions ;-)
For a good example of how to do this sort of thing, see
http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-Timeout.html
the docs
Duncan Coutts wrote:
On Fri, 2008-12-19 at 10:42 -0600, Jake McArthur wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Keir wrote:
fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
This is a CAF (Constant Applicative Form). Since it is actually a
constant it is never garbage collected,
How about this slightly more general interface, which works
with the new
FFI libraries, and is trivial to implement on top of the
primitives in
GHC's IOExts:
hPut :: Storable a = Handle - a - IO ()
hGet :: Storable a = Handle - IO a
What about endianess? In
Simon Marlow wrote:
Well, simply extending the Haskell syntax to allow
\ p11 .. p1n - e1
..
pm1 .. pmn - em
(with appropriate layout) should be ok, but I haven't tried
it. Guarded
right-hand-sides could be allowed too.
Introducing layout after
Chris Webb writes:
For simple networking, I usually find that the simple Socket interface
from hslibs does everything I need, except that I always need
to import
sClose from SocketPrim as well, so I can close the sockets I open.
Tidying up some old code this morning, I was wondering: is the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tuesday 13 November 2001 06:18, Manuel M. T. Chakravarty wrote:
The time consuming part in creating such a system are the C
bindings, not the XML stuff. In fact, similar functionality
is available for GTK+ already for a long while.
On Fri, Nov 23, 2001 at 09:38:35AM -, Simon Marlow wrote:
[...]
However, I agree that sometimes you really want to be able
to do this,
so perhaps we need another form of 'block' which doesn't allow *any*
exceptions to be delivered, for those times when you know
that the time
Any thumb rule for using arrays? I'm expecting access to be
O(1), it is right?
In GHC, yes.
Need to have a set of data, and I just want to get random
elements from that
Set, arrays seem like a good solution... am I right?
If you're building it once and doing lots of access, then
Simon Marlow [EMAIL PROTECTED] writes:
Any thumb rule for using arrays? I'm expecting access to be
O(1), it is right?
In GHC, yes.
(Shouldn't this really be required? I mean, the whole
*point* of using
arrays is to have O(1) random access, isn't it?)
Can we also rely
itz All this taken together, I mean, _really_, is the lexical
itz structure of Haskell a botch, or what?
Jon No. Innovative. All the problems described in this thread reflect
Jon unwarranted assumptions inherited in emacs. It's plainly possible
Jon to parse Haskell, and not hard either.
How should I modify the function below so that characters
are printed
out as they arrive?
printchar :: Handle - IO ()
printchar handle = do c - hGetChar handle
putChar c
Try using
hSetBuffering handle NoBuffering
hSetBuffering stdout
Does anybody with their elbows in the
code think variable interpolation and/or
multi-line strings are good/doable ideas?
Would this be the sort of change one could make
without a lot of previous familiarity with
the implementation of Hugs/Ghc?
It would be a *signifigant* boon to those
of
I was not suggesting that the Haskell'98 report should
change or even give a warning -- I was giving a warning to
compiler implementors, that this simple change might have
disastrous effects.
BTW, I remember a similar discussion along these lines on
the Haskell mailing list that happened
Is there some reason haskell binaries have to be statically linked?
I can't seem to find a way to make them otherwise, at least with
ghc.
The ELF dynamic linking format seems to be designed on the assumption
of poor code reuse (e.g., C code) where calls from one module to
another are
Can one write withthe Haskell compliler faster code than in
the examples of http://www.bagley.org/~doug/shootout/ where
GHC (old Haskell 98?) seems to be much slower than Ocaml or
Mlton both strict functional languages.
Can one expect any improvements in speed in the future?
Many of
At 2002-08-09 03:26, Simon Marlow wrote:
Why combine I/O and {en,de}coding? Firstly, efficiency.
Hmm... surely the encoding functions can be defined efficiently?
decodeISO88591 :: [Word8] - [Char];
encodeISO88591 :: [Char] - [Word8]; -- uses low octet of
codepoint
You
I've come up with three different methods of approach to
solve the same
problem in haskell. I would like to compare the three in
terms of reductions,
memory usage, and overall big O complexity.
What's the quickest way to gather these stats? I usually use the ghc
compiler, but also
[ off-topic ]
I'm sorry to bring up such petty issues, but this has been nagging me
for quite a long while now...
The Haskell mailing lists have one rather unflattering characteristic:
their mail threads are almost always broken.
[... snip ...]
X-Mimeole: Produced By Microsoft Exchange
Here what the User's Guide says:
Functional dependencies are implemented as described by
Mark Jones in
Type Classes with Functional Dependencies, Mark P. Jones,
In Proceedings
of the 9th European Symposium on Programming, ESOP 2000,
Berlin, Germany,
March 2000,
I had the same problem, and I found a fix somewhere.
Don't reember what exactly I had to change so I'll just send
you my Haskell section of xemacs init.el.
By the way I get an error whenever I type undefined. Anyone
else noticed it?
(1) (error/warning) Error in `post-command-hook'
How does the ghc run-time system determine if an operation is
interruptible
when within block function scope? Explanations I've read in various
papers/web pages state that an operation is interruptible,
even within a the
scope of the block function, if that operation can potentially block
501 - 600 of 856 matches
Mail list logo
