On 24 Oct 2015, at 09:17, Joachim Breitner wrote:
> For example in
>
>>Relevant bindings include
>> syllables :: [(a1, Syllable)]
>> (bound at Derive/Call/India/Pakhawaj.hs:141:16)
>> best_match :: [(a1, Syllable)]
>> -> Maybe (Int, ([(a1, Syllable)],
exist. Maybe they do but are too afraid
to speak up (due to corporate policy or whatever).
On Thu, May 7, 2015 at 10:41 PM, Malcolm Wallace malcolm.wall...@me.com
wrote:
I also note that in this discussion, so far not a single person has said that
the cpphs licence would actually
On 8 May 2015, at 00:06, Richard A. O'Keefe wrote:
I think it's important that there be *one*
cpp used by Haskell. fpp is under 4 kSLOC
of C, and surely Haskell can do a lot better.
FWIW, cpphs is about 1600 LoC today.
Regards,
Malcolm
___
licensing issues: perhaps we should simply ask Malcolm
Wallace if he would consider changing the license for the sake of GHC?
Or perhaps he could grant a custom-tailored license to the GHC
project? After all, the project page [1] says: If that's a problem
for you, contact me to make other arrangements
On 20 Jan 2015, at 11:20, Björn Peemöller wrote:
The reason is the usage of foldr, which changed its type from
foldr :: (a - b - b) - b - [a] - b -- GHC 7.8.4
to
foldr :: Foldable t = (a - b - b) - b - t a - b -- GHC 7.10.1
Thus, the use of foldr is now ambiguous. I can fix this by
On 1 Jan 2015, at 13:58, George Colpitts wrote:
Configuring cpphs-1.13...
Building cpphs-1.13...
Warning: cpphs.cabal: Unknown fields: build-depends (line 5)
Could not find module ‘Prelude’
It is a member of the hidden package ‘base-4.8.0.0’.
Perhaps you need to add ‘base’ to
How about doing the honest thing, and withdrawing both packages in ghc-7.10?
Haskell'98 is now 15 years old, and the 2010 standard was never really popular
anyway.
Regards,
Malcolm
On 30 Sep 2014, at 21:21, Austin Seipp aus...@well-typed.com wrote:
Hello developers, users, friends,
I'd
On 25 Apr 2014, at 14:17, Simon Marlow wrote:
The problem we often have is that when you're writing code for a library that
lives deep in the module hierarchy, you end up needing a deep directory
structure, where the top few layers are all empty.
I don't see how this is a problem at all.
Yes, this is a known problem. I intend to put out a fresh version of HaXml
soon to fix it.
Regards,
Malcolm
On 18 Mar 2014, at 15:17, Christian Maeder wrote:
Hi,
under mavericks using the ghc-clang-wrapper (ghc-7.6) or using
ghc-7.8.20140130 I can no longer install the HaXml
On 6 Aug 2013, at 20:03, Evan Laforge wrote:
I don't know how others like to work, but I like when a compiler bails
early, because I fix errors one at a time, and I search for the
easiest looking ones before worrying about the complicated looking
ones.
With C compilers, it is often the case
On 28 Jun 2013, at 12:16, AntC wrote:
Thanks Simon, I'm a little puzzled what your worry is.
f r b = r.foo b
With dot-notation baked in (non-orthogonally), f would get the type
f :: (r { foo::Bool }) = r - Bool - Bool
With the orthogonal proposal, f is equivalent to
Unless you show us the code, any answers will be guesses in the dark. Does
your program use unsafePerformIO unsafely perhaps? Or a version of a library
that happens to have a known bug?
On 25/05/2012, at 14:33, Mark Conway Wirt markcw...@gmail.com wrote:
I have a piece of Haskell code
On 29 Feb 2012, at 09:53, Antoras wrote:
I updated my GHC version from 7.0.3 to 7.4.1. But after that GHC is unable to
install some required packages.
containers-0.4.2.1 (reinstall) changes: array-0.4.0.0 - 0.3.0.3
binary-0.5.1.0 (reinstall) changes: array-0.4.0.0 - 0.3.0.3
I believe
Sorry to pick on your post in particular Matthew, but I have been seeing a lot
of this on the Haskell lists lately.
I find it completely unreasonable for a reply to a very long post to quote the
entire text, only to add a single line at the bottom (or worse, embedded in the
middle somewhere).
On 12 Jan 2012, at 18:41, Evan Laforge wrote:
Unicode dot (∘) would be optimal, since that's what it's for.
Is ∘ (U+2218 RING OPERATOR)* in Prelude yet? We should propose that.**
However, changing the composition operator from (.) will involve huge
amounts of changes to source code.
I notice that ghci is loading integer-simple before loading base. This at
least explains why it cannot find a symbol from the base package - it hasn't
been loaded yet. So the question is why does integer-simple use any function
from the base package at all? I'm fairly sure that the dependency
As one of the few people who has habitually used Haskell'98 wherever possible,
I favour plan A. As I recently discovered, in ghc 7 it is already very fragile
to attempt to depend on both the base and haskell98 packages simultaneously.
In most cases it simply doesn't work. Removing those few
On 10 Jun 2011, at 02:15, Manuel M T Chakravarty wrote:
Anybody who is halfway serious about developing software on a Mac will have
Xcode installed anyway.
As the original poster clarified, the motivating use-case is education
(specifically a class of 12-13 year olds.) These are not
On 6 Jun 2011, at 13:49, Lyndon Maydwell wrote:
I would be fantastic if XCode wasn't a dependency. ...
Not to detract at all from the work of the wonderful GHC and Haskell
Platform contributors in any way. For me it would just make it that
much easier to convince mac-using friends to give
hsc2hs converts
(#const sizeof(struct stat))
(#peek struct stat, st_mtimespec)
to
108
36
but the correct values are
144
32.
Is this a bug of hsc2hs?
Not directly. hsc2hs calls the C compiler to determine these numbers. It
seems it is calling gcc-4.0 rather than gcc-4.2. It
Ranjit,
I'd like to build a hoogle database that indexes the GHC source.
Can anyone point me to how I might do that? (Or better, to a
preexisting database?)
The author of Hoogle, Neil Mitchell, is currently on holiday, but I'm
sure he will have some good advice for you when he returns.
The final stumbling block is getting the local webserver (hoogle
server)
to also search the above database. I'm sure there must be some
simple way I
can pass the name of the database as an argument when I boot up the
server,
but I can't seem to find it...
Have you found the various
On 10 Jan 2011, at 22:37, Daniel Peebles wrote:
So the basic point seems to be: if you know how to use a tool, you
don't usually curse and swear when you use it. If you don't, you
tend to swear a lot!
There is a meta-point though - how easy is it to learn the tool?
Regards,
Malcolm
On 10 Jan 2011, at 14:02, Gregory Collins wrote:
+1. I don't have a lot of skin in this particular game (I'm not
currently a GHC contributor and am unlikely to become one in the near
future), but I can offer some anecdotal evidence:
As another non-GHC contributor, my opinion should probably
You will be more likely to get an answer on the ghc-users mailing list
(cc'ed). The ghc developers rarely follow -cafe.
On 1 Jan 2011, at 20:36, Jane Ren wrote:
Hi,
Does anyone know what GHC module gets the AST and type info of some
source code? This is the GHC module that converts all
(ii) If [pads| is a lexeme, then some list comprehensions become
illegal,
I am not myself a TH or QQ user, but it has always bothered me
slightly that the syntax for them steals some valid list comprehensions.
Of the alternative syntaxes you suggest...
My gut feel is to go with [|pads|
The flag -P for traditional gnu cpp (or --noline for stand-alone
cpphs) should suppress the initial #line noise.
Does ghc still fail to recognise a module-start pragma, even if the
only characters preceding it are whitespace?
I intended to give an example.
file foo.h
#if
Would you find the extra information useful, or just noise?
i.e. should we show error spans by default?
I certainly wouldn't find it distracting, and I think it could be
quite useful in many cases. I vote for turning it on by default.
I agree.
+1.
It is a feature I have always found useful
Too late. We had a stable link, I used it, Google used it, blog posts
were written that linked to it, I've emailed my wife links to it, I've
put them in Word documents, I've posted them on internal intranets.
You can't create a link, put content behind it, then move the content
- it just breaks
module Main where
import Foo (Bar.bar)
GHC apparently accepts this code, but I can find no mention of such a
feature in the GHC docs.
It certainly is an extension beyond Haskell'98 and Haskell 2010, which
do not permit qualified names in import lists. I cannot think for any
use for such
I've the 6.10.4 version installed on my MacOS X 10.6 OS. Have I to
uninstall this version of GHC before installing the Mac .pkg for the
6.12.1?
Most installer packages (_except_ for MacOS) allow you to have
multiple previous versions of ghc - they are simply left in place (but
must now
The ghc documentation at
http://www.haskell.org/ghc/docs/latest/html/users_guide/packages.html
says the following:
-package-name foo
Tells GHC the the module being compiled forms part of package
foo. If this flag is omitted (a very common case) then the default
package main is
Say you are
implementing a network server, for example -- you don't want
to have big spikes in the request latency due to GC.
We think
concurrent GC is unlikely to be practical in the Haskell
setting, due to the extra synchronisation needed in the
mutator.
-- Simon Marlow
It
i'm not an expert, but: once value of thunk is evaluated, it's
written
back by code called mutator
Whilst that is indeed mutation, it is not what is usually referred to
as the mutator in the context of garbage collection. Quite simply,
the mutator is the actual running program, as
Your function is not equivalent:
perm _|_ = _|_
permutations _|_ = _|_ : _|_
I have a vague memory that the library version diagonalises properly,
so that if you give it a lazy infinite input, it still generates
sensible output lazily. If so, this important property should be
noted in
In C code, I want to save a complex data strcuture defined in
haskell and pass it back to a haskell function at certain time.
Look up StablePtr in Haskell's FFI spec.
Regards,
Malcolm
___
Glasgow-haskell-users mailing list
I would hereby like to propose that the
ExistentialQuantification extension is deprecated.
It is worth pointing out that all current Haskell implementations (to
my knowledge) have ExistentialQuantification, whilst there is only one
Haskell implementation that has the proposed replacement
Max Bolingbroke batterseapo...@hotmail.com wrote:
2009/3/27 Simon Marlow marlo...@gmail.com:
I have a fix for num012 (the test is broken), but I still don't know
what's going on with num009.
num009 has been broken on OS X for as long as I can remember :-).
If it is any help, I can
Claus Reinke claus.rei...@talk21.com wrote:
A while ago, I needed lots of fairly small positive numbers,
together with a small number of flags for each, so I thought
I'd switch from Int to Word, and map the flags to bits.
Since there are few guarantees about the size of a Word (or Int),
Simon Marlow marlo...@gmail.com wrote:
stdout should be flushed when the program exits, regardless of whether
it exits as a result of a clean exit or an exception. I've just
checked the code, and that's certainly what is supposed to happen.
If anyone has evidence to the contrary, please
Peter Hercek pher...@gmail.com wrote:
http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack
I was writing about a way how to maintain the stack as described in
point 6 of the page (provided that point is about dynamic stack).
The whole page (including point 6) is about explicitly
Currently, hsc2hs (as shipped with GHC) cannot be used with just
hsc2hs Foo.hsc
as it cannot find HsFFI.h
The hsc2hs repo includes a shell script (yes, I know, no good on Windows)
called hsc2hs.wrapper that already adds some default arguments.
(nhc98 has a modified version of the script,
Here is an apparent bug in ghc's specialisation rules. The rewrite rule
generated by a SPECIALISE pragma seems to want to pattern-match on exact
dictionaries (as well as types). But the compiler is not necessarily
able to fully resolve dictionaries before the rules are supposed to
fire.
First,
Kwanghoon Choi lazysw...@gmail.com wrote:
=
instance Arg a = Arg [a] where
pr _ = [ ++ pr (undefined :: a) ++ ]
=
You want to use `asTypeOf`, with a lazy
It seems that the problem you have is that moving to the multithreaded
runtime imposes an overhead on the communication between your two
threads, when run on a *single CPU*. But performance on a single CPU
is not what you're interested in - you said you wanted parallelism,
and for that you
Simon Marlow marlo...@gmail.com wrote:
Malcolm Wallace wrote:
For the only application I tried, using the threaded RTS imposes a
100% performance penalty - i.e. computation time doubles, compared
to the non-threaded RTS. This was with ghc-6.8.2, and maybe the
overhead has improved
basically, IMCROSS installs a couple new gccs with names like
/usr/local/bin/i386-mingw-gcc and so forth, is there some way to get
ghc to use said non-native compiler as its back end?
I don't know about IMCROSS specifically, but earlier this year Sylvain
Nahas adapted the build system of nhc98
Had you deprecated the non-threaded RTS, we would probably have no
problems described in ticket #2848 :-/
I think you'll have to deprecate it anyway, because it will be more
and more difficult to maintain two versions of code,
we may conduct small survey on amount of usage of old RTS
The suggested remedy of commenting out the
line reading SRC_HC_OPTS += -fvia-C in the Makefile won't work, as
that line isn't there anyway.
In case it is not obvious from what other people have said, way back
in the days of ghc-6.2, you got -fvia-C by default, whether it was
specified on
test2 :: Box a - a - [a]
test2 box x = go x
where
-- go :: a - [a]
go y = [(val box), y]
Couldn't match expected type `a1' against inferred type `a'
You need to turn on {-# ScopedTypedVariables #-}.
See
When the -XUnicodeSyntax option is specified, GHC accepts some Unicode
characters including left/right arrows. Unfortunately, the letter
greek lambda cannot be used. Are there any technical reasons to not
accept it?
The greek lambda is a normal lower-case alphabetic character - it can
be used
John Meacham [EMAIL PROTECTED] wrote:
(bring back hmake! :) ).
It never went away...
http://www.cs.york.ac.uk/fp/hmake
I even have the idea to allow hmake to read the .cabal file format for
configuration data (although that is waiting for a delivery of round
Manuel wrote:
| It is worth pointing out that I *never* validate against ghc head
when
| I commit to the core libraries.
Sorry, but I think the only reason its halfway acceptable is that
Malcolm didn't break the GHC build yet. If he does, I'll be
screaming as loudly as for anybody
I don't think that is the right policy. Everybody (including Malcolm)
should validate.
If you contribute code to the linux kernel, comprehensive testing of
the code is a requirement, too.
The analogy is flawed. It is like asking the developers of _gcc_ to
ensure that the Linux kernel
I think an even better analogy is probably comparing it to developer
of GCC changing the libc implementation of another compiler or vice
versa.
Our shared libraries do not belong to any one compiler. They are joint
creations, with a lot of community (non-compiler-hacker) involvement.
On 12 Aug 2008, at 01:35, Manuel M T Chakravarty wrote:
Ah, good point! Changing ghc to git means *all* developers of boot
libraries need to use git *regardless* of what repo format the boot
libraries are in. After all, they need to validate against the
current ghc head before pushing.
With the upcoming switchover to git, has any thought gone into merging
in the libraries into the main ghc tree
The libraries are going to remain under darcs, because they are shared
with other haskell compilers.
Regards,
Malcolm
___
I'd be interested in any progress here -- we noticed issues with
optimisations in the stream fusion package across module boundaries
that we never tracked down. If there's some key things not firing,
that would be good to know.
I suspect that if all modules are compiled -O0, then you
I've built binary distributions for Mac OS 10.4 (Tiger) based on
(better supported) GMP and GNUreadline frameworks and for Solaris 10.
http://www.dfki.de/sks/hets/mac/versions/ghc-6.8.2-powerpc-apple-darwin.tar.bz2
Yes at the moment we allow
LANGUAGE
language
but not
Language
or
LanGUAge
Being allowed to write
Language
would be nice
I concur. Surely it is easy to just (map toLower) over the pragma
identifier before comparison with known pragma
Marc Weber [EMAIL PROTECTED] wrote:
print $ M.(.!.) [1,2] 1 -- (2)
The parens must enclose the whole varop:
print $ (M..!.) [1,2] 1 -- (2)
Regards,
Malcolm
___
Glasgow-haskell-users
Matthew Danish [EMAIL PROTECTED] wrote:
I've been playing with the INTEST problem on SPOJ which demonstrates
the ability to write a program which processes large quantities of
input data. http://www.spoj.pl/problems/INTEST/
I don't know if anyone replied to this already, so here is my
Iavor Diatchki wrote:
Just curious, what external modules does the Prelude depend on?
I'm not really sure what you mean by external modules. In GHC the
Prelude is comprised almost entirely of re-exports from other
modules.
Just to note that, although ghc's inversion of the expected
Adrian Hey [EMAIL PROTECTED] wrote:
Failing because the stack has
grown beyond some arbitrary (and typically small) size seems
bad to me.
Just FYI, nhc98 has a single memory area in which the stack and heap
grow towards each other. Memory exhaustion only happens when the stack
and heap meet
I wrote:
So, should I push my patch for building
System.Posix.Types with nhc98 (i.e. without autoconf, with hsc2hs)?
OK, I have pushed a revised patch, which should not alter the behaviour
for ghc at all. I moved the invocation of hsc2hs into the NHC.*
hierarchy, and just re-export that module
Simon Marlow [EMAIL PROTECTED] wrote:
Also after the base
reorg we might find we have no hsc2hs-generated code left in base and
we can disable hsc2hs to prevent this happening again.
Ah. I was about to checkin a replacement for System.Posix.Types (in
base) that uses hsc2hs instead of
Simon Marlow [EMAIL PROTECTED] wrote:
I suppose we could add a dependency on another Haskell compiler just to
run hsc2hs, but that's a pain.
I'm hoping that by the end of this summer, nhc98 will be able to compile
the whole of ghc. :-) Also, and alternatively, the yhc chaps have
mooted the
Simon Marlow [EMAIL PROTECTED] writes:
Ah. I was about to checkin a replacement for System.Posix.Types (in
base) that uses hsc2hs instead of autoconf.
Anyway, to answer your question, using hsc2hs in System.Posix.Types
will cause problems for bootstrapping GHC, yes, because we can't run
Wilson MacGyver [EMAIL PROTECTED] wrote:
there is no reason for multiple build-bot for the same platform is
there?
If you have two or three slaves for each platform, then the buildbot is
robustified against downtime of any of the machines (intentional, like
going on holiday for a couple of
Serge D. Mechveliani [EMAIL PROTECTED] wrote:
{-# OPTIONS_GHC -fglasgow-ext -prof -auto-all #-}
LemmaSearch.hs:
unknown flags in {-# OPTIONS #-} pragma: -fglasgow-ext -prof -auto-all
You have spelled the first option wrongly: should be -fglasgow-exts.
Regards,
Malcolm
Seth Kurtzberg [EMAIL PROTECTED] writes:
how about searching code that's outside of the standard library? Hoogle
doesn't seem to know about HaXml, or haskelldb for example (maybe I am
missing something obvious)
You want to distinguish between capabilities, and the fact that the
Simon Marlow [EMAIL PROTECTED] wrote:
When I use `seq`, it is sometimes in a construction like
unsafePerformIO (emit squawk!) `seq` x
My take on this kind of thing is that if you want a specific
operational behaviour, then you're doing something
implementation-specific. We
Simon Marlow [EMAIL PROTECTED] wrote:
The report is in general very careful to say absolutely *nothing*
about evaluation order, leaving the implementation free to choose,
Yes, this is a highly desirable goal.
However, having said all that, arguably an exception should be made in
this
Deborah Goldsmith [EMAIL PROTECTED] wrote:
I checked and the Mac OS X PowerPC binary distribution does not have
this problem; only Mac OS X Intel.
Is it possible that the Intel distro built the OpenGL package using
Cabal, but the PowerPC distro used Makefiles? I seem to recall there
was
Simon Marlow [EMAIL PROTECTED] wrote:
The difference is subtle. The semantics of seq and pseq are
identical; however, GHC can see that seq is strict in both its
arguments and hence could choose to evaluate them in either order,
whereas pseq is only strict in its first argument as far as
Luke Worth [EMAIL PROTECTED] wrote:
I just installed GHC 6.6 using the PPC binary installer on Mac OS X.
I'm having some trouble getting debuggers to work; I have tried both
plargleflarp (buddha) and Hat. Neither of them will compile on GHC
6.6 on Mac yet.
As an interim measure, I have
HaXml (no longer builds)
In what way does HaXml fail to build for Hugs? Is it easily
fixable?
... and there's the famous Data.FiniteMap.
So does anyone have any objections if I go ahead and commit the
replacement (compatibility) implementation of Data.FiniteMap to the main
So does anyone have any objections if I go ahead and commit the
replacement (compatibility) implementation of Data.FiniteMap to the
main repository for packages/base?
I'd rather see HaXml updated to use Data.Map, perhaps with a
compatibility layer for older GHCs.
OK, I've looked more
Bulat Ziganshin [EMAIL PROTECTED] wrote:
It makes sense to me that the above behaviour is seen: length is
now a good
consumer, but it generates 1+(1+(1+(1+... as it is consuming, and
this causes a stack overflow. I don't think we can fix this while
staying with fold/build fusion,
Joel Reymont [EMAIL PROTECTED] wrote:
Thanks for the tip! I'm _really_ interested in why it takes 55 min on
Linux and 3+ hours on Mac Intel, though. Any clues?
Building a compiler generally reads/touches/creates a very large number
of files. So one possibility is the relative efficiency of
Joel Reymont [EMAIL PROTECTED] wrote:
Thanks for the tip! I'm _really_ interested in why it takes 55 min on
Linux and 3+ hours on Mac Intel, though. Any clues?
Another thought. The ghc HACKING guide has this to say:
The GHC build tree is set up so that, by default, it builds a
Marc Weber [EMAIL PROTECTED] wrote:
My purpose: After having found the a function I want to use it without
having to search where does it belong to and where does it come from.
I want it beeing as up to date as the installed libraries.
You can download Hoogle as a command-line tool, and give
[EMAIL PROTECTED] (Donald Bruce Stewart) wrote:
So what am I doing wrong? And is there any way to ask the compiler
to give a warning if the RULES pragma contains errors?
In this case, it's because it's missing -fglasgow-exts, I think.
Ah, thank you. The missing (and undocumented)
Malcolm Wallace [EMAIL PROTECTED] wrote:
Ah, thank you. The missing (and undocumented) option.
Actually, now I came to submit a patch to the manual, I discover that it
/is/ documented, but at the beginning of section 7. (But on the index
page on the web, the link to section 7 is two whole
Christian Maeder [EMAIL PROTECTED] wrote:
It doesn't work under solaris and under linux [1] my nightly
compilation jobs are killed every tuesday morning (!) for some
reason that i cannot reproduce. I suspect the threaded RTS and heavy
load. I had no such problems with ghc-6.4.1 before.
A
I think many would be grateful if a podcast were made of this event
such that those who missed it can still watch the presentations.
+1. A podcast would be perfect, posting minutes would be next in line.
If the Hackathon goes ahead, recording a video podcast of the event
should be
Chris Brown [EMAIL PROTECTED] writes:
ld: Undefined symbols:
_TypeRep_AClass_stauic_info
I have noticed that there are spelling mistakes in these error messages.
_TypeRep_AClass_stauic_info
should be
_TypeRep_AClass_static_info
Earlier there was something with
DISCASD
instead of
John Goerzen [EMAIL PROTECTED] writes:
Meanwhile, I noted that the HaXml repo on darcs.haskell.org seems
to be a verbatim copy of the darcs repo at York.
Ahh. You are correct.
Re-converting now, since you've presumably committed patches to the
darcs side, is probably not going to be
Sven Moritz Hallberg [EMAIL PROTECTED] writes:
I'm running GHC and GCC head-to-head on the task of adding a bunch of
long IOUArray-Vectors really fast. My machine is a Linux-ppc PowerBook
and gets a runtime for the GHC-compiled binary that's about 10x as long
as for GCC.
Is it possible that
John Goerzen wrote:
* I will re-convert all of the top-level directories in the current
libraries darcs repo, except for: doc, mk, and Cabal
* Each new repo will be under darcs.haskell.org/packages
Inspired by the new browsable interface to the libraries repo at
Sven Panne [EMAIL PROTECTED] writes:
I've been looking at the cvs configuration file CVSROOT/modules.
I /think/ the procedure is something like changing this:
nhc98src-d nhc98 nhc98
nhc98libraries -d nhc98/src/libraries fptools/libraries
nhc98 -a
Simon Marlow [EMAIL PROTECTED] writes:
But how about having a separate repository for each library
package?
The time to mention this would have been a few weeks ago when I proposed
the current scheme :-)
Err, I think I did...
I think it /would/ actually be nicer to split up the
[EMAIL PROTECTED] (Donald Bruce Stewart) writes:
One thing it occurs to me to ask is what will be happening to CVS
commit messages, once the switchover to darcs happens?
I originally wrote this script as a temporary fix until darcs supported
post-apply hooks. If it does now, perhaps
Simon Marlow [EMAIL PROTECTED] writes:
The aim is to eventually switch over to using darcs for our revision
control. The point of this message is to find out what constraints
people have that will affect when we can throw the switch.
One thing it occurs to me to ask is what will be happening
Ross Paterson [EMAIL PROTECTED] writes:
No problem for me if you switch over at any time. But how about having
a separate repository for each library package?
Seconded.
Regards,
Malcolm
___
Glasgow-haskell-users mailing list
Simon Marlow [EMAIL PROTECTED] writes:
Malcolm, Ross - since you both also use the CVS libraries tree, is it
going to be possible for you to switch to using darcs to get the
libraries? Any idea how long you'll need?
I've been looking at the cvs configuration file CVSROOT/modules.
I /think/
Simon Marlow [EMAIL PROTECTED] writes:
In the general case, for some arbitrary
actions between the write and the read (excluding another write of
course), there is no guarantee that the IORef remains unmodified.
This is an analysis that's performed all the time
Jan-Willem Maessen [EMAIL PROTECTED] writes:
- Fetch elimination for imperative reads:
writeIORef r e acts readIORef r
=== writeIORef r e acts return e
This transformation is valid only on single-threaded systems.
If there is any possibility of an IORef being shared across
Simon Marlow [EMAIL PROTECTED] writes:
I should have said that if 'acts' blocks, then the transformation is
invalid.
Well that is exactly what I was assuming when I said that the
transformation is invalid. In the general case, for some arbitrary
actions between the write and the read
[previously sent by mistake to Simon only - new para at end]
Simon Marlow [EMAIL PROTECTED] writes:
Now, take the original program, but change the creation of m2 to
newMVar (), i.e. m2 starts off full. Is the transformation valid now?
Well maybe, because in some interleavings acts does not
1 - 100 of 189 matches
Mail list logo
