On 16/09/2009 21:17, Florian Weimer wrote:
Are there any plans to get rid of hGetContents and the semi-closed
handle state for Haskell Prime?
(I call hGetContents unsafe because it adds side effects to pattern
matching, stricly speaking invalidating most of the transformations
which are
On 17/09/2009 13:58, Nicolas Pouillard wrote:
Excerpts from Florian Weimer's message of Wed Sep 16 22:17:08 +0200 2009:
Are there any plans to get rid of hGetContents and the semi-closed
handle state for Haskell Prime?
(I call hGetContents unsafe because it adds side effects to pattern
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
On 16/09/2009 15:06, Karel Gardas wrote:
Thanks to Christian note I solved the issue. Also thanks to Matthias'
advice I've been able to configure ghc to use GNU iconv in /usr/local,
but the result was still the same. I later used Christian advice to
force ghc not to use /usr/local's iconv and
On 17/09/2009 04:43, Norman Ramsey wrote:
While we're on this topic, I've had several requests to pull HOOPL
(the new dataflow optimization code) out as a library so that we can
make it into a Hackage package. I'd like to do this, but the
situation is complicated
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
On 12/09/2009 00:02, Norman Ramsey wrote:
Incedentally, the reason I'd like us to make a decision on this now is
because I'm about to add two new boot libraries...
While we're on this topic, I've had several requests to pull HOOPL
(the new dataflow optimization code) out as a library so
On 05/09/2009 17:38, Phil Dennis wrote:
Or... someone could put the URL back up as a redirect to the current
location of the documentation :)
Done.
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
Duncan Coutts wrote:
On Fri, 2009-08-28 at 11:42 +0100, Simon Marlow wrote:
Can anyone think of a good reason not to upgrade darcs to 2.3.0 on
darcs.haskell.org? I can think of 3 reasons to do so:
- this script, for preventing accidental divergence from upstream
- faster pushes, due
On 27/08/2009 11:37, Sittampalam, Ganesh wrote:
Simon Marlow wrote:
Simon Marlow wrote:
I suggest if we stick with the independent repo approach that we
have some automation to check that changes are indeed getting
pushed upstream.
[snip unhelpful suggestion from me]
Yes, it tells you
On 27/08/2009 11:25, José Pedro Magalhães wrote:
Hello,
On Wed, Aug 26, 2009 at 18:15, Simon Marlow marlo...@gmail.com
mailto:marlo...@gmail.com wrote:
* Boot libraries are of several kinds:
- INDEPENDENT: Independently maintained (e.g. time, haskeline)
- COUPLED: Tightly
On 28/08/2009 10:05, Simon Marlow wrote:
On 27/08/2009 11:37, Sittampalam, Ganesh wrote:
Simon Marlow wrote:
Simon Marlow wrote:
I suggest if we stick with the independent repo approach that we
have some automation to check that changes are indeed getting
pushed upstream.
[snip unhelpful
On 26/08/2009 22:32, Duncan Coutts wrote:
On Wed, 2009-08-26 at 17:15 +0100, Simon Marlow wrote:
* Sometimes we want to make local modifications to INDEPENDENT
libraries:
- when GHC adds a new warning, we need to fix instances of the
warning in the library to keep
On 27/08/2009 11:18, Sittampalam, Ganesh wrote:
Simon Marlow wrote:
I suggest if we stick with the independent repo approach that we have
some automation to check that changes are indeed getting pushed
upstream.
Agreed. Can you think of an easy way to automate it?
How about a cronjob
On 27/08/2009 00:55, Don Stewart wrote:
marlowsd:
Simon and I have been chatting about how we accommodate libraries in the
GHC repository. After previous discussion on this list, GHC has been
gradually migrating towards having snapshots of libraries kept as
tarballs in the repo (currently only
On 27/08/2009 11:24, Sittampalam, Ganesh wrote:
Simon Marlow wrote:
On 27/08/2009 11:18, Sittampalam, Ganesh wrote:
Simon Marlow wrote:
I suggest if we stick with the independent repo approach that we
have some automation to check that changes are indeed getting
pushed upstream.
Agreed
, shared by ghc and ghc-pkg).
I don't much like bin-package-db being a separate package, given that
it's only 100 lines or so in one module, but I don't see a good alternative.
Cheers,
Simon
On 26/08/2009 17:15, Simon Marlow wrote:
Simon and I have been chatting about how we accommodate
On 26/08/2009 11:05, David Duke wrote:
This didn't seem like a ghc bug per se, but am happy to put an entry
into trac if appropriate.
In playing with DPH, I've recently tried building the head code, using
Mac OSX 10.5.8 and ghc 6.10.4
After compiling and installing, I tried building an
Simon and I have been chatting about how we accommodate libraries in the
GHC repository. After previous discussion on this list, GHC has been
gradually migrating towards having snapshots of libraries kept as
tarballs in the repo (currently only time falls into this category),
but I don't
On 19/08/2009 10:15, Peter Hercek wrote:
Ian Lynagh wrote:
We are aiming to have the first release candidate out on the 14th
September 2009.
Until then, we plan to focus on the bugs in the 6.12.1 milestone, marked
high priority; they are listed here:
On 19/08/2009 00:15, Tim Chevalier wrote:
Hi,
Is there a way to tell the GHC build system that I only want to build
a stage 1 compiler and the libraries, not a stage 2 compiler?
Executing:
$ sh boot
$ ./configure
$ make stage=1
in my build tree still builds the stage 2 compiler as well.
I'm
On 19/08/2009 10:18, Peter Hercek wrote:
Hi,
I thought I may look at the :next command for GHCi debugger again. If I
do, I will not make it before 6.12.1 is out. I have few questions about
RTS in relation to :next implementation. If they is easy to answer I
would appreciate it, if not, don't
Levi Greenspan wrote:
Apologies for re-posting this subject here since I had sent already a
message to haskell-café 3 days ago, but I just learned about this
mailing list and it seems more appropriate to ask this question here I
guess. I already got a reply from Simon Marlow but I posted some
Bulat Ziganshin wrote:
Hello Levi,
Friday, August 7, 2009, 6:48:42 PM, you wrote:
1. How can one safely perform a blocking wait on a system call via
FFI when compiling with -threaded
i think you should use forkOS to create OS thread dedicated to Haskell
thread
Why do you recommend forkOS
.
-- Simon Marlow
It is perfectly possible to do real-time concurrent garbage collection
for Haskell, in an incremental fashion that guarantees a small maximum
bound on each packet of GC work. The tradeoff is that the percentage of
time devoted to GC in total is much greater, and the mutator
On 06/08/2009 17:42, Malcolm Wallace wrote:
What semantics would you like Haskell to have, in which (x `seq` y
`seq` e) and (y `seq` x `seq` e) are not equal?
I can easily imagine that (x `seq` y `seq` e) might have *two* semantic
denotations: bottom (Exception: stack overflow), and e. And I
On 06/08/2009 23:56, Peter Gammie wrote:
On 07/08/2009, at 12:00 AM, Simon Marlow wrote:
On 06/08/2009 14:20, Peter Gammie wrote:
On 06/08/2009, at 10:59 PM, Simon Marlow wrote:
On 06/08/2009 13:49, Thomas Davie wrote:
On 6 Aug 2009, at 14:37, Nils Anders Danielsson wrote:
On 2009-08-06
Dan Weston wrote:
foldl (+) 0 [1..1000] :: Integer
*** Exception: stack overflow
foldl' (+) 0 [1..1000] :: Integer
500500
I thought both of these were perfectly well defined in denotational
semantics (and equal to 500500). The first is
On 06/08/2009 08:22, Simon Peyton-Jones wrote:
| In the early to mid '90s we built various heap-profiling tools to
| examine the characteristics of heap data in lazy functional programs.
| You can find papers describing this work by Googling heap profiling.
| You may be particularly interested
On 06/08/2009 14:20, Peter Gammie wrote:
On 06/08/2009, at 10:59 PM, Simon Marlow wrote:
On 06/08/2009 13:49, Thomas Davie wrote:
On 6 Aug 2009, at 14:37, Nils Anders Danielsson wrote:
On 2009-08-06 11:08, Malcolm Wallace wrote:
yet, because of the definition of $!, this applies
On 06/08/2009 15:33, Malcolm Wallace wrote:
What semantics would you like Haskell to have, in which (x `seq` y
`seq` e) and (y `seq` x `seq` e) are not equal?
I can easily imagine that (x `seq` y `seq` e) might have *two* semantic
denotations: bottom (Exception: stack overflow), and e. And I
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 03/08/2009 15:54, Richard Kelsall wrote:
This page
http://www.haskell.org/ghc/documentation.html
has a link to the September 2001 (Draft for GHC 5.02) document
describing GHC Core (in what is for me user-hostile .ps.gz format.)
And this page
I suggest not using Haskell for your list. Put the data in a file and
read it at runtime, or put it in a static C array and link it in.
Cheers,
Simon
On 03/08/2009 22:09, Günther Schmidt wrote:
Hi Thomas,
yes, a source file with a single literal list with 85k elements.
Günther
On 04/08/2009 13:33, Sam Martin wrote:
Sounds like region inference to me.
(https://secure.wikimedia.org/wikipedia/en/wiki/Region_inference)
Thanks, yes, that's exactly what I had in mind.
Is anything like this is done in GHC?
Not at the moment, no.
Bear in mind that with generational GC,
On 02/08/2009 22:38, Niklas Broberg wrote:
I updated the code on the wiki page: the previous version didn't handle
prefix negation - did you implement that yourself in HLint?
No, I didn't implement prefix negation in HLint - it never came up as
an issue. Perhaps the underlying HSE library
On 01/08/2009 12:58, Simon Peyton-Jones wrote:
Personally I hate the fact that
f Z {x=3}
parses as
f (Z {a=3})
because even though (as Iavor says) there is only one function application
involved, it *looks* as if there are two.
Equally personally, I think that the presence or
I have fleshed out the report delta for
remove FixityResolution from the context-free grammar
http://hackage.haskell.org/trac/haskell-prime/wiki/FixityResolution
Please take a look and comment. This fixes a nasty bug in the Haskell
syntax - albeit one that doesn't cause problems in
On 31/07/2009 14:51, Neil Mitchell wrote:
Hi
remove FixityResolution from the context-free grammar
http://hackage.haskell.org/trac/haskell-prime/wiki/FixityResolution
Please take a look and comment. This fixes a nasty bug in the Haskell
syntax - albeit one that doesn't cause problems
On 24/07/2009 23:01, Justin Bailey wrote:
On Fri, Jul 24, 2009 at 2:51 PM, Don Stewartd...@galois.com wrote:
jgbailey:
On Fri, Jul 24, 2009 at 2:02 PM, Don Stewartd...@galois.com wrote:
Oh, and I note you're not using -O or -O2 either?
-- Don
This is a compile time problem, wouldn't -O
On 26/07/2009 21:09, Antoine Latter wrote:
Folks,
I was trying to see what GHC head was like, but I've run into a few
snags compiling packages.
My existing binary for cabal-install can install quite a few packages,
but then starts giving me strange errors eventually:
$ cabal --version
On 25/07/2009 16:28, Ian Lynagh wrote:
I've made a ticket and proposal page for removing the monomorphism
restriction:
http://hackage.haskell.org/trac/haskell-prime/ticket/131
http://hackage.haskell.org/trac/haskell-prime/wiki/NoMonomorphismRestriction
I think if we do this we really
On 25/07/2009 02:02, Ian Lynagh wrote:
Hi all,
I've made a ticket and proposal page for removing n+k patterns:
http://hackage.haskell.org/trac/haskell-prime/ticket/130
http://hackage.haskell.org/trac/haskell-prime/wiki/NoNPlusKPatterns
Should I have also added it to some index page
On 24/07/2009 05:17, leledumbo wrote:
OK, I've tried ghc's supplied gcc, too (not so easy, I need to set some
environment variables first) and here are the results:
With ghc's gcc:
D:/Sources/ghc/ghc-6.10.4/ghc/stage1-inplace/ghc.exe -package rts-1.0
-optc-O2 -
odir dist/build -c
On 22/07/2009 10:35, Christian Maeder wrote:
For sparc-solaris 10 I could not run the testsuite (with GNU Make 3.80)
What went wrong?
(Maybe someone can explain the bad testsuite results.)
Could you publish the results?
Cheers,
Simon
On 22/07/2009 10:35, Christian Maeder wrote:
(Maybe someone can explain the bad testsuite results.)
My comments begin with SDM: below:
= 2469(ghci)
cd ./ffi/should_run
'/export/local1/home/maeder/haskell/ghc-6.10.4/ghc/stage2-inplace/ghc'
-fforce-recomp -dcore-lint -dcmm-lint
On 24/07/2009 13:19, Christian Maeder wrote:
Simon Marlow wrote:
SDM: I'd guess your gmp.h is dropping definitions for some inline
functions into the code.
gmp for ghc was taking from the ghc-sources, but maybe my gcc uses
/usr/local/include/gmp.h nevertheless (because that's a system path
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
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 22/07/2009 05:10, leledumbo wrote:
I've just installed 6.10.4 and try to rebuild a minimal version from source,
but the rebuild process failed. It stops with message:
Capability.c: error converting to pointer type
on stage1.
configure command:
./configure --prefix=/c/ghc CFLAGS=-O4
On 16/07/2009 06:53, Kazu Yamamoto (山本和彦) wrote:
Hello,
Reduce this to 1024, otherwise the runtime will eventually find itself
dealing with file descriptors beyond the select() limit mentioned
above.
Someone with more knowledge of the Haskell runtime will have to advise
as to possible ways
On 14/07/2009 10:08, Dominic Steinitz wrote:
Trac doesn't seem to work for us so I'm sending this bug report by email.
What's the symptom?
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
On 15/07/2009 05:16, Brandon S. Allbery KF8NH wrote:
On Jul 14, 2009, at 21:48 , Kazu Yamamoto (山本和彦) wrote:
running well at the beginning. But after several hours, it receives an
error, buildFdSets: file descriptor out of range.
I believe the runtime uses select(), which has a hard limit
On 14/07/2009 15:04, Ian Lynagh wrote:
On Tue, Jul 14, 2009 at 07:48:36AM +0100, Sittampalam, Ganesh wrote:
I don't have any strong opinion about whether there should be a library
standard or not, but if there is a standard, how about putting the
entire thing (perhaps including the Prelude)
On 15/07/2009 15:47, Sittampalam, Ganesh wrote:
But there's a solution: we could remove the standard modules from
base, and have them only provided by haskell-std (since base will
just be a re-exporting layer on top of base-internals, this will be
easy to do). Most packages will then have
On 15/07/2009 15:54, Ian Lynagh wrote:
On Wed, Jul 15, 2009 at 03:39:55PM +0100, Simon Marlow wrote:
But there's a solution: we could remove the standard modules from
base, and have them only provided by haskell-std (since base will just
be a re-exporting layer on top of base-internals
Peter Hercek wrote:
Simon Marlow wrote:
On 10/07/2009 15:31, Peter Hercek wrote:
Hi,
It would be cool if ghci debugger could grab not only the free variables
in the selected expression but in one case a bit more. The case is when
we stop at a function definition the first time (when just
On 14/07/2009 08:58, Malcolm Wallace wrote:
left section right section prefix
unqualified (+ 1) (1 +) (+)
Haskell 98 (M.+ 1) (1 M.+) (M.+)
proposed (`M.(+)` 1) (1 `M.(+)`) M.(+)
or(*) (M.(+) 1) (flip M.(+) 1)
The last line is not correct. (M.(+) 1) captures the first argument of
the
On 10/07/2009 15:31, Peter Hercek wrote:
Hi,
It would be cool if ghci debugger could grab not only the free variables
in the selected expression but in one case a bit more. The case is when
we stop at a function definition the first time (when just entering it).
In this case it should provide
On 12/07/2009 16:49, Daniel Gorín wrote:
Hi
I'm trying to use the GHC API to have several instances of GHC's
interpreter loaded simultaneously; each with its own loaded modules,
etc. However, this doesn't seem to work well when two instances have
loaded modules with the same name. I'm including
On 12/07/2009 22:32, hask...@henning-thielemann.de wrote:
On Tue, 7 Jul 2009, hask...@henning-thielemann.de wrote:
I like to note that I'm against this proposal. The example given in
http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators
namely [Red..] can be easily resolved by
On 08/07/2009 22:45, Ian Lynagh wrote:
On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote:
1. Just drop the whole libraries section from the report. The
Report will still define the Prelude, however.
I'm tending towards (1), mainly because it provides a clean break
We still need owners for:
On 08/07/2009 10:07, Simon Marlow wrote:
Remove n+k patterns
NonDecreasingIndentation
Cheers,
Simon
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
On 08/07/2009 23:06, k...@cas.mcmaster.ca wrote:
Simon Marlow replied to Henning Thielemann:
Prelude.= just doesn't look like an infix operator. The point of
infix operators is that they are a lightweight notation, but they lose
that advantage when qualified. The qualified
On 09/07/2009 13:26, Bulat Ziganshin wrote:
Hello Simon,
Thursday, July 9, 2009, 3:46:31 PM, you wrote:
This would be a bold step, in that we would be effectively standardising
a lot more libraries than the current language standard. The base
package is a fairly random bag of library
On 08/07/2009 12:12, Andrea Vezzosi wrote:
the bug about ^C (http://hackage.haskell.org/trac/ghc/ticket/3317)
doesn't look fixed to me, on amd64 linux.
sai...@astarte:~/cabal$ ~/bin/ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.3.20090628
sai...@astarte:~/cabal$
On 07/07/2009 16:40, Claus Reinke wrote:
At last year's Haskell Symposium, it was announced that we would
change the Haskell Prime process to make it less monolithic. ..
In the coming weeks we'll be refining proposals in preparation for
Haskell 2010.
Given the incremental nature of the new
On 07/07/2009 16:58, hask...@henning-thielemann.de wrote:
Adding to an old thread:
http://www.haskell.org/pipermail/haskell-prime/2008-April/002441.html
I like to note that I'm against this proposal. The example given in
http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators
On 07/07/2009 20:17, Simon Peyton-Jones wrote:
| There are a couple sensible removals here. Do we also want to get rid
| of the useless class contexts on data-declarations? (that look like
| data Ord a = Set a = Set ...)
Yes! Yes! Kill them.
(In GHC's source code these contexts are
This is more of a consistency issue than anything else. We have to
decide what to do with the libraries in the Report.
Right now, the Haskell Report specifies 15 library modules. Things like
Maybe, Char, IO, Time, and Random. The situation is not ideal, for many
reasons:
- There are a
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
At last year's Haskell Symposium, it was announced that we would change
the Haskell Prime process to make it less monolithic. Since then,
everyone has been busy using Haskell (or implementing it), and we
haven't made much progress on the standardisation side of things. Well,
with ICFP and
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
The list of talks at the Haskell Implementers Workshop 2009 has now been
posted, and I think you'll agree we have an exciting lineup:
http://haskell.org/haskellwiki/HaskellImplementorsWorkshop
See you on 5 September!
Cheers,
Simon
___
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
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
On 28/06/2009 05:39, Conal Elliott wrote:
I'm getting panic! (the 'impossible' happened) / initC: srt_lbl in ghc
6.10.3. Does anyone have an educated guess about initC: srt_lbl ?
Oddly, ghci doesn't throw the panic.
When I comment out some GADT code, the panic goes away.
It's a pretty
On 24/06/2009 18:30, Brandon S. Allbery KF8NH wrote:
On Jun 24, 2009, at 05:04 , Simon Marlow wrote:
There's one exception: if GHC is forced to use blocking mode on a
particular FD, and you're using the non-threaded RTS, then a large
write using hPutBuf may block all Haskell threads
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
On 23/06/2009 22:28, Bulat Ziganshin wrote:
i have started http://haskell.org/haskellwiki/GHC/Memory_Management -
not much written yet
You could link to the recent paper about the parallel GC, it has plenty
of information about the architecture of the GC (not just relevant to
parallel GC):
On 24/06/2009 07:33, Brandon S. Allbery KF8NH wrote:
On Jun 24, 2009, at 02:27 , Sittampalam, Ganesh wrote:
Brandon S. Allbery KF8NH wrote:
Sure - but it hurts more when in some environments you get away with
it and others you don't.
You'll still have that though, it'll just be a different
On 20/06/2009 21:46, Ganesh Sittampalam wrote:
I recently spent a while debugging a problem where a program deadlocked
in the non-threaded runtime, but ran fine in the threaded runtime,
despite the program having no blocking FFI calls, and boiled it down to
the following test case:
module
On 17/06/2009 10:14, Peter Hercek wrote:
Hi GHC and VI users,
I got frustrated with vi tags not working after some unrelated code is
edited in a source file. Moreover non-exported top level declarations
were not available in vi tags file. Here is an attempt to fix it:
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 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 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 13/06/2009 17:21, Corey O'Connor wrote:
On Sat, Jun 6, 2009 at 2:09 PM, Corey O'Connorcoreyocon...@gmail.com wrote:
I'm running a webserver built using salvia [1] and GHC 6.10 [2]. I've
trimmed down the code enough such that there is no obvious source of a
deadlock in either salvia or the
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 08/06/2009 10:16, Christian Maeder wrote:
When building ghc-6.10.3 I've noticed again:
1. ghc-pkg check:
There are problems in package rts-1.0:
include-dirs: PAPI_INCLUDE_DIR doesn't exist or isn't a directory
Ian, could you merge this patch please?
Thu Apr 2 11:55:40 BST 2009 Simon
Claus Reinke wrote:
Perhaps I've been misunderstanding what you mean by lexical stack?
lexical to me implies only scope information, nothing related to run
time call chains, which would be dynamic. In the dynamic case, one
can then distinguish between call-by-need stack (what actually happens
901 - 1000 of 5259 matches
Mail list logo
