Would it be possible to implement an operation to lock an MVar without
any extra expense? So that the thread owning the MVar can do things to
it, but no other thread can. If it is possible, I suggest that it be
added and it would solve Marcin's problem (isEmptyMVar would then suffice).
This is a trivial problem of no importance I know, but . . .
How do I write parallel or in Concurrent Haskell, without using unsafe
features? So I want a function
por :: a -> a -> a
which takes two (presumably unevaluated) parameters and evaluates them
concurrently and returns if either of th
Simon Peyton-Jones wrote:
>
> Try it now with -fddump-minimal-imports
>
> I don't promise it'll work, but it does in simple cases.
> It produces a file M.imports
Brilliant, thanks. I'll try it out (indeed probably use it) when I next manage
to compile GHC from CVS.
At the moment UniForM contains great swathes of imported modules, which is
untidy and makes the interfaces too large. Would it perchance be easy to
hack GHC to output the names and provenances of imported entities actually
used in a compilation, in the form of import declarations that can be subs
(Sent to glasgow-haskell-users rather than haskell, as it is GHC-specific.)
If we were writing a C library rather than a Haskell library, we could make
"head" a macro which included an appropriate message referring to __FILE__
and __LINE__. The equivalent in Glasgow Haskell would be to make head
How should I detect if a file is a symbolic link in Posix? If I were writing
C, I could do it by lstat'ing, looking at the
mode_t value in the result, and comparing it with S_IFLNK. Or at
least I could on Sparc/Solaris. But the Posix encapsulation doesn't
provide a FileMode value corresponding
When I asked on the mailing list about this a year ago, I think I was told
that it wasn't exactly supported any longer. So rather than trying to get
GHC to compile ReadLine in, I used green-card instead. The attached file gives
you the very simplest readline function.
If you want to try to get
Simon Peyton-Jones wrote:
>
> | At the time of writing, I am waiting for yet another long
> | Haskell re-make of
> | lots of modules to complete. The frustrating thing is, that
> | at least 90% of these
> | remakes are actually completely unnecessary.
>
> OK, I have heard your cries, and have f
Volker Stolz wrote:
>
> Should getEnvVar just be overloaded in Posix.lhs or should the whole thing
> (System & PosixProcPrim) be changed?
> --
> Volker Stolz * [EMAIL PROTECTED] * PGP
I was hoping that we wouldn't have any incompatible changes . . .
I think ideally that getEnv like functions sho
Two further comments on RegexString:
(1) I actually have to use Ian Jackson's excellent
matchRegexAll
function to do what I want. If this were documented and supported
I would appreciate it.
(2) While I can live without the facility (I think) it would nevertheless
be nice to b
Simon Marlow wrote:
> You're suggesting removing this function? Again, I've no objection (because
> I don't use it :-) but it's harder to make a case for removing something
> from a library. In this case, recvFrom is the dual of sendTo, so it at
> least looks consistent. I agree it's hard to i
I'm worried that Regex might be obsolescent. If I change to RegexString, can
I be sure that it's going to stay and be supported for the next two years?
Simon Peyton-Jones wrote:
>
> | But Haskell *really* needs some standard way of reading values in the
> | native format on a platform:
>
> What about this specification?
It looks too slow and inflexible to me. If I just want to get at the
byte representation of a Float, I have to create a whole
Simon Marlow wrote:
>
> Sparc users in particular: I've identified some recent breakage in the
> Sparc port of GHC. If you've been experiencing crashes in binaries
> generated by a compiler built from recent (at least February) sources, then
> I've checked in a fix which might help.
>
> George
Simon Marlow wrote:
>
> Sparc users in particular: I've identified some recent breakage in the
> Sparc port of GHC. If you've been experiencing crashes in binaries
> generated by a compiler built from recent (at least February) sources, then
> I've checked in a fix which might help.
>
> George
Marc van Dongen wrote:
>
> Hello there,
>
> When doing cvs updates I get a lot of errors of the form
>
> patch: Invalid options.
> patch: Usage: patch [-blNR] [-c|-e|-n] [-d dir] [-D define] [-i patchfile]\
> [-o outfile] [-p num] [-r rejectfile] [file]
> cvs update: could
"Manuel M. T. Chakravarty" wrote:
> This is exactly what the `...-config' script that I was
> talking about is supposed to do. Now we can argue whether
> that should be part of `ghc' proper or an extra script. An
> extra script at least has the advantage that it is easier to
> maintain manual in
Sven Panne wrote:
> binaries go into /usr/bin, the whole rest into /usr/lib/ghc. So what's
> the problem? :-)
None. But can I suggest that if it's completely trivial we have
ghc -display-include-path
and
ghc -display-libraries
if that's easy to do? EG on this system
ghc -display-librar
"Manuel M. T. Chakravarty" wrote:
>
> Malcolm Wallace <[EMAIL PROTECTED]> wrote,
>
> > Can I propose a change to the -i / -I flags? Currently, the -idir (or
> > -Idir) options add a directory to the search path for imports. This
> > directory is either relative to the current dir, or absolute.
I must admit I'm surprised by the reaction to my suggestion. Here /usr is shared
between lots of machines and there is no question of my installing GHC in /usr/bin
or anything like it. (The few system adminstrators here are all honest, overworked,
and sadly incorruptible.) My original problem w
The latest binary distribution puts the GHC include files in
"lib/ghc-4.06/includes", not "lib/includes" as older versions used to.
This is a nuisance, because it means that there isn't any way a
Makefile can refer to the includes without coding in the GHC version.
Or is there? One needs access t
Part of the problem right now seems to be that GHC is wrongly rewriting (or
perhaps touching) the .hi file even though nothing in it is altered.
(This is clear because -hi-diffs is also on and not reporting anything).
Thus even though I'm using -Onot -recomp it's still recompiling everything.
George Russell wrote:
>
> Sigbjorn Finne wrote:
> >
> > Seems like you're not using -recomp.
> No I'm not. What about documenting it somewhere?
I take that back. I AM using it in the big program I mentioned, but I still
get huge swathes of unnecessary compilatio
Sigbjorn Finne wrote:
>
> Seems like you're not using -recomp.
No I'm not. What about documenting it somewhere?
Jon Fairbairn wrote:
> I'm afraid I've not gone through your detailed suggestions, but in the
> short term, would a crude hack that I used to use with Algol68C help?
No, fraid not. GHC already does this hack anyway. Algol68C didn't have
interface declarations. Still, nice to find someone else w
Malcolm Wallace wrote:
> Wrong. If B imports C and has no export list, nothing from C is
> re-exported, only definitions from B itself, with the single exception
> of C's instance decls.
OK, but this has no influence at all on my suggestions except to make
them work slightly better.
George Russell wrote:
> This scheme is not the cleverest that could be devised. For example it is
> still necessary to recompile whole chains of modules if you add an import
> declaration. (Not to a system library, imports from those are counted as
> "stable" in GHCs a
At the time of writing, I am waiting for yet another long Haskell re-make of
lots of modules to complete. The frustrating thing is, that at least 90% of these
remakes are actually completely unnecessary. Suppose module A imports module B
and B imports C. So in my automatically generated Make fi
floor(Inf) and floor(NaN) do not appear to be defined in Standard Haskell.
(They both come down to "properFraction" which is only defined for Ratio.)
This differs from (for example) the Standard ML Basis Library, where it
is specified that floor(Int) should raise Overflow and floor(NaN) should
rai
OK, I've now fixed the problem, I hope. Attached is a global-variable-free
implementation of Unique which has a logarithmic time compare action
(exercise for the reader or e-mail me privately to know why). I
expect everyone is now heartily fed up with this topic, and so while I'm
quite proud to
George Russell wrote:
> with comparison done in (at most) a logarithmic
> number of steps.
Damn. I really should have thought this through before making such
an assertion. You can contrive a sequence of calls that will force comparison
to take a linear number of steps. And I don'
George Russell wrote:
>
> George Russell wrote:
> > Exactly the same happens at the same time to Processor 2.
> > Now somehow you have to distinguish between Processor 1 and Processor 2,
> > because only one is going to get to lower the flags. But I don't think
>
Marcin 'Qrczak' Kowalczyk wrote:
> ...relative time of IO events that occured in a single thread.
> (>>=) imposes the sequencing.
Yes OK. I see no problem with required elements of the Unique type to
increase in a single thread. But I suspect anything stronger than this
could slow things down an
Tom Pledger wrote:
> For two threads to have access to the same MVar, they must have a
> common ancestor, right? Could a common ancestor spawn a transaction
> broker thread? That would be similar to what database management
> systems do. It'd still be centralised, but wouldn't need to do unsafe
Marcin 'Qrczak' Kowalczyk wrote:
[snip]
> The requirement could be even stronger, that the integers are
> increasing, so one can compare relative time of IO events without
Absolutely not. If you have 5000 processors, how are they to work out
which one did an IO event first? I don't really see th
Simon Peyton-Jones wrote:
> I think what you want is a distributed way to get a unique,
> as George suggested. Then you can pair that with an MVar when
> you want something comparable. The unique can include the processor
> id, so it can be globally unique. 64 bits?
>
> I'm still leery of putt
George Russell wrote:
> Exactly the same happens at the same time to Processor 2.
> Now somehow you have to distinguish between Processor 1 and Processor 2,
> because only one is going to get to lower the flags. But I don't think
> with the existing Concurrency extensions plus
(Michael Hobbs solution excised)
But this code could potentially loop forever! Surely that's just as bad
as deadlocking??
Marcin 'Qrczak' Kowalczyk wrote:
> If the IO monad can maintain a random number generator, it can as
> well mainain unique Integer supply. The interface is clean.
It can, but according to the current specification, it doesn't. Maybe
it should. I think Integer is a little too specific - how about
Simon Peyton-Jones wrote:
> Now newMVar needs to consult a global variable to get the
> next Flag number, but after that there's no global locking.
I really don't like this at all. Suppose we have Concurrent Haskell
running on 5000 processors, then every time I want to set this sort of
thing up I
Sorry if you don't want to be bothered with my problems, but I think this
problem which I've just encountered is rather amusing. Is there a neat solution?
I confess to finding concurrency problems difficult so there might be.
I want to implement a type Flag. Each flag is either Up or Down. Whe
Malcolm Wallace wrote:
>
> I am starting a one-person (and it might stay that way :-) campaign
> to change the name of the library module IOExts to something more
> meaningful and pronounceable. Personally, I hate the name IOExts
> with a vehement loathing, but I guess I probably have to convinc
Simon Marlow wrote:
> The binary dists all have pre-formatted HTML and PS docs, so you could just
> download one of those (except it seems the link to the Linux binary dist is
> currently broken; I'll fix that shortly, in the meantime there's the solaris
> binary dist).
I think perhaps you are mi
Please can we have a "binary" distribution of the Glasgow Haskell documentation
in HTML format? In theory I believe I can do it by installing various bits of
SGML software, hacking them to work with Solaris rather than Linux, linking them
up, and running the relevant Make commands in the fptools
Simon Marlow wrote:
>
> > Why doesn't the configure script have a
> >--with-happy
> > option? There are --with-gcc and --with-hc to tell configure
> > where to find
> > gcc and GHC.
>
> It's kind of a policy decision: build.mk is the appropriate place for
> setting such things at the moment
Why doesn't the configure script have a
--with-happy
option? There are --with-gcc and --with-hc to tell configure where to find
gcc and GHC.
Michael Weber wrote:
>
> On Tue, Jan 18, 2000 at 11:21:06 +0100, George Russell wrote:
>
> [...]
> > OK, after hacking ghc-inplace to stop it deleting all its files (is there
> > a --keep-everything option?) and running hsc inside gdb I get:
> [...]
>
> EXTRAHC
Simon Marlow wrote:
> Our nightly build did a two-stage bootstrap last night on a Sparc/Solaris
> system successfully
>
> ~/builds > uname -a
> SunOS gigha 5.7 Generic_106541-04 sun4u sparc SUNW,Ultra-5_10
uname -a
SunOS titania 5.7 Generic_106541-08 sun4u sparc SUNW,Ultra-1
> ~/builds > gcc -v
Simon Peyton-Jones wrote:
> This is the second Time-library-related issue in a few weeks.
> Does anyone out there know about Times in all their glory and
> feel like taking up the challenge?
Well I have. The attached module (TimeExts, based on Time)
is supposed to provide ways of adding
and subt
George Russell wrote:
[snip]
> It won't be so hard to
> speed up GHC later if that becomes important.
Since this has been disputed, here are three ways I believe you could speed up
GHC without rewriting the whole of it. I would be surprised if you didn't get
at least twice th
I really don't think you should have got rid of the binary distribution for
Happy 1.5 on Sparc/Solaris (which at least used to be on the Web page).
I may be wrong, but I suspect it is isn't possible to build the latest GHC from
scratch on Solaris using what can be downloaded from the Web site, b
Sven Panne wrote:
> Could you be a little bit more precise, e.g. the signatures of which
> functions should be changed and how?
All the documented functions in the Regex module which return
an "IO a" might as well return an "a". For example,
recompile_pattern :: PackedString -> Bool -> Bool -> P
and I shall probably have to fix most of it; I would still like this
sorted out . . .
Thanks
George Russell
What progress on the Great Hugs Collaboration? That is, being able to run
Hugs bytecode inside GHC or GHC compiled code inside Hugs. I don't expect
much detail but if the marriage is expected Real Soon Now, or alternatively has
been postponed indefinitely, I would like to know!
Simon Marlow wrote:
> Hmm, good points. The delay before running the signal handler shouldn't be
> too long, unless you have *lots* of running threads.
Actually it is long in the case of the program I'm trying (1 minute and counting).
I think that's because input is done via a _ccall_ (using
Simon Marlow wrote:
>
> [ replying to private mail, but cc'ing to the list ]
>
> George Russell asks if he can write a function that traps ^C, with type:
>
> >allowInterrupts :: IO a -> IO a -> IO a
>
> You can implement this as follows: the signal h
Simon Marlow wrote:
[snip]
> Hmm, you're probably doing a large chunk of renaming too. I just added an
> error call right after the parser in Main.lhs.
The MLj parser/lexer doesn't actually rename, but it does tokenise all
identifiers in the lexer. Symbols already known aren't even copied out o
George Russell wrote:
> I suspect that Simon M owes me a drink though . . .
Maybe I was wrong there. When I ran GHC I didn't hack it first to get it to stop
after parsing, and I don't know how to do that. It did fall over because it couldn't
find any of the import files,
Sven Panne wrote:
[snip]
> I guess that even the computer on *your* desktop would be fast
> enough for the current parser by the time a completely tuned
> rewrite of Happy would be finished. Moore's Law comes to the
> rescue here... :-)
Well we're going in circles here. So far we've established
icly available
> > modules for Haskell
> > syntax seems like a good one, and could be combined with this.
>
> There's a freely available haskell parser library - take a look at
>
>
>http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne/haskell_libs/hsparser.html
Since it appears to use Happy, it is presumably just as bad if not worse than GHC.
Err apologies for the tone, I only criticise GHC so much because it's so useful . . .
George Russell
can't you get Microsoft
to spend a few millions doing it?
> It was you who suggested the parser be rewritten. So what's the
> alternative?
Rewrite Happy.
Best wishes
George Russell
John O'Donnell wrote:
[snip]
> Please, do *not* put error correction into ghc! I think error correction
> is one of the Classic Bad Ideas for a compiler. It's much better to
> focus on providing understandable error messages: when the user knows
> what the compiler thinks is wrong, it's usually
Simon Peyton-Jones wrote:
[snip]
> There is no difficulty in principle here, but GHC would
> have to retain a lot more location information than it
> currently does. In particular, it could retain precise
> location info for every occurrence, and propagate that
> right through to the type checke
Yes, I know this is hackers only territory, but does it have to be made
deliberately difficult? I'm just trying to do this on a fresh machine and
while there's nothing especially difficult (not one tenth as bad as the
first time I did it . . .) the following are annoying:
(1) The repository is ve
Michael Weber <[EMAIL PROTECTED]> wrote
[snip]
> forkChild :: IO () -> IO (MVar ())
> forkChild p = do
> mvar <- newEmptyMVar
> forkIO (p >> putMVar mvar ())
> return mvar
This does not of course synthesise a non-daemonic forkIO from a daemonic one, because
it requires the parent threa
Einar Karlson, my predecessor, asked for daemonic forking as for Java. In Java
you have ordinary threads and daemonic threads; the process ends when only daemonic
threads are still running. The GHC team seem to have gone ahead and made all
forked thread daemonic! So can we have ordinary threads
The recent version, 3.77, of gmake seems to be a bit too clever
(or maybe too stupid) for GHC's device of not updating a .hi file
which is identical to the last one generated. It appears to me
as if gmake is saving on a call to fstat by assuming that .hi
has been updated even if it hasn't, and
It would be nice if the ghc command had options which made it call
a different hsc/gcc/ld than the one hardwired by the installation
procedure into the Perl script. Currently I am playing games with
my PATH to achieve this effect.
Unhappily, having managed to build hsc from scratch with gcc2.95 on Sparc/Solaris,
I can confirm that I still get a segmentation fault when I run it. So it looks like
we are stuck with gcc2.7.2. Is there anything that can be done about this?
Do these two work together? (I believe gcc2.95 is supposed to be descended
from egcs, which is supposed to sort-of-work with GHC).
I would like to add my strong support, as the person in charge of
transferring the UniForM workbench, for the implementation of
wait functions on input and output handles and input on Posix.FD
which don't block everything else to be done urgently. I think
I suggested this in May, and was told i
OK wise guys, now you've changed (incompatibly) the format of .hi files,
how can I rewrite these pre-404 hi-boot files so that they work for 404?
Can you summarise the changes?
For historical reasons (I suppose), the text in the Users Guide
section 5.4 on calling foreign functions from C seems to assume that
you only need C integers (represented by Int). This means it's not clear
what to do if, for example, you need size_t. At the moment I suppose most
people are still
Simon Marlow wrote:
>
> > In my experience, it pays off to store as many as possible
> > of the intermediate files (and even the linked binary during
> > development) on a local disk (e.g., on /tmp). This is
> > *much* faster than going via NFS.
>
> Absolutely.
>
> While I suspect that zipping
Sven Panne wrote:
[ cut ]
> Doing a similar thing for GHC would complicate things for implementors
> and users. How e.g. would you write your Makefile rules with .hi files
> in an archive?
Yes, it would complicate things for implementors, as they'd have to implement
it. However I don't think addi
Glasgow Haskell is very slow. I know it needs a lot of CPU time anyway,
but when I do ps it is only using 50% of the CPU available, and frequently
less. So I think what is happening is that it is spending half of its time
waiting for the Network Filing System to open and fstat interface files.
I
ng mailing list
for talking about the Hugs/GHC extensions do let me know.
Many thanks
George Russell
"Sigbjorn Finne (Intl Vendor)" wrote:
> this is a Hugs(98) issue, when Hugs starts to use the new
> RTS, `yield' is approximately equivalent to a nop. Before
> that time, won't ConcBase.suspend do the trick?
Well it might do, but ConcBase doesn't export it . . .
I suppose I shall have to hack the
"Sigbjorn Finne (Intl Vendor)" wrote:
> Is it worth adding something like `yield' to the Concurrent
> API? I'm unconvinced, but don't feel strongly about it. If
> there are others that also think that it should be supported,
> let me know, and I'll change my mind :-)
Here are two reasons:
(1) Pre-
GHC offers pre-emptive scheduling, so yield may be redundant.
But Hugs doesn't so it is vital. At the moment it looks like I shall
have to simulate it by creating an MVar () and swapMVar'ing it, but
that's not exactly ideal! So please could yield be provided? Thanks.
I have some code which uses threadWaitRead and threadWaitWrite which I'd
like to make more portable. Is it possible to approximate them in a way
which works for Hugs98 and Haskell 4.02? If not, as they look fairly useful,
could they be added to the standard Concurrent module?
I would like FiniteMap (and other similar modules, such as Bag) to be usable
from Hugs. I've played around a bit with unlit and cpp, and it seems that
there is an attempt to make FiniteMap portable, EG by allowing a choice of
boxed and unboxed types, but there are still one or two things, such as
We have had confusion here because GHC uses the "prefix" Makefile variable (which
gives the final location of the compiled code) at two different times.
It uses it in "gmake" to construct the "ghc-4.05" driver script
(which hardwires in the location of the installed code), and it uses it in
"gmake
Ah yes, I forgot to say that all my times were in GMT.
Andy Gill wrote:
[snip]
> What time (in GMT, say) are you proposing?
The best for me would be a compromise between when the GHC folk
go home for the day and how long everything takes to compile.
Would 8pm GMT be possible?
s come and stomp on
everything at 3am GMT, so in practice I can't have the new version in place until
the day after the day after the bug-fix. Could you consider mirroring the
anoncvs repository more often and/or earlier please?
Thanks
George Russell
101 - 185 of 185 matches
Mail list logo
